[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PCI Device Subtree Change from Traditional to Upstream



> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@xxxxxxxxxx]
> Sent: 08 April 2019 10:47
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; Anthony Perard 
> <anthony.perard@xxxxxxxxxx>
> Cc: Kevin Stange <kevin@xxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to 
> Upstream
> 
> On 1/26/18 10:38 AM, Paul Durrant wrote:
> >> -----Original Message-----
> >> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> >> Of George Dunlap
> >> Sent: 25 January 2018 18:15
> >> To: Anthony Perard <anthony.perard@xxxxxxxxxx>
> >> Cc: Kevin Stange <kevin@xxxxxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx;
> >> George Dunlap <George.Dunlap@xxxxxxxxxx>
> >> Subject: Re: [Xen-devel] PCI Device Subtree Change from Traditional to
> >> Upstream
> >>
> >> On 01/25/2018 06:04 PM, Anthony PERARD wrote:
> >>> On Thu, Jan 25, 2018 at 05:54:36PM +0000, George Dunlap wrote:
> >>>> On 01/04/2018 12:52 PM, Anthony PERARD wrote:
> >>>>> From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> >>>>> Subject: [PATCH] libxl_dm: Explicitly put xen-platform device on PCI 
> >>>>> slot
> >> 3
> >>>>>
> >>>>> In order to do that, we don't use xenfv machine anymore and explicity
> >>>>> add the platform device on the command line.
> >>>>>
> >>>>> Signed-off-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
> >>>>
> >>>> Anthony,
> >>>>
> >>>> It seems like we might want to add the ability to specify which slot we
> >>>> want the xen-platform device to occupy. Is it worth thinking of the best
> >>>> way to add a patch like this upstream?
> >>>
> >>> I think that would be nice for people who switch from qemu-trad to
> >>> QEMU. The only question that remain is, how to name the xl config
> >>> option?  The rest is to simply take my libxl patch and make it use
> >>> the new config option.
> >>
> >> Well the other half would be to make sure something like this doesn't
> >> happen by accident in the future -- i.e., that no future changes in QEMU
> >> will accidentally move it away from whatever the current slot is now.
> >>
> >
> > IMO, it would be best if libxl specified the bus topology exactly (i.e. 
> > specified devfn for
> everything that appears on the bus). If we, as I hope, make a move to having 
> Xen rather than QEMU own
> the topology then this should hopefully ensure at least some degree of 
> forward compatibility.
> 
> Is this on anybody's radar?  It seems like this wouldn't be a huge
> amount of work, and it would prevent this sort of compatibility issue in
> the future.

This very topic came up in relation to the XAPI toolstack last week. It would 
definitely be good to have commonality with libxl on this but I'm not aware of 
anyone working on this.

  Paul

> 
>  -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.