Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

On 2012-10-31 07:35, Xiao Guangrong wrote:
>>>>> We can not do that for pflash is a RD device which can not be directly written,
>>>>> kvm can not emulate the instruction which implicitly write the memory. (e.g:
>>>>> using this area as stack).
>>>>
>>>> Isn't enabling ROMD support for KVM that whole point of your patches? I
>>>
>>> It can generate MMIO exit if ROMD be written, that means the instruction
>>> needs kvm's help to be finished if it explicitly/implicitly write the memory.
>>
>> I was assuming that this is what you already do. If you trap write
>> accesses, why not allowing user space to handle them?
> 
> Already have done that, guest write ROMD -> vmexit -> return to userspace with
> MMIO Exit.

Great.

> 
>>
>>>
>>>> do not see yet what prevents this still, but it should be fixed first.
>>>
>>> For the explicitly write memory access, it is easy to be fixed - we just need
>>> to fetch the instruction from EIP and emulate it. But for the implicitly memory
>>> access, fixing its emulation is really hard work. Really worth doing it?
>>
>> Aren't the read-only regions also marked read-only on the host side to
>> avoid that the guest writes to it? Or how is this implemented?
>>
>> Support for flash emulation in KVM mode is increasingly important, for
>> embedded platform virtualization but also for classic x86 server-like
>> targets. The pflash-backed system firmware device was added for a reason...
> 
> Please allow me to clarify it more clearly.
> 
> The flash is ROMD device means guest can not write it, any kinds of guest write
> access on this device can cause vmexit to kvm and return to userspace.
> 
> We should pay more attention on it if we execute the code in ROMD since we
> can not use ROMD as stack/page table/IDT table and all other implicitly write access.
> Of course, if you do not use ROM as those purposes, it is okay. :)

So the problem is that there is KVM code that still blindly writes to
guest memory and does not take the memory regions' protection flag into
account? And we cannot mark those regions read only in the host's page
table?

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]