Re: [Xen-devel] [PATCH] x86/MSI: add mechanism to protect MSI-X table from PV guest accesses

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-02-07 at 08:44 +0000, Jan Beulich wrote:
> >>> On 06.02.13 at 17:50, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > This adds two new physdev operations for Dom0 to invoke when resource
> > allocation for devices is known to be complete, so that the hypervisor
> > can arrange for the respective MMIO ranges to be marked read-only
> > before an eventual guest getting such a device assigned even gets
> > started, such that it won't be able to set up writable mappings for
> > these MMIO ranges before Xen has a chance to protect them.

This sounds reasonable, is the "when resource allocation ... complete"
difficult to assess or likely to be fragile going forward?

> I should probably mention the alternatives:
> 
> 1) Brute force scan of the (PV) guest's L1 page tables, locating
> eventual mappings of the questionable MMIO pages, and
> converting those mappings to R/O ones.

When would this occur? Just on setup (might be ok) or on any MMU update
(clearly not) or some middle ground (like only DOMID_IO mappings
perhaps)?

> 2) Snoop BAR modifications (via xen/arch/x86/traps.c:
> guest_io_write(), taking note of which BAR(s) are relevant at the
> point where the device gets first detected/reported), perhaps
> along with snoops of the PCI_COMMAND_MEMORY bit.

Do these modifications come straight from the guest, or do they come
from dom0 via pciback and/or dom0's own PCI subsystem setup? If these
are coming via pciback then it seems reasonable to me to use physdev
operations, which takes us back to the patch you've implemented I think.

Trapping and emulating them sounds like something to avoid even if these
are not especially hot paths.

Ian.


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