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

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

> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, August 14, 2014 1:25 PM
> 
> At 17:49 +0000 on 14 Aug (1408034941), Tian, Kevin wrote:
> > > From: Tim Deegan [mailto:tim@xxxxxxx]
> > > > Could we introduce a cpu-write-protection attribute only for functional
> > > > usages which don't care about DMA path like in XenGT?
> > >
> > > Possibly.  Sorry for going over things that have probably already been
> > > covered but AIUI you are saying that XenGT needs to allow full DMA access
> > > to this memory area but only read-only CPU access.  If that's what's
> > > needed then I think a new type with these semantics is the best way of
> > > doing it (and requiring no shared IOMMU/HAP tables).  But:
> >
> > It's about GPU page table write-protection, so XenGT needs to trap
> > writes in both CPU/DMA paths:
> >
> > * CPU writes are captured by read-only permission in EPT
> > * GPU writes are captured by scanning GPU commands before they're
> > submitted for execution, as part of the 'mediation' concept in XenGT
> > mediated pass-through architecture.
> >
> > Note XenGT doesn't use IOMMU because w/o SR-IOV a single device
> > entry can't be used to server multiple VMs.
> 
> Oh, I see.  So you don't actually want the GPUPTs mapped for DMA at
> all.  That's much easier.
> 
> > So XenGT can achieve true 'write-protection' w/o IOMMU restarting
> > fault support. However it's very GPU specific. As a general implementation,
> > I think a new type with below semantics should be enough:
> >
> > - only CPU access to the protected area, so it's removed from IOMMU
> > page table
> > - require IOMMU/HAP seperate
> 
> I think we might want to make those tables separate in general.  IIRC we
> were discussing that in another thread already.  But that aside, I think
> a plain read-only mapping will DTRT for you -- it allows read-only DMA
> from the GPUPTs, but that's no worse that the read-only CPU mapping.

for 'plain read-only mapping' you mean existing p2m_ram_ro? 

btw just curious how we handle p2m_ram_ro today. Does it play any trick
to fail-safe in IOMMU side, e.g. zap the mapping or not? Otherwise when
it allows read-only DMA there's no way to prevent DMA writes either. :-)


> 
> After that, the only odd behaviour is that you're emulating writes to
> read-only memory.  And that's where the new type is helpful: to say
> that we should be emulating writes rather than dropping them.

so p2m_mmio_write_dm would go together with existing p2m_ram_ro
in most condition checks, with only difference on final policy of emulation 
vs. drop.

> 
> > How would you call such a new type then? just p2m_write_protection
> > or p2m_cpu_write_protection? (still need to differentiate write-protection
> > from read-only, since the latter implies no writes)
> 
> p2m_mmio_write_dm?
> 
> Now that (I hope) I understand better what you need, I can see how
> just using plain mmio_dm and emulating reads would be a plausible
> solution too.  So I think I'd be happy with either that or a new type.
> 

yes either way works. for now let's try the new p2m type since it
is more intuitive regarding to 'write-protection'. :-)

Thanks
Kevin

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