From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
qemu-devel@nongnu.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [Qemu-devel] [Xen-devel] [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability
Date: Mon, 14 Dec 2015 11:41:34 +0000 [thread overview]
Message-ID: <1450093294.16856.46.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1512141101150.3023@kaball.uk.xensource.com>
On Mon, 2015-12-14 at 11:19 +0000, Stefano Stabellini wrote:
> On Fri, 11 Dec 2015, Ian Campbell wrote:
> > On Fri, 2015-12-11 at 16:44 +0000, Stefano Stabellini wrote:
> > >
> > > It is not possible to do this at runtime. I think we should do this
> > > at
> > > compile time because in any case it is not supported to run a QEMU
> > > built
> > > for a given Xen version on a different Xen version.
> >
> > I am currently working pretty hard to make this possible in the future,
> > it
> > would be a shame to add another reason it wasn't possible at this
> > stage.
> >
> > I proposed (in <1445442435.9563.184.camel@citrix.com>) that as well as
> > the
> > various stable libraries extracted from libxenctrl we will probably
> > also
> > want to have a libxendevicemodel.so at some point, to provide a stable
> > way
> > to interface with all the stuff which being a DM involves.
>
> I understand the direction we are heading toward, but unfortunately we
> are still pretty far from it. I don't think we want to block this patch
> until we have a stable libxendevicemodel ABI?
No, but I would appreciate if such things were explicitly considered on a
case by case by case basis rather than just bundled under a generic "it's
not possible yet", since there may be cases where we want to hold off, or
more likely where doing something a particular way now will ease things for
the transition in the future.
> Also this particular
> change regards PCI passthrough, which is not convered by the proposed
> ABI yet.
>
>
> > Maybe that library could contain a way to get this information? (In
> > which
> > case it could be hardcoded at compile time now and I'll see what I can
> > do
> > when I get to producing the library).
>
> Given the choice, I would rather have only compile time or only run time
> Xen version checks in QEMU and not both to avoid complexity. Especially
> as long as the underlying libraries don't make any stability guarantees.
"that library" obviously will make such guarantees as a matter of design.
Ian.
WARNING: multiple messages have this Message-ID (diff)
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
qemu-devel@nongnu.org, Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability
Date: Mon, 14 Dec 2015 11:41:34 +0000 [thread overview]
Message-ID: <1450093294.16856.46.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1512141101150.3023@kaball.uk.xensource.com>
On Mon, 2015-12-14 at 11:19 +0000, Stefano Stabellini wrote:
> On Fri, 11 Dec 2015, Ian Campbell wrote:
> > On Fri, 2015-12-11 at 16:44 +0000, Stefano Stabellini wrote:
> > >
> > > It is not possible to do this at runtime. I think we should do this
> > > at
> > > compile time because in any case it is not supported to run a QEMU
> > > built
> > > for a given Xen version on a different Xen version.
> >
> > I am currently working pretty hard to make this possible in the future,
> > it
> > would be a shame to add another reason it wasn't possible at this
> > stage.
> >
> > I proposed (in <1445442435.9563.184.camel@citrix.com>) that as well as
> > the
> > various stable libraries extracted from libxenctrl we will probably
> > also
> > want to have a libxendevicemodel.so at some point, to provide a stable
> > way
> > to interface with all the stuff which being a DM involves.
>
> I understand the direction we are heading toward, but unfortunately we
> are still pretty far from it. I don't think we want to block this patch
> until we have a stable libxendevicemodel ABI?
No, but I would appreciate if such things were explicitly considered on a
case by case by case basis rather than just bundled under a generic "it's
not possible yet", since there may be cases where we want to hold off, or
more likely where doing something a particular way now will ease things for
the transition in the future.
> Also this particular
> change regards PCI passthrough, which is not convered by the proposed
> ABI yet.
>
>
> > Maybe that library could contain a way to get this information? (In
> > which
> > case it could be hardcoded at compile time now and I'll see what I can
> > do
> > when I get to producing the library).
>
> Given the choice, I would rather have only compile time or only run time
> Xen version checks in QEMU and not both to avoid complexity. Especially
> as long as the underlying libraries don't make any stability guarantees.
"that library" obviously will make such guarantees as a matter of design.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-12-14 11:42 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 15:09 [Qemu-devel] [PATCH v2 0/4] xen/pass-through: XSA-120, 128...131 follow-up Jan Beulich
2015-11-24 15:15 ` [PATCH v2 1/4] xen/MSI-X: latch MSI-X table writes Jan Beulich
2015-11-24 15:15 ` [Qemu-devel] " Jan Beulich
2015-12-07 12:41 ` Stefano Stabellini
2015-12-07 12:41 ` [Qemu-devel] " Stefano Stabellini
2015-12-07 15:57 ` Jan Beulich
2015-12-07 15:57 ` Jan Beulich
2015-12-07 16:46 ` Jan Beulich
2015-12-07 16:46 ` [Qemu-devel] " Jan Beulich
2015-12-08 10:41 ` Stefano Stabellini
2015-12-08 10:41 ` Stefano Stabellini
2015-12-08 11:09 ` [Qemu-devel] [PATCH v3 " Jan Beulich
2015-12-09 15:55 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini
2015-12-09 16:28 ` Jan Beulich
2015-12-09 16:28 ` Jan Beulich
2015-12-09 15:55 ` Stefano Stabellini
2015-12-08 11:09 ` Jan Beulich
2015-11-24 15:15 ` [Qemu-devel] [PATCH v2 2/4] xen/MSI-X: really enforce alignment Jan Beulich
2015-11-24 15:15 ` Jan Beulich
2015-11-24 15:16 ` [Qemu-devel] [PATCH v2 3/4] xen/pass-through: correctly deal with RW1C bits Jan Beulich
2015-12-07 12:43 ` Stefano Stabellini
2015-12-07 12:43 ` Stefano Stabellini
2015-11-24 15:16 ` Jan Beulich
2015-11-24 15:17 ` [Qemu-devel] [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability Jan Beulich
2015-12-07 12:45 ` Stefano Stabellini
2015-12-07 13:05 ` Jan Beulich
2015-12-07 14:56 ` Stefano Stabellini
2015-12-07 15:35 ` Jan Beulich
2015-12-07 15:35 ` [Qemu-devel] " Jan Beulich
2015-12-11 14:33 ` Stefano Stabellini
2015-12-11 14:33 ` [Qemu-devel] " Stefano Stabellini
2015-12-11 15:18 ` Jan Beulich
2015-12-11 15:18 ` [Qemu-devel] " Jan Beulich
2015-12-11 16:44 ` Stefano Stabellini
2015-12-11 16:56 ` [Qemu-devel] [Xen-devel] " Ian Campbell
2015-12-14 8:02 ` Jan Beulich
2015-12-14 8:02 ` [Qemu-devel] [Xen-devel] " Jan Beulich
2015-12-14 11:23 ` Stefano Stabellini
2015-12-14 11:23 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini
2015-12-14 11:19 ` Stefano Stabellini
2015-12-14 11:19 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini
2015-12-14 11:41 ` Ian Campbell [this message]
2015-12-14 11:41 ` Ian Campbell
2015-12-14 16:01 ` [Qemu-devel] [Xen-devel] " Jan Beulich
2015-12-14 16:27 ` Stefano Stabellini
2015-12-14 16:27 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini
2015-12-14 16:01 ` Jan Beulich
2015-12-11 16:56 ` Ian Campbell
2015-12-11 16:44 ` Stefano Stabellini
2015-12-07 14:56 ` Stefano Stabellini
2015-12-07 13:05 ` Jan Beulich
2015-12-07 12:45 ` Stefano Stabellini
2015-11-24 15:17 ` Jan Beulich
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=1450093294.16856.46.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=qemu-devel@nongnu.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.