Re: [Xen-devel] [PATCH v1 0/2] Extend ioreq-server to support page write protection

["Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>]

Tian, Kevin wrote on 2014-08-06:
>> From: Zhang, Yang Z
>> Sent: Tuesday, August 05, 2014 7:11 PM
>> 
>> Tian, Kevin wrote on 2014-08-05:
>>>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>>>> Sent: Tuesday, August 05, 2014 12:52 AM
>>>> 
>>>>>>> On 05.08.14 at 09:35, <yang.z.zhang@xxxxxxxxx> wrote: Tian,
>>>>>>> Kevin wrote on 2014-08-05: From: Jan Beulich
>>>>>>> [mailto:JBeulich@xxxxxxxx]
>>>>>>> Sent: Monday, August 04, 2014 12:35 AM
>>>>>>> 
>>>>>>>>>> On 04.08.14 at 07:05, <wei.ye@xxxxxxxxx> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> Jan Beulich wrote on 2014-07-28:
>>>>>>>>> devel@xxxxxxxxxxxxx; keir@xxxxxxx
>>>>>>>>> Subject: Re: [PATCH v1 0/2] Extend ioreq-server to support
>>>>>>>>> page write protection
>>>>>>>>> 
>>>>>>>>>>>> On 28.07.14 at 19:55, <wei.ye@xxxxxxxxx> wrote:
>>>>>>>>>> ioreq-server is proposed to forward PIO and MMIO request to
>>>>>>>>>> multiple device models according to the io range. XenGT (Intel
>>>>>>>>>> Graphics Virtualization technology, please refer to
>>>>>>>>>> https://01.org/xen/blogs/srclarkx/2013/graphics-virtualizat io
>>>>>>>>>> n- xengt) driver reside in Dom0 as a virtual graphics device
>>>>>>>>>> model also need to trap and emulate the guest's write operation
>>>>>>>>>> to some specific memory pages, like the memory pages used by
>>>>>>>>>> guest graphics driver as PPGTT(per-process graphics translation
>>>>>>>>>> table). We add an new p2m type "p2m_ram_wp" to trap the page
>>>>>>>>>> write operation. Page of this new p2m type is read only and for
>>>>>>>>>> write, the request will go to device model via ioreq-server.
>>>>>>>>> 
>>>>>>>>> So how is this write-protection supposed to work on the
>>>>>>>>> IOMMU side when sharing page tables?
>>>>>>>> 
>>>>>>>> Thanks for pointing out this question. Write-protection is
>>>>>>>> not supposed to work when sharing page tables between EPT and vt-d.
>>>>>>>> An explicit command line "iommu=no-sharept" should be setted
>>>>>>>> for avoiding undesirable iommu fault.
>>>>>>> 
>>>>>>> Requiring the unconditional use of a specific command line
>>>>>>> option is certainly fine for experimental code, but not beyond that.
>>>>>>> Behavior should be correct by default in production code.
>>>>>>> 
>>>>>>> But what's worse here: The option _allows_ device side writes from
>>>>>>> the guest. Why would device side writes be okay, but CPU side ones
>>>>>>> not?
>>>>>>> 
>>>>>> 
>>>>>> right, whether ept is shared or not doesn't address the concern here.
>>>>>> In both cases we need maintain the same p2m view between CPU
>>>>>> and device side, otherwise it's broken...
>>>>>> 
>>>>>> One option is to treat wp similar to logdirty, i.e. exclusive
>>>>>> to VT-d device assignment, until in the future VT-d supports
>>>>>> page fault. We can provide a boot option to override the
>>>>>> default policy if user thinks OK.
>>>>>> 
>>>>>> 2nd option, like Wei mentioned in another mail, is to treat
>>>>>> such write protected PPGTT page tables as MMIO. new hypercall
>>>>>> is required to change the p2m type between p2m_io and p2m_ram,
>>>>>> based on allocation/free of guest page table. This way may
>>>>>> impact performance on read though.
>>>>>> 
>>>>>> Comments?
>>>>> 
>>>>> Another solution is using the EPT misconfiguration mechanism
>>>>> like what Xen does for MTRR emulation currently.
>>>> 
>>>> That would cause faults on reads as well, making it necessary to
>>>> emulate them.
>>>> 
>>> 
>>> Then it's same effect of p2m_mmio_dm.
>> 
>> p2m_mmio_dm will break VT-d but EPT misconfiguration doesn't.
>> 
> 
> I don't understand. Treating it as emulated io just means no valid p2m
> entry in EPT/VT-d. Note XenGT itself doesn't require VT-d, while you
> can still assign other devices this way.

From guest's view, it doesn't know the page is not valid in EPT/VT-d table. So 
if guest CPU touch this page, then hypervisor will intercept the access from 
EPT violation and handle it. But if guest uses that page as DMA buffer (a 
malicious guest may do it), then VT-d fault happens. Since DMA is not 
restartable, guest will never receive the right data.

> 
> Thanks
> Kevin


Best regards,
Yang



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel