[Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
When QEMU restricts its xenstore connection, it cannot provide PV
backends. A separate QEMU instance is required to provide PV backends in
userspace, such as qdisk. With two separate instances, it is not
possible to take advantage of vkb for mouse and keyboard, as the QEMU
that emulates the graphic card (the device model), would be separate
from the QEMU running the vkb backend (PV QEMU).
Signed-off-by: Stefano Stabellini
---
tools/libxl/libxl_create.c |5 -
1 file changed, 5 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f0da7dc..a74b340 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1275,17 +1275,12 @@ static void domcreate_launch_dm(libxl__egc *egc,
libxl__multidev *multidev,
{
libxl__device_console console;
libxl__device device;
-libxl_device_vkb vkb;
init_console_info(gc, &console, 0);
console.backend_domid = state->console_domid;
libxl__device_console_add(gc, domid, &console, state, &device);
libxl__device_console_dispose(&console);
-libxl_device_vkb_init(&vkb);
-libxl__device_vkb_add(gc, domid, &vkb);
-libxl_device_vkb_dispose(&vkb);
-
dcs->dmss.dm.guest_domid = domid;
if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
libxl__spawn_stub_dm(egc, &dcs->dmss);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote:
> When QEMU restricts its xenstore connection, it cannot provide PV
> backends. A separate QEMU instance is required to provide PV backends in
> userspace, such as qdisk. With two separate instances, it is not
> possible to take advantage of vkb for mouse and keyboard, as the QEMU
> that emulates the graphic card (the device model), would be separate
> from the QEMU running the vkb backend (PV QEMU).
>
The question is that how would this affect the non-split setup.
But do I understand correctly we are moving towards a split setup
regardlessly whether QEMU supports xsrestrict or not? I.e. there is no
non-split setup in the future.
Wei.
> Signed-off-by: Stefano Stabellini
> ---
> tools/libxl/libxl_create.c |5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f0da7dc..a74b340 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1275,17 +1275,12 @@ static void domcreate_launch_dm(libxl__egc *egc,
> libxl__multidev *multidev,
> {
> libxl__device_console console;
> libxl__device device;
> -libxl_device_vkb vkb;
>
> init_console_info(gc, &console, 0);
> console.backend_domid = state->console_domid;
> libxl__device_console_add(gc, domid, &console, state, &device);
> libxl__device_console_dispose(&console);
>
> -libxl_device_vkb_init(&vkb);
> -libxl__device_vkb_add(gc, domid, &vkb);
> -libxl_device_vkb_dispose(&vkb);
> -
> dcs->dmss.dm.guest_domid = domid;
> if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
> libxl__spawn_stub_dm(egc, &dcs->dmss);
> --
> 1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 16 Jun 2015, Wei Liu wrote:
> On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote:
> > When QEMU restricts its xenstore connection, it cannot provide PV
> > backends. A separate QEMU instance is required to provide PV backends in
> > userspace, such as qdisk. With two separate instances, it is not
> > possible to take advantage of vkb for mouse and keyboard, as the QEMU
> > that emulates the graphic card (the device model), would be separate
> > from the QEMU running the vkb backend (PV QEMU).
> >
>
> The question is that how would this affect the non-split setup.
vkb is useful because emulating usb forces QEMU to wake up more often.
However there is no way around it.
> But do I understand correctly we are moving towards a split setup
> regardlessly whether QEMU supports xsrestrict or not? I.e. there is no
> non-split setup in the future.
Yes, that is my intention.
> > Signed-off-by: Stefano Stabellini
> > ---
> > tools/libxl/libxl_create.c |5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index f0da7dc..a74b340 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1275,17 +1275,12 @@ static void domcreate_launch_dm(libxl__egc *egc,
> > libxl__multidev *multidev,
> > {
> > libxl__device_console console;
> > libxl__device device;
> > -libxl_device_vkb vkb;
> >
> > init_console_info(gc, &console, 0);
> > console.backend_domid = state->console_domid;
> > libxl__device_console_add(gc, domid, &console, state, &device);
> > libxl__device_console_dispose(&console);
> >
> > -libxl_device_vkb_init(&vkb);
> > -libxl__device_vkb_add(gc, domid, &vkb);
> > -libxl_device_vkb_dispose(&vkb);
> > -
> > dcs->dmss.dm.guest_domid = domid;
> > if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
> > libxl__spawn_stub_dm(egc, &dcs->dmss);
> > --
> > 1.7.10.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > On Tue, 16 Jun 2015, Wei Liu wrote: > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote: > > > When QEMU restricts its xenstore connection, it cannot provide PV > > > backends. A separate QEMU instance is required to provide PV backends in > > > userspace, such as qdisk. With two separate instances, it is not > > > possible to take advantage of vkb for mouse and keyboard, as the QEMU > > > that emulates the graphic card (the device model), would be separate > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > The question is that how would this affect the non-split setup. > > vkb is useful because emulating usb forces QEMU to wake up more often. > However there is no way around it. Does pvfb+vkb continue to work due to code somewhere else? Do we think anyone will actually be using emulated VGA + PV input devices? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Thu, 25 Jun 2015, Ian Campbell wrote: > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote: > > > > When QEMU restricts its xenstore connection, it cannot provide PV > > > > backends. A separate QEMU instance is required to provide PV backends in > > > > userspace, such as qdisk. With two separate instances, it is not > > > > possible to take advantage of vkb for mouse and keyboard, as the QEMU > > > > that emulates the graphic card (the device model), would be separate > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > The question is that how would this affect the non-split setup. > > > > vkb is useful because emulating usb forces QEMU to wake up more often. > > However there is no way around it. > > Does pvfb+vkb continue to work due to code somewhere else? Yes, it continues to work as usual for PV guests. > Do we think anyone will actually be using emulated VGA + PV input > devices? VGA + PV input only works with Linux and is only useful for power efficiency, because if you disable usb emulation in QEMU, then QEMU would be able to wake up less often. Given that usb emulation is still on by default, I don't think that this change will have a big impact. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > On Thu, 25 Jun 2015, Ian Campbell wrote: > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote: > > > > > When QEMU restricts its xenstore connection, it cannot provide PV > > > > > backends. A separate QEMU instance is required to provide PV backends > > > > > in > > > > > userspace, such as qdisk. With two separate instances, it is not > > > > > possible to take advantage of vkb for mouse and keyboard, as the QEMU > > > > > that emulates the graphic card (the device model), would be separate > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > The question is that how would this affect the non-split setup. > > > > > > vkb is useful because emulating usb forces QEMU to wake up more often. > > > However there is no way around it. > > > > Does pvfb+vkb continue to work due to code somewhere else? > > Yes, it continues to work as usual for PV guests. > > > > Do we think anyone will actually be using emulated VGA + PV input > > devices? > > VGA + PV input only works with Linux and is only useful for power > efficiency, because if you disable usb emulation in QEMU, then QEMU > would be able to wake up less often. Given that usb emulation is still > on by default, I don't think that this change will have a big impact. My question was whether we thought anyone would be using this non-default configuration, not what the impact on the default is. You gave a good reason why people might be using this facility, do you think anyone is actually using it? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 30 Jun 2015, Ian Campbell wrote: > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote: > > > > > > When QEMU restricts its xenstore connection, it cannot provide PV > > > > > > backends. A separate QEMU instance is required to provide PV > > > > > > backends in > > > > > > userspace, such as qdisk. With two separate instances, it is not > > > > > > possible to take advantage of vkb for mouse and keyboard, as the > > > > > > QEMU > > > > > > that emulates the graphic card (the device model), would be separate > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > The question is that how would this affect the non-split setup. > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up more often. > > > > However there is no way around it. > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > Yes, it continues to work as usual for PV guests. > > > > > > > Do we think anyone will actually be using emulated VGA + PV input > > > devices? > > > > VGA + PV input only works with Linux and is only useful for power > > efficiency, because if you disable usb emulation in QEMU, then QEMU > > would be able to wake up less often. Given that usb emulation is still > > on by default, I don't think that this change will have a big impact. > > My question was whether we thought anyone would be using this > non-default configuration, not what the impact on the default is. > > You gave a good reason why people might be using this facility, do you > think anyone is actually using it? I don't know of anybody using it. I don't think we made clear enough how to use this non-default configuration and its advantages for users to go out of their ways to use it. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > On Tue, 30 Jun 2015, Ian Campbell wrote: > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini wrote: > > > > > > > When QEMU restricts its xenstore connection, it cannot provide PV > > > > > > > backends. A separate QEMU instance is required to provide PV > > > > > > > backends in > > > > > > > userspace, such as qdisk. With two separate instances, it is not > > > > > > > possible to take advantage of vkb for mouse and keyboard, as the > > > > > > > QEMU > > > > > > > that emulates the graphic card (the device model), would be > > > > > > > separate > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split setup. > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up more often. > > > > > However there is no way around it. > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV input > > > > devices? > > > > > > VGA + PV input only works with Linux and is only useful for power > > > efficiency, because if you disable usb emulation in QEMU, then QEMU > > > would be able to wake up less often. Given that usb emulation is still > > > on by default, I don't think that this change will have a big impact. > > > > My question was whether we thought anyone would be using this > > non-default configuration, not what the impact on the default is. > > > > You gave a good reason why people might be using this facility, do you > > think anyone is actually using it? > > I don't know of anybody using it. I don't think we made clear enough how > to use this non-default configuration and its advantages for users to go > out of their ways to use it. That's good enough for me, thanks,. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 30 Jun 2015, Ian Campbell wrote: > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini > > > > > > > wrote: > > > > > > > > When QEMU restricts its xenstore connection, it cannot provide > > > > > > > > PV > > > > > > > > backends. A separate QEMU instance is required to provide PV > > > > > > > > backends in > > > > > > > > userspace, such as qdisk. With two separate instances, it is not > > > > > > > > possible to take advantage of vkb for mouse and keyboard, as > > > > > > > > the QEMU > > > > > > > > that emulates the graphic card (the device model), would be > > > > > > > > separate > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split setup. > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up more > > > > > > often. > > > > > > However there is no way around it. > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV input > > > > > devices? > > > > > > > > VGA + PV input only works with Linux and is only useful for power > > > > efficiency, because if you disable usb emulation in QEMU, then QEMU > > > > would be able to wake up less often. Given that usb emulation is still > > > > on by default, I don't think that this change will have a big impact. > > > > > > My question was whether we thought anyone would be using this > > > non-default configuration, not what the impact on the default is. > > > > > > You gave a good reason why people might be using this facility, do you > > > think anyone is actually using it? > > > > I don't know of anybody using it. I don't think we made clear enough how > > to use this non-default configuration and its advantages for users to go > > out of their ways to use it. > > That's good enough for me, thanks,. Can I add your acked-by? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote: > On Tue, 30 Jun 2015, Ian Campbell wrote: > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini > > > > > > > > wrote: > > > > > > > > > When QEMU restricts its xenstore connection, it cannot > > > > > > > > > provide PV > > > > > > > > > backends. A separate QEMU instance is required to provide PV > > > > > > > > > backends in > > > > > > > > > userspace, such as qdisk. With two separate instances, it is > > > > > > > > > not > > > > > > > > > possible to take advantage of vkb for mouse and keyboard, as > > > > > > > > > the QEMU > > > > > > > > > that emulates the graphic card (the device model), would be > > > > > > > > > separate > > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split setup. > > > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up more > > > > > > > often. > > > > > > > However there is no way around it. > > > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV input > > > > > > devices? > > > > > > > > > > VGA + PV input only works with Linux and is only useful for power > > > > > efficiency, because if you disable usb emulation in QEMU, then QEMU > > > > > would be able to wake up less often. Given that usb emulation is still > > > > > on by default, I don't think that this change will have a big impact. > > > > > > > > My question was whether we thought anyone would be using this > > > > non-default configuration, not what the impact on the default is. > > > > > > > > You gave a good reason why people might be using this facility, do you > > > > think anyone is actually using it? > > > > > > I don't know of anybody using it. I don't think we made clear enough how > > > to use this non-default configuration and its advantages for users to go > > > out of their ways to use it. > > > > That's good enough for me, thanks,. > > Can I add your acked-by? If you put some distillation of the reasoning given in this subthread for why we think we can get away with it into the commit message then yes. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, Jun 30, 2015 at 03:13:53PM +0100, Ian Campbell wrote: > On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote: > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano Stabellini > > > > > > > > > wrote: > > > > > > > > > > When QEMU restricts its xenstore connection, it cannot > > > > > > > > > > provide PV > > > > > > > > > > backends. A separate QEMU instance is required to provide > > > > > > > > > > PV backends in > > > > > > > > > > userspace, such as qdisk. With two separate instances, it > > > > > > > > > > is not > > > > > > > > > > possible to take advantage of vkb for mouse and keyboard, > > > > > > > > > > as the QEMU > > > > > > > > > > that emulates the graphic card (the device model), would be > > > > > > > > > > separate > > > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split > > > > > > > > > setup. > > > > > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up more > > > > > > > > often. > > > > > > > > However there is no way around it. > > > > > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV input > > > > > > > devices? > > > > > > > > > > > > VGA + PV input only works with Linux and is only useful for power > > > > > > efficiency, because if you disable usb emulation in QEMU, then QEMU > > > > > > would be able to wake up less often. Given that usb emulation is > > > > > > still > > > > > > on by default, I don't think that this change will have a big > > > > > > impact. > > > > > > > > > > My question was whether we thought anyone would be using this > > > > > non-default configuration, not what the impact on the default is. > > > > > > > > > > You gave a good reason why people might be using this facility, do you > > > > > think anyone is actually using it? > > > > > > > > I don't know of anybody using it. I don't think we made clear enough how > > > > to use this non-default configuration and its advantages for users to go > > > > out of their ways to use it. > > > > > > That's good enough for me, thanks,. > > > > Can I add your acked-by? > > If you put some distillation of the reasoning given in this subthread > for why we think we can get away with it into the commit message then > yes. Why don't we also make the Linux code not expose this driver for HVM guests? I've had an go for this last year (can't find the link) as it would unduly cause the Linux kernel to take an extra 30 seconds to boot. That is because 'xend' by default exposes the PV configuration even for HVM guests - and of course there are no PV drivers (as the VGA in QEMU is enabled). The only use case I had was for ARM - where there are no VGA - and the patch I think I had just disabled the xen-fbfront under X86 HVM. Thanks. > > Ian. > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Tue, 30 Jun 2015, Konrad Rzeszutek Wilk wrote: > On Tue, Jun 30, 2015 at 03:13:53PM +0100, Ian Campbell wrote: > > On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote: > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano > > > > > > > > > > Stabellini wrote: > > > > > > > > > > > When QEMU restricts its xenstore connection, it cannot > > > > > > > > > > > provide PV > > > > > > > > > > > backends. A separate QEMU instance is required to provide > > > > > > > > > > > PV backends in > > > > > > > > > > > userspace, such as qdisk. With two separate instances, it > > > > > > > > > > > is not > > > > > > > > > > > possible to take advantage of vkb for mouse and keyboard, > > > > > > > > > > > as the QEMU > > > > > > > > > > > that emulates the graphic card (the device model), would > > > > > > > > > > > be separate > > > > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split > > > > > > > > > > setup. > > > > > > > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up > > > > > > > > > more often. > > > > > > > > > However there is no way around it. > > > > > > > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV > > > > > > > > input > > > > > > > > devices? > > > > > > > > > > > > > > VGA + PV input only works with Linux and is only useful for power > > > > > > > efficiency, because if you disable usb emulation in QEMU, then > > > > > > > QEMU > > > > > > > would be able to wake up less often. Given that usb emulation is > > > > > > > still > > > > > > > on by default, I don't think that this change will have a big > > > > > > > impact. > > > > > > > > > > > > My question was whether we thought anyone would be using this > > > > > > non-default configuration, not what the impact on the default is. > > > > > > > > > > > > You gave a good reason why people might be using this facility, do > > > > > > you > > > > > > think anyone is actually using it? > > > > > > > > > > I don't know of anybody using it. I don't think we made clear enough > > > > > how > > > > > to use this non-default configuration and its advantages for users to > > > > > go > > > > > out of their ways to use it. > > > > > > > > That's good enough for me, thanks,. > > > > > > Can I add your acked-by? > > > > If you put some distillation of the reasoning given in this subthread > > for why we think we can get away with it into the commit message then > > yes. > > Why don't we also make the Linux code not expose this driver for HVM guests? > > I've had an go for this last year (can't find the link) as it would unduly > cause the Linux kernel to take an extra 30 seconds to boot. That is because > 'xend' by default exposes the PV configuration even for HVM guests - and of > course there are no PV drivers (as the VGA in QEMU is enabled). But even with xend it only happens with a vfb line is in the config file, right? That's why we didn't fix it back when the issue was reported, if I remember correctly. > The only use case I had was for ARM - where there are no VGA - and the > patch I think I had just disabled the xen-fbfront under X86 HVM. Yeah, we need xen-fbfront for ARM. Given that xen-fbfront is likely to go away for HVM guests, I wouldn't be opposed to stop the driver initialization in Linux on x86/HVM. Unless Roger's work on HVMlite is going to need xen-fbfront again, but in that case we'll be able to distinguish a regular HVM guest from an HVMlite guest, I think. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
El 01/07/15 a les 12.29, Stefano Stabellini ha escrit: > Given that xen-fbfront is likely to go away for HVM guests, I wouldn't > be opposed to stop the driver initialization in Linux on x86/HVM. Unless > Roger's work on HVMlite is going to need xen-fbfront again, but in that > case we'll be able to distinguish a regular HVM guest from an HVMlite > guest, I think. I haven't get to that point yet, but yes, it seems useful for HVMlite guests because we won't have an emulated VGA card any more. HVMlite guest can be easily identified because they set the device model to none: device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE For HVMlite. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Wed, 1 Jul 2015, Roger Pau Monné wrote: > El 01/07/15 a les 12.29, Stefano Stabellini ha escrit: > > Given that xen-fbfront is likely to go away for HVM guests, I wouldn't > > be opposed to stop the driver initialization in Linux on x86/HVM. Unless > > Roger's work on HVMlite is going to need xen-fbfront again, but in that > > case we'll be able to distinguish a regular HVM guest from an HVMlite > > guest, I think. > > I haven't get to that point yet, but yes, it seems useful for HVMlite > guests because we won't have an emulated VGA card any more. > > HVMlite guest can be easily identified because they set the device model > to none: > > device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE What about the guest side? Are they going to be hvm guests from Linux POV? Or something else?___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
Il 01/07/2015 12:55, Roger Pau Monné ha scritto: El 01/07/15 a les 12.29, Stefano Stabellini ha escrit: Given that xen-fbfront is likely to go away for HVM guests, I wouldn't be opposed to stop the driver initialization in Linux on x86/HVM. Unless Roger's work on HVMlite is going to need xen-fbfront again, but in that case we'll be able to distinguish a regular HVM guest from an HVMlite guest, I think. I haven't get to that point yet, but yes, it seems useful for HVMlite guests because we won't have an emulated VGA card any more. If you don't want have emulated vga you can already do it fast in xl cfg: vga="none" Note: emulated vga is used by spice and vnc of hvm domUs, without connecting with them you'll have black screen. HVMlite guest can be easily identified because they set the device model to none: device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE For HVMlite. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
El 01/07/15 a les 12.56, Stefano Stabellini ha escrit: > On Wed, 1 Jul 2015, Roger Pau Monné wrote: >> El 01/07/15 a les 12.29, Stefano Stabellini ha escrit: >>> Given that xen-fbfront is likely to go away for HVM guests, I wouldn't >>> be opposed to stop the driver initialization in Linux on x86/HVM. Unless >>> Roger's work on HVMlite is going to need xen-fbfront again, but in that >>> case we'll be able to distinguish a regular HVM guest from an HVMlite >>> guest, I think. >> >> I haven't get to that point yet, but yes, it seems useful for HVMlite >> guests because we won't have an emulated VGA card any more. >> >> HVMlite guest can be easily identified because they set the device model >> to none: >> >> device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE > > What about the guest side? Are they going to be hvm guests from Linux > POV? Or something else? That's not set on stone, they could certainly be HVM guests depending on the implementation that each OS has. IMHO from a guest POV the interface exposed is very similar to PVH, so in order to ease the implementation I think they should be considered PVH guests from Linux POV, we can always move them to being HVM guests later if needed. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Wed, Jul 01, 2015 at 11:29:46AM +0100, Stefano Stabellini wrote: > On Tue, 30 Jun 2015, Konrad Rzeszutek Wilk wrote: > > On Tue, Jun 30, 2015 at 03:13:53PM +0100, Ian Campbell wrote: > > > On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote: > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano > > > > > > > > > > > Stabellini wrote: > > > > > > > > > > > > When QEMU restricts its xenstore connection, it cannot > > > > > > > > > > > > provide PV > > > > > > > > > > > > backends. A separate QEMU instance is required to > > > > > > > > > > > > provide PV backends in > > > > > > > > > > > > userspace, such as qdisk. With two separate instances, > > > > > > > > > > > > it is not > > > > > > > > > > > > possible to take advantage of vkb for mouse and > > > > > > > > > > > > keyboard, as the QEMU > > > > > > > > > > > > that emulates the graphic card (the device model), > > > > > > > > > > > > would be separate > > > > > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the non-split > > > > > > > > > > > setup. > > > > > > > > > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake up > > > > > > > > > > more often. > > > > > > > > > > However there is no way around it. > > > > > > > > > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV > > > > > > > > > input > > > > > > > > > devices? > > > > > > > > > > > > > > > > VGA + PV input only works with Linux and is only useful for > > > > > > > > power > > > > > > > > efficiency, because if you disable usb emulation in QEMU, then > > > > > > > > QEMU > > > > > > > > would be able to wake up less often. Given that usb emulation > > > > > > > > is still > > > > > > > > on by default, I don't think that this change will have a big > > > > > > > > impact. > > > > > > > > > > > > > > My question was whether we thought anyone would be using this > > > > > > > non-default configuration, not what the impact on the default is. > > > > > > > > > > > > > > You gave a good reason why people might be using this facility, > > > > > > > do you > > > > > > > think anyone is actually using it? > > > > > > > > > > > > I don't know of anybody using it. I don't think we made clear > > > > > > enough how > > > > > > to use this non-default configuration and its advantages for users > > > > > > to go > > > > > > out of their ways to use it. > > > > > > > > > > That's good enough for me, thanks,. > > > > > > > > Can I add your acked-by? > > > > > > If you put some distillation of the reasoning given in this subthread > > > for why we think we can get away with it into the commit message then > > > yes. > > > > Why don't we also make the Linux code not expose this driver for HVM guests? > > > > I've had an go for this last year (can't find the link) as it would unduly And the link: http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg00160.html > > cause the Linux kernel to take an extra 30 seconds to boot. That is because > > 'xend' by default exposes the PV configuration even for HVM guests - and of > > course there are no PV drivers (as the VGA in QEMU is enabled). > > But even with xend it only happens with a vfb line is in the config > file, right? That's why we didn't fix it back when the issue was > reported, if I remember correctly. Both. If you had 'vnc' or 'vfb' it would setup the 'vfb' key. > > > > The only use case I had was for ARM - where there are no VGA - and the > > patch I think I had just disabled the xen-fbfront under X86 HVM. > > Yeah, we need xen-fbfront for ARM. > > > Given that xen-fbfront is likely to go away for HVM guests, I wouldn't > be opposed to stop the driver initialization in Linux on x86/HVM. Unless > Roger's work on HVMlite is going to need xen-fbfront again, but in that > case we'll be able to distinguish a regular HVM guest from an HVMlite > guest, I think. Correct. Right now the 'xen_pvh_domain' is based on it being PV and auto-translate. That whole thing will need some help. But I am looking at the xen-fbfront.c driver and it might be that I had already fixed this issue! (inadvertly it seems) 51c71a3bbaca868043cc45b3ad3786dd48a90235 Author: Konrad Rzeszutek Wilk Date: T
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
On Wed, 1 Jul 2015, Konrad Rzeszutek Wilk wrote: > On Wed, Jul 01, 2015 at 11:29:46AM +0100, Stefano Stabellini wrote: > > On Tue, 30 Jun 2015, Konrad Rzeszutek Wilk wrote: > > > On Tue, Jun 30, 2015 at 03:13:53PM +0100, Ian Campbell wrote: > > > > On Tue, 2015-06-30 at 15:02 +0100, Stefano Stabellini wrote: > > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > > On Tue, 2015-06-30 at 12:21 +0100, Stefano Stabellini wrote: > > > > > > > On Tue, 30 Jun 2015, Ian Campbell wrote: > > > > > > > > On Mon, 2015-06-29 at 18:59 +0100, Stefano Stabellini wrote: > > > > > > > > > On Thu, 25 Jun 2015, Ian Campbell wrote: > > > > > > > > > > On Tue, 2015-06-16 at 16:39 +0100, Stefano Stabellini wrote: > > > > > > > > > > > On Tue, 16 Jun 2015, Wei Liu wrote: > > > > > > > > > > > > On Wed, Jun 10, 2015 at 11:09:50AM +0100, Stefano > > > > > > > > > > > > Stabellini wrote: > > > > > > > > > > > > > When QEMU restricts its xenstore connection, it > > > > > > > > > > > > > cannot provide PV > > > > > > > > > > > > > backends. A separate QEMU instance is required to > > > > > > > > > > > > > provide PV backends in > > > > > > > > > > > > > userspace, such as qdisk. With two separate > > > > > > > > > > > > > instances, it is not > > > > > > > > > > > > > possible to take advantage of vkb for mouse and > > > > > > > > > > > > > keyboard, as the QEMU > > > > > > > > > > > > > that emulates the graphic card (the device model), > > > > > > > > > > > > > would be separate > > > > > > > > > > > > > from the QEMU running the vkb backend (PV QEMU). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The question is that how would this affect the > > > > > > > > > > > > non-split setup. > > > > > > > > > > > > > > > > > > > > > > vkb is useful because emulating usb forces QEMU to wake > > > > > > > > > > > up more often. > > > > > > > > > > > However there is no way around it. > > > > > > > > > > > > > > > > > > > > Does pvfb+vkb continue to work due to code somewhere else? > > > > > > > > > > > > > > > > > > Yes, it continues to work as usual for PV guests. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do we think anyone will actually be using emulated VGA + PV > > > > > > > > > > input > > > > > > > > > > devices? > > > > > > > > > > > > > > > > > > VGA + PV input only works with Linux and is only useful for > > > > > > > > > power > > > > > > > > > efficiency, because if you disable usb emulation in QEMU, > > > > > > > > > then QEMU > > > > > > > > > would be able to wake up less often. Given that usb emulation > > > > > > > > > is still > > > > > > > > > on by default, I don't think that this change will have a big > > > > > > > > > impact. > > > > > > > > > > > > > > > > My question was whether we thought anyone would be using this > > > > > > > > non-default configuration, not what the impact on the default > > > > > > > > is. > > > > > > > > > > > > > > > > You gave a good reason why people might be using this facility, > > > > > > > > do you > > > > > > > > think anyone is actually using it? > > > > > > > > > > > > > > I don't know of anybody using it. I don't think we made clear > > > > > > > enough how > > > > > > > to use this non-default configuration and its advantages for > > > > > > > users to go > > > > > > > out of their ways to use it. > > > > > > > > > > > > That's good enough for me, thanks,. > > > > > > > > > > Can I add your acked-by? > > > > > > > > If you put some distillation of the reasoning given in this subthread > > > > for why we think we can get away with it into the commit message then > > > > yes. > > > > > > Why don't we also make the Linux code not expose this driver for HVM > > > guests? > > > > > > I've had an go for this last year (can't find the link) as it would unduly > > And the link: > > http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg00160.html > > > cause the Linux kernel to take an extra 30 seconds to boot. That is > > > because > > > 'xend' by default exposes the PV configuration even for HVM guests - and > > > of > > > course there are no PV drivers (as the VGA in QEMU is enabled). > > > > But even with xend it only happens with a vfb line is in the config > > file, right? That's why we didn't fix it back when the issue was > > reported, if I remember correctly. > > Both. If you had 'vnc' or 'vfb' it would setup the 'vfb' key. > > > > > > > The only use case I had was for ARM - where there are no VGA - and the > > > patch I think I had just disabled the xen-fbfront under X86 HVM. > > > > Yeah, we need xen-fbfront for ARM. > > > > > > Given that xen-fbfront is likely to go away for HVM guests, I wouldn't > > be opposed to stop the driver initialization in Linux on x86/HVM. Unless > > Roger's work on HVMlite is going to need xen-fbfront again, but in that > > case we'll be able to distinguish a regular HVM guest from an HVMlite > > guest, I think. > > Correct. Right now the 'xen_pvh_do
Re: [Xen-devel] [PATCH v3 2/6] libxl: do not add a vkb backend to hvm guests
> > But I am looking at the xen-fbfront.c driver and it might be that
> > I had already fixed this issue! (inadvertly it seems)
> >
> > 51c71a3bbaca868043cc45b3ad3786dd48a90235
> > Author: Konrad Rzeszutek Wilk
> > Date: Tue Nov 26 15:05:40 2013 -0500
> >
> > xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).
> >
> > ..
> >- if running in HVM, check if user wanted 'xen_emul_unplug=never',
> >in which case bail out and don't load any PV drivers.
> > - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> >does not exist, then bail out and not load PV drivers.
> > - (v2) if running in HVM, and if the user wanted
> > 'xen_emul_unplug=ide-disks',
> >then bail out for all PV devices _except_ the block one.
> >Ditto for the network one ('nics').
> > - (v2) if running in HVM, and if the user wanted
> > 'xen_emul_unplug=unnecessary'
> >then load block PV driver, and also setup the legacy IDE paths.
> >In (v3) make it actually load PV drivers.
> >
> > .. which means that if the driver does not use the 'xen_has_pv_XXX_devices'
> > but only the 'xen_has_pv_devices' then for a normal HVM guest it won't load
> > it.
> >
> > And sure enough we have:
> >
> > + if (!xen_has_pv_devices())
> > + return -ENODEV;
> >
> > so we bail out and not load it under HVM.
>
> And at the same time it works on ARM because CONFIG_XEN_PVHVM is not
> defined there, right?
Yup, and it ends up doing:
static inline bool xen_has_pv_devices(void)
{
return IS_ENABLED(CONFIG_XEN);
}
which will return true if CONFIG_XEN is set.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
