[Qemu-devel] Re: [PATCH 6/7] Set slots more carefully

[Jan Kiszka]

Alexander Graf wrote:
> 
> On 17.07.2009, at 16:18, Jan Kiszka wrote:
> 
>> Alexander Graf wrote:
>>>
>>> On 17.07.2009, at 15:48, Jan Kiszka wrote:
>>>
>>>> Alexander Graf wrote:
>>>>> KVM only supports slot sizes of PAGE_SIZE granilarity. On PPC the OS
>>>>> sets the framebuffer to some odd size though, causing the current code
>>>>> to simply abort().
>>>>>
>>>>> So let's bet graceful here. We can just allocate memory sizes that
>>>>> are of
>>>>> PAGE_SIZE granularity and everything that exceeds that comes in as
>>>>> MMIO and
>>>>> gets handled too - just slower.
>>>>>
>>>>> Signed-off-by: Alexander Graf <address@hidden>
>>>>> ---
>>>>> kvm-all.c |    2 +-
>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/kvm-all.c b/kvm-all.c
>>>>> index 961fa32..60b76cf 100644
>>>>> --- a/kvm-all.c
>>>>> +++ b/kvm-all.c
>>>>> @@ -134,7 +134,7 @@ static int kvm_set_user_memory_region(KVMState
>>>>> *s, KVMSlot *slot)
>>>>>
>>>>>    mem.slot = slot->slot;
>>>>>    mem.guest_phys_addr = slot->start_addr;
>>>>> -    mem.memory_size = slot->memory_size;
>>>>> +    mem.memory_size = slot->memory_size & ~(TARGET_PAGE_SIZE - 1);
>>>>
>>>> TARGET_PAGE_MASK? And I bet you want to round up here...
>>>
>>>
>>> Eh - yeah. Same thing, no?
>>
>> Just look at its definition...
>>
>>>
>>> And no, I don't want to round up. After the memory backed slot could
>>> easily be real MMIO space. I had such strange configurations with the
>>> ESCC overlapping in the same page as graphic memory once.
>>
>> Overlapping is handled by the kvm layer in user space. For sure, if
>> there is a mapping conflict, we are in trouble (kvm-wise) as the second
>> request overwrites the mapping type of the overlapping page(s).
>>
>>>
>>> Better be safe than sorry.
>>
>> No, something wrong. If you cut off the odd "overhead", you effectively
>> exclude that page. So either the caller should not include it in the
>> first place as it is unused or kvm should try to map the whole page just
>> like the rest of the slot. If there remains an unresolvable conflict, we
>> need to enhance the slot management with some sub-page dispatching
>> mechanism.
> 
> Not mapped = MMIO

Right.

> 
> MMIO then gets passed to userspace which puts it into qemu's read/write
> functions which then decide if it's real MMIO or just a plain RAM access.
> 
> So all we get is a couple more MMIO accesses, right?

In this particular case. But it only happens to work due to the given
setup. You can't derive a generic rounding rule for KVM slots from this.

You may say if slot A is MMIO and slot B RAM, that a overlapping page
should be handled as MMIO. But that's not what your code does.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux