Re: [qemu-s390x] [Qemu-devel] [PATCH for-4.0?] exec: Only count mapped memory backends for qemu_getrampagesize()

[David Hildenbrand]

>> Once we support 2GB pages, we'll might have think about what you
>> describe here, depending on what the KVM interface promises us. If the
>> interfaces promises "If 2GB are enabled, 1MB are enabled implicitly", we
>> are fine, otherwise we would have to check per mapped backend.
> 
> I guess.  I'm generally in favour of checking explicitly for the
> condition you need, rather than something that should be equivalent
> based on a bunch of assumptions, even if those assumptions are pretty
> solid.  At least if it's practical to do so, which explicitly
> iterating through the backends seems like it would be here.
> 
> But, when it comes down to it, I don't really care that much which
> solution you go with.

I guess it will be all easier to handle once we would have all RAM
converted to (internal) memory devices. No need to check for (e.g.
mem-path) side conditions or memory backends used for different purposes
than RAM.

> 
>>> It also occurs to me: why does this logic need to be in qemu at all?
>>> KVM must know what pagesizes it supports, and I assume it will throw
>>> an error if you try to put something with the wrong size into a
>>> memslot.  So can't qemu just report that error, rather than checking
>>> the pagesizes itself?
>>
>> There are multiple things to that
>>
>> 1. "KVM must know what pagesizes it supports"
>>
>> Yes it does, and this is reflected via KVM capabilities (e.g.
>> KVM_CAP_S390_HPAGE_1M) . To make use of
>> these capabilities, they have to be enabled by user space. Once we have
>> support for 2G pages, we'll have KVM_CAP_S390_HPAGE_2G.
>>
>> In case the capability is enabled, certain things have to be changed in KVM
>> - CMMA can no longer be used (user space has to properly take care of that)
>> - Certain HW assists (PFMF interpretation, Storage Key Facility) have to
>> be disabled early.
>>
>>
>> 2. "it will throw an error if you try to put something with the wrong
>>     size into a memslot"
>>
>> An error will be reported when trying to map a huge page into the GMAP
>> (e.g. on a host page fault in virtualization mode). So not when the
>> memslot is configured, but during kvm_run.
> 
> Ah, ok, if we don't get the error at set memslot time then yes that's
> definitely something we'd need to check for in qemu in advance.
> 
>> Checking the memslot might be
>>
>> a) complicated (check all VMAs)
> 
> Yeah, maybe.
> 
>> b) waste of time (many VMAs)
> 
> I doubt that's really the case, but it doesn't mater because..
> 
>> c) incorrect - the content of a memslot can change any time. (KVM
>> synchronous MMU). Think of someone wanting to remap some pages part of a
>> memslot using huge pages.
> 
> ..good point.  Yeah, ok, that's not going to work.
> 
>> 3. Can you elaborate on "So can't qemu just report that error, rather
>> than checking the pagesizes itself?" We effectively check against the
>> capabilities of KVM and the page size. Based on that, we report the
>> error in QEMU. Reporting an error after the guest has already started
>> and crashed during kvm_run due to a huge page is way too late.
> 
> Agreed.
> 


-- 

Thanks,

David / dhildenb