qemu-devel
[Top][All Lists]
Advanced

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

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v2 3/5] Qemu: do not mark bios readonly
Date: Wed, 31 Oct 2012 07:46:36 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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: signature.asc
Description: OpenPGP digital signature


reply via email to

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