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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> 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-virtualizatio
> >>>>>>>> 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. 

Thanks
Kevin

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