Re: [PATCH v8 13/14] tools/libxl: explicitly grant access to needed I/O-memory ranges

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2014-06-05 at 15:31 +0100, Ian Campbell wrote:
> On Mon, 2014-05-26 at 12:15 +0100, Jan Beulich wrote:
> > >>> IHMO, the guest doesn't need to have permission to this region. When
> > >>> QEMU ask to map this region to the guest, the hypercall will only check
> > >>> the permission on the domain where QEMU is running. Therefore, the
> > >>> permission should be given to the stubdomain.
> > >>
> > >> How would qemu be involved in I/O from/to a passed through
> > >> device?
> > > 
> > > AFAIU, the mapping of the range 0xa0000-* will be done by QEMU for an 
> > > HVM guest (i.e calling xc_domain_memory_mapping).
> > 
> > If qemu is mapping this _machine_ range to every guest (or every
> > guest getting a GFX device passed through) that would be wrong
> > then too afaict.
> 
> How does this work today then? Do no guests get access to 0xa0000 or do
> we some how determine which of the multiple GFX devices is the primary
> one (with the real 0xa0000 mapped to it)?
> 
> I can't see 0xa0000 mapped by anything in xen.git and there are too many
> hits on the qemu tree for me to spot it if it is there.

Ah, here it is in qemu-trad hw/pt-graphics.c:

int register_vga_regions(struct pt_dev *real_device)
{
    u16 vendor_id;
    int ret = 0;

    if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
        return ret;

        ...
    ret |= xc_domain_memory_mapping(xc_handle, domid,
            0xa0000 >> XC_PAGE_SHIFT,
            0xa0000 >> XC_PAGE_SHIFT,
            0x20,
            DPCI_ADD_MAPPING);


AFAICT the only thing which might save us from the scenario you are
worried about would be the device_class == 0x0300 thing, but I don't see
how that could be the case...

Ian.