Re: An emulation failure occurs, if I hotplug vcpus immediately after the VM start

[David Hildenbrand <david@redhat.com>]

On 06.06.2018 15:57, Paolo Bonzini wrote:
> On 06/06/2018 15:28, Gonglei (Arei) wrote:
>> gonglei********: mem.slot: 3, mem.guest_phys_addr=0xc0000,
>> mem.userspace_addr=0x7fc343ec0000, mem.flags=0, memory_size=0x0 
>> gonglei********: mem.slot: 3, mem.guest_phys_addr=0xc0000,
>> mem.userspace_addr=0x7fc343ec0000, mem.flags=0, memory_size=0x9000
>>
>> When the memory region is cleared, the KVM will tell the slot to be 
>> invalid (which it is set to KVM_MEMSLOT_INVALID).
>>
>> If SeaBIOS accesses this memory and cause page fault, it will find an
>> invalid value according to gfn (by __gfn_to_pfn_memslot), and finally
>> it will return an invalid value, and finally it will return a
>> failure.
>>
>> So, My questions are:
>>
>> 1) Why don't we hold kvm->slots_lock during page fault processing?
> 
> Because it's protected by SRCU.  We don't need kvm->slots_lock on the
> read side.
> 
>> 2) How do we assure that vcpus will not access the corresponding 
>> region when deleting an memory slot?
> 
> We don't.  It's generally a guest bug if they do, but the problem here
> is that QEMU is splitting a memory region in two parts and that is not
> atomic.
> 
> One fix could be to add a KVM_SET_USER_MEMORY_REGIONS ioctl that
> replaces the entire memory map atomically.
> 
> Paolo
> 

Hi Paolo,

I have a related requirement, which would be to atomically grow a
memory regions. So instead of region_del(old)+region_add(new), I would
have to do it in one shot (atomically).

AFAICS an atomic replace of the memory map would work for this, too.
However I am not sure how we want to handle all kinds of tracking data
that is connected to e.g. x86 memory slots (e.g. rmap, dirty bitmap ...).

And for a generic KVM_SET_USER_MEMORY_REGIONS, we would have to handle
this somehow.

-- 

Thanks,

David / dhildenb