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

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



> 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:
> 
> >
> >> -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> >> Sent: Monday, July 28, 2014 4:25 PM
> >> To: Ye, Wei
> >> Cc: ian.campbell@xxxxxxxxxx; Paul.Durrant@xxxxxxxxxx;
> >> ian.jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx; xen-
> >> 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-virtualization-
> >> > 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?

Thanks
Kevin

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.