qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [BUG]: kvm_set_phys_mem: error unregistering overlappin


From: Jordan Justen
Subject: Re: [Qemu-devel] [BUG]: kvm_set_phys_mem: error unregistering overlapping slot: Invalid argument
Date: Thu, 30 May 2013 10:32:36 -0700

On Thu, May 30, 2013 at 10:03 AM, Luiz Capitulino
<address@hidden> wrote:
> On Thu, 30 May 2013 09:50:10 -0700
> Jordan Justen <address@hidden> wrote:
>> On Thu, May 30, 2013 at 9:08 AM, Luiz Capitulino <address@hidden> wrote:
>> > On Thu, 30 May 2013 18:03:04 +0200
>> > Paolo Bonzini <address@hidden> wrote:
>> >
>> >> Il 30/05/2013 17:46, Luiz Capitulino ha scritto:
>> >> > The culprit is commit:
>> >> >
>> >> > commit 235e8982ad393e5611cb892df54881c872eea9e1
>> >> > Author: Jordan Justen <address@hidden>
>> >> > Date:   Wed May 29 01:27:26 2013 -0700
>> >> >
>> >> >     kvm: support using KVM_MEM_READONLY flag for regions
>> >> >
>> >> > I'm running 3.9.2-200.fc18, btw. And, error checking is missing on the
>> >> > first call to kvm_vm_ioctl().
>>
>> As noted in the code, the first call is for KVM commit 75d61fbc.
>>
>> I'm not sure we want to fail if an error occurs when making that call.
>> (I'm pretty sure we don't want to in fact.)
>>
>> Xiao, any thoughts?
>>
>> >> Reproducer?
>> >
>> > I just try to start a VM (HEAD 87d23f7):
>> >
>> > ~/work/virt/ sudo ./qemu-qmp -drive 
>> > file=disks/test.img,if=virtio,cache=none,aio=native -enable-kvm -m 1G 
>> > -monitor stdio -cpu host -snapshot
>> > QEMU 1.5.50 monitor - type 'help' for more information
>> > (qemu) kvm_set_phys_mem: error unregistering overlapping slot: Invalid 
>> > argument
>> > ~/work/virt/
>>
>> Sorry. I am working with Linux 3.8.0, and I don't see this. I'll try
>> to update my kernel.
>>
>> Does the firmware behave as a ROM for you?
>
> I think so:
>
> (qemu) info roms
> fw=genroms/kvmvapic.bin size=0x002400 name="kvmvapic.bin"
> addr=00000000fffe0000 size=0x020000 mem=rom name="bios.bin"
> (qemu)
>
> Is this what you're asking?

I guess I was meaning ... if you write to an address such as
0xfffffff0, does it update as RAM, or does it retain the original
value?

This is easy to test in OVMF at the EFI shell, but I'm not sure how
you could easily test it otherwise.

Does the system actually boot for you after the error message?

-Jordan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]