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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 05.06.14 at 16:37, <ian.campbell@citrix.com> wrote:
> 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...

Indeed that would match on most if not all graphics cards.

Jan