From: "Jan Beulich" <JBeulich@suse.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: tim@xen.org, paolo.valente@unimore.it, keir@xen.org,
stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com,
dario.faggioli@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, julien.grall@citrix.com,
Sander Eikelenboom <linux@eikelenboom.it>,
etrudeau@broadcom.com,
Arianna Avanzini <avanzini.arianna@gmail.com>,
viktor.kleinik@globallogic.com
Subject: Re: [PATCH v9 12/14] tools/libxl: read from config if passing through primary GPU
Date: Thu, 03 Jul 2014 16:37:35 +0100 [thread overview]
Message-ID: <53B594DF02000078000205EB@mail.emea.novell.com> (raw)
In-Reply-To: <1404401156.10477.4.camel@kazak.uk.xensource.com>
>>> On 03.07.14 at 17:25, <Ian.Campbell@citrix.com> wrote:
> On Thu, 2014-07-03 at 16:17 +0100, Jan Beulich wrote:
>> >>> On 03.07.14 at 16:53, <Ian.Campbell@citrix.com> wrote:
>> > On Thu, 2014-07-03 at 15:50 +0100, Ian Campbell wrote:
>> >> What specifically should Arianna be looking for? THe PCI device class or
>> >> something else?
>> >
>> > Qemu-trad seems to use:
>> > if ( !gfx_passthru || real_device->pci_dev->device_class != 0x0300 )
>> > return ret;
>> >
>> > Is that sufficient?
>>
>> I don't think so - I'd expect secondary cards to also be showing this
>> class/sub-class (but I have no system with two or more cards where
>> I could at least empirically check), i.e. that would only be sufficient
>> when there's no upstream bridge. PCI_BRIDGE_CTL_VGA (on
>> upstream bridges) and maybe (but unlikely)
>> PCI_COMMAND_VGA_PALETTE (on the device itself and perhaps also
>> upstream bridges) would seem to be the indicators. But I'm afraid
>> this really needs to be properly answered by a PCI expert.
>
> Hrm, I'm not sure I see that happening any time soon...
>
> Given that the above class-based check has apparently been fine since
> however long could we live with it in the context of this series?
As said on an earlier version of the series - this is tools code, so
ultimately you judge. I'm merely pointing out that we're apparently
spreading a pre-existing shortcoming.
Jan
next prev parent reply other threads:[~2014-07-03 15:37 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 18:42 [PATCH v9 00/14] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 01/14] arch/arm: add consistency check to REMOVE p2m changes Arianna Avanzini
2014-07-03 10:24 ` Julien Grall
2014-07-03 11:03 ` Julien Grall
2014-07-03 14:28 ` Ian Campbell
2014-07-03 14:44 ` Julien Grall
2014-07-02 18:42 ` [PATCH v9 02/14] arch/arm: let map_mmio_regions() take pfn as parameters Arianna Avanzini
2014-07-03 10:26 ` Julien Grall
2014-07-02 18:42 ` [PATCH v9 03/14] arch/arm: let map_mmio_regions() use start and count Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 04/14] arch/arm: unmap partially-mapped I/O-memory regions Arianna Avanzini
2014-07-03 14:40 ` Ian Campbell
2014-07-03 15:00 ` Julien Grall
2014-07-03 15:15 ` Ian Campbell
2014-07-02 18:42 ` [PATCH v9 05/14] arch/x86: warn if to-be-removed mapping does not exist Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 06/14] arch/x86: cleanup memory_mapping DOMCTL Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 07/14] xen/common: add ARM stub for the function memory_type_changed() Arianna Avanzini
2014-07-03 14:41 ` Ian Campbell
2014-07-02 18:42 ` [PATCH v9 08/14] xen/x86: factor out map and unmap from the memory_mapping DOMCTL Arianna Avanzini
2014-07-03 10:43 ` Jan Beulich
2014-07-02 18:42 ` [PATCH v9 09/14] xen/common: move the memory_mapping DOMCTL hypercall to common code Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 10/14] tools/libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 11/14] tools/libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 12/14] tools/libxl: read from config if passing through primary GPU Arianna Avanzini
2014-07-02 19:00 ` Sander Eikelenboom
2014-07-03 10:30 ` Jan Beulich
2014-07-03 10:49 ` Sander Eikelenboom
2014-07-03 10:58 ` Jan Beulich
2014-07-03 14:50 ` Ian Campbell
2014-07-03 14:53 ` Ian Campbell
2014-07-03 15:17 ` Jan Beulich
2014-07-03 15:25 ` Ian Campbell
2014-07-03 15:37 ` Jan Beulich [this message]
2014-07-03 16:11 ` Ian Campbell
2014-07-03 15:45 ` Sander Eikelenboom
2014-07-03 14:47 ` Ian Campbell
2014-07-02 18:42 ` [PATCH v9 13/14] tools/libxl: explicitly grant access to needed I/O-memory ranges Arianna Avanzini
2014-07-02 18:42 ` [PATCH v9 14/14] xen/common: do not implicitly permit access to mapped I/O memory Arianna Avanzini
2014-07-11 13:51 ` [PATCH v9 00/14] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Julien Grall
2014-07-11 14:24 ` Ian Campbell
2014-07-11 17:00 ` Arianna Avanzini
2014-07-14 8:54 ` Ian Campbell
2014-07-14 9:22 ` Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND " Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 01/14] arch/arm: add consistency check to REMOVE p2m changes Arianna Avanzini
2014-07-14 10:57 ` Julien Grall
2014-07-17 12:56 ` Ian Campbell
2014-07-14 0:50 ` [PATCH RESEND v9 02/14] arch/arm: let map_mmio_regions() take pfn as parameters Arianna Avanzini
2014-07-17 12:57 ` Ian Campbell
2014-07-18 12:43 ` Ian Campbell
2014-07-14 0:50 ` [PATCH RESEND v9 03/14] arch/arm: let map_mmio_regions() use start and count Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 04/14] arch/arm: unmap partially-mapped I/O-memory regions Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 05/14] arch/x86: warn if to-be-removed mapping does not exist Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 06/14] arch/x86: cleanup memory_mapping DOMCTL Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 07/14] xen/common: add ARM stub for the function memory_type_changed() Arianna Avanzini
2014-07-17 12:59 ` Ian Campbell
2014-07-24 14:07 ` Julien Grall
2014-07-14 0:50 ` [PATCH RESEND v9 08/14] xen/x86: factor out map and unmap from the memory_mapping DOMCTL Arianna Avanzini
2014-07-17 13:00 ` Ian Campbell
2014-07-23 11:59 ` Jan Beulich
2014-07-23 12:54 ` Arianna Avanzini
2014-07-23 13:04 ` Ian Campbell
2014-07-14 0:50 ` [PATCH RESEND v9 09/14] xen/common: move the memory_mapping DOMCTL hypercall to common code Arianna Avanzini
2014-07-24 14:10 ` Julien Grall
2014-07-14 0:50 ` [PATCH RESEND v9 10/14] tools/libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 11/14] tools/libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-07-24 14:12 ` Julien Grall
2014-07-14 0:50 ` [PATCH RESEND v9 12/14] tools/libxl: read from config if passing through primary GPU Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 13/14] tools/libxl: explicitly grant access to needed I/O-memory ranges Arianna Avanzini
2014-07-14 0:50 ` [PATCH RESEND v9 14/14] xen/common: do not implicitly permit access to mapped I/O memory Arianna Avanzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B594DF02000078000205EB@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=avanzini.arianna@gmail.com \
--cc=dario.faggioli@citrix.com \
--cc=etrudeau@broadcom.com \
--cc=julien.grall@citrix.com \
--cc=keir@xen.org \
--cc=linux@eikelenboom.it \
--cc=paolo.valente@unimore.it \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=viktor.kleinik@globallogic.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).