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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.02.13 at 09:44, "Jan Beulich" <JBeulich@xxxxxxxx> 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.
> 
> 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.
> 
> 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.

So I just now sent a mail to Linux'es PCI subsystem maintainer,
assuming that we'll go with the approach the patch presented at
the start of this thread. The outcome of this, however, is not
really relevant for the hypervisor side change to go in, as it
would only affect the placement of the new hypercall within
pciback or the core PCI subsystem.

That assumption is largely because no-one really voiced an opinion
towards a preference of one of the alternatives described above.

Unless I'll receive an explicit NAK or further comments moving this
discussion forward, I'm intending to commit the patch without
anyone's ACK in a few days time _and_ backport it to the stable
trees (4.2 at least, not sure how well it will backport to 4.1).

Jan


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