Re: [Qemu-devel] [PATCH 7/7 v5] VMXNET3 paravirtualized device implementation Interface type "vmxnet3" added.

[Izik Eidus]

Hi,

What about this patch?, everything that was asked from Dmitry was 
accomplished...

What prevent us from progressing with merging this patch?

Thanks.

On 18/03/2012 11:27, Dmitry Fleytman wrote:

Signed-off-by: Dmitry Fleytman
Signed-off-by: Yan Vugenfirer
---
  Makefile.objs   |1 +
  default-configs/pci.mak |1 +
  hw/pci.c|2 +
  hw/pci.h|1 +
  hw/vmxnet3.c| 2454 +++
  hw/vmxnet3.h|  757 +++
  net.c   |2 +-
  7 files changed, 3217 insertions(+), 1 deletions(-)
  create mode 100644 hw/vmxnet3.c
  create mode 100644 hw/vmxnet3.h

Re: [Qemu-devel] [PATCH] VMXNET3 paravirtual NIC device implementation

[Izik Eidus]

On Tue, Feb 28, 2012 at 2:50 PM, Yan Vugenfirer  wrote:
> Adding Izik from Ravello.
>
> Best regards,
> Yan.
>
> On Tue, Feb 28, 2012 at 6:43 PM, malc  wrote:
>> On Tue, 28 Feb 2012, Yan Vugenfirer wrote:
>>
>>> From: Dmitry Fleytman 
>>>
>>> Implementation of VMWare VMXNET3 paravirtual NIC device.
>>> Supports of all the device features including offload capabilties,
>>> VLANs and etc.
>>> The device is tested on different OSes:
>> [..snip..]
>>
>>> @@ -0,0 +1,146 @@
>>> +/*
>>> + * QEMU VMWARE paravirtual devices - auxiliary code
>>> + *
>>> + * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
>>> + * All Rights Reserved
>>
>> Not quite sure, i'm follwing this, here it says that all rights are
>> reserved.


Hey,

isn`t this is the common GPL2 licence format?
for example from the very same qemu:
/*
 * qemu/kvm integration
 *
 * Copyright (C) 2006-2008 Qumranet Technologies
 *
 * Licensed under the terms of the GNU GPL version 2 or higher.
 */

Do we miss anything? because our meaning is to publish it as a fully
GPL2 licensed code...

Thanks.

>>
>>> + *
>>> + * Developed by Daynix Computing LTD (http://www.daynix.com)
>>> + *
>>> + * Authors:
>>> + * Dmitry Fleytman 
>>> + * Yan Vugenfirer 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License as published by the
>>> + * Free Software Foundation; version 2 of the License and no later version.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
>>> + * NON INFRINGEMENT.  See the GNU General Public License for more
>>> + * details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with this program; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 
>>> USA.
>>> + *
>>> + * The full GNU General Public License is included in this distribution in
>>> + * the file called "COPYING".
>>> + *
>>> + */
>>
>> And here that most of them are really not.
>>
>> Not a lawyer though.
>>
>> [..snip..]
>>
>> --
>> mailto:av1...@comtv.ru

Re: [Qemu-devel] [PATCH] VMXNET3 paravirtual NIC device implementation

[Izik Eidus]

On 02/28/2012 03:01 PM, Daniel P. Berrange wrote:

On Tue, Feb 28, 2012 at 02:57:32PM -0500, Izik Eidus wrote:

On Tue, Feb 28, 2012 at 2:50 PM, Yan Vugenfirer  wrote:

Adding Izik from Ravello.

Best regards,
Yan.

On Tue, Feb 28, 2012 at 6:43 PM, malc  wrote:

On Tue, 28 Feb 2012, Yan Vugenfirer wrote:


From: Dmitry Fleytman

Implementation of VMWare VMXNET3 paravirtual NIC device.
Supports of all the device features including offload capabilties,
VLANs and etc.
The device is tested on different OSes:

[..snip..]


@@ -0,0 +1,146 @@
+/*
+ * QEMU VMWARE paravirtual devices - auxiliary code
+ *
+ * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
+ * All Rights Reserved

Not quite sure, i'm follwing this, here it says that all rights are
reserved.


Hey,

isn`t this is the common GPL2 licence format?
for example from the very same qemu:
/*
  * qemu/kvm integration
  *
  * Copyright (C) 2006-2008 Qumranet Technologies
  *
  * Licensed under the terms of the GNU GPL version 2 or higher.
  */

Do we miss anything? because our meaning is to publish it as a fully
GPL2 licensed code...

Your "Copyright" line is fine, but you should really remove the
'All rights reserved' line which contradicts your GPL intention
below


Ok, got it, we will resend it without 'All rights reserved'
Thanks.




+ *
+ * Developed by Daynix Computing LTD (http://www.daynix.com)
+ *
+ * Authors:
+ * Dmitry Fleytman
+ * Yan Vugenfirer
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License and no later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT.  See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ */

And here that most of them are really not.

Not a lawyer though.

[..snip..]

--
mailto:av1...@comtv.ru

Regards,
Daniel

Re: [Qemu-devel] [PATCH] VMXNET3 paravirtual NIC device implementation

[Izik Eidus]

On Tue, Feb 28, 2012 at 3:01 PM, Daniel P. Berrange  wrote:
> On Tue, Feb 28, 2012 at 02:57:32PM -0500, Izik Eidus wrote:
>> On Tue, Feb 28, 2012 at 2:50 PM, Yan Vugenfirer  
>> wrote:
>> > Adding Izik from Ravello.
>> >
>> > Best regards,
>> > Yan.
>> >
>> > On Tue, Feb 28, 2012 at 6:43 PM, malc  wrote:
>> >> On Tue, 28 Feb 2012, Yan Vugenfirer wrote:
>> >>
>> >>> From: Dmitry Fleytman 
>> >>>
>> >>> Implementation of VMWare VMXNET3 paravirtual NIC device.
>> >>> Supports of all the device features including offload capabilties,
>> >>> VLANs and etc.
>> >>> The device is tested on different OSes:
>> >> [..snip..]
>> >>
>> >>> @@ -0,0 +1,146 @@
>> >>> +/*
>> >>> + * QEMU VMWARE paravirtual devices - auxiliary code
>> >>> + *
>> >>> + * Copyright (c) 2012 Ravello Systems LTD (http://ravellosystems.com)
>> >>> + * All Rights Reserved
>> >>
>> >> Not quite sure, i'm follwing this, here it says that all rights are
>> >> reserved.
>>
>>
>> Hey,
>>
>> isn`t this is the common GPL2 licence format?
>> for example from the very same qemu:
>> /*
>>  * qemu/kvm integration
>>  *
>>  * Copyright (C) 2006-2008 Qumranet Technologies
>>  *
>>  * Licensed under the terms of the GNU GPL version 2 or higher.
>>  */
>>
>> Do we miss anything? because our meaning is to publish it as a fully
>> GPL2 licensed code...
>
> Your "Copyright" line is fine, but you should really remove the
> 'All rights reserved' line which contradicts your GPL intention
> below

(I am sending my answer again, my clock was not configured so the
email had wrong time)

We will send the patch again, this time without this line.

Thanks.


>
>> >>
>> >>> + *
>> >>> + * Developed by Daynix Computing LTD (http://www.daynix.com)
>> >>> + *
>> >>> + * Authors:
>> >>> + * Dmitry Fleytman 
>> >>> + * Yan Vugenfirer 
>> >>> + *
>> >>> + * This program is free software; you can redistribute it and/or modify 
>> >>> it
>> >>> + * under the terms of the GNU General Public License as published by the
>> >>> + * Free Software Foundation; version 2 of the License and no later 
>> >>> version.
>> >>> + *
>> >>> + * This program is distributed in the hope that it will be useful, but
>> >>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>> >>> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
>> >>> + * NON INFRINGEMENT.  See the GNU General Public License for more
>> >>> + * details.
>> >>> + *
>> >>> + * You should have received a copy of the GNU General Public License
>> >>> + * along with this program; if not, write to the Free Software
>> >>> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 
>> >>> USA.
>> >>> + *
>> >>> + * The full GNU General Public License is included in this distribution 
>> >>> in
>> >>> + * the file called "COPYING".
>> >>> + *
>> >>> + */
>> >>
>> >> And here that most of them are really not.
>> >>
>> >> Not a lawyer though.
>> >>
>> >> [..snip..]
>> >>
>> >> --
>> >> mailto:av1...@comtv.ru
>>
>
> Regards,
> Daniel
> --
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 17:07:13 -0200
Glauber Costa  wrote:

> >>
> >> Spice is a library, it is library for remote display, it handle by
> >> itself all the connection between the spice client to the host that
> >> run the guest, it include:
> >> sound, display, keyboard, usb, network tunneling (for printers)
> >> and so on...
> >>
> >
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines
> >
> > So how can we change the library just for qemu?
> >
> I don't fully understand spice yet, but what's the difficulty here?
> libraries changes every single day to try to acomodate for the needs
> of specific users, be it through generalizations, shims, or whatever.
> 
> This is just another day in the OSS world.
> 
> 

We are working on physical machines support for spice. the library
contain all what need for remote display.

[Qemu-devel] Re: [PATCH] adding helper pci functions

[Izik Eidus]

On 02/25/2010 10:41 AM, Gerd Hoffmann wrote:

From: Izik Eidus
   


The true auther of this patch is Yaniv Kamay.

Thanks.


Signed-off-by: Izik Eidus
Signed-off-by: Gerd Hoffmann
---
   

[Qemu-devel] [PATCH] fix migration with large mem

[Izik Eidus]

From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
From: Izik Eidus 
Date: Tue, 13 Apr 2010 12:24:57 +0300
Subject: [PATCH] fix migration with large mem

In cases of guests with large mem that have pages
that all their bytes content are the same, we will
spend alot of time reading the memory from the guest
(is_dup_page())

It is happening beacuse ram_save_live() function have
limit of how much we can send to the dest but not how
much we read from it, and in cases we have many is_dup_page()
hits, we might read huge amount of data without updating important
stuff like the timers...

The guest lose all its repsonsibility and have many softlock ups
inside itself.

this patch add limit on the size we can read from the guest each
iteration.

Thanks.

Signed-off-by: Izik Eidus 
---
 arch_init.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch_init.c b/arch_init.c
index cfc03ea..e27b1a0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -88,6 +88,8 @@ const uint32_t arch_type = QEMU_ARCH;
 #define RAM_SAVE_FLAG_PAGE 0x08
 #define RAM_SAVE_FLAG_EOS  0x10
 
+#define MAX_SAVE_BLOCK_READ 10 * 1024 * 1024
+
 static int is_dup_page(uint8_t *page, uint8_t ch)
 {
 uint32_t val = ch << 24 | ch << 16 | ch << 8 | ch;
@@ -175,6 +177,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 uint64_t bytes_transferred_last;
 double bwidth = 0;
 uint64_t expected_time = 0;
+int data_read = 0;
 
 if (stage < 0) {
 cpu_physical_memory_set_dirty_tracking(0);
@@ -205,10 +208,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
void *opaque)
 bytes_transferred_last = bytes_transferred;
 bwidth = qemu_get_clock_ns(rt_clock);
 
-while (!qemu_file_rate_limit(f)) {
+while (!qemu_file_rate_limit(f) && data_read < MAX_SAVE_BLOCK_READ) {
 int ret;
 
 ret = ram_save_block(f);
+data_read += ret * TARGET_PAGE_SIZE;
 bytes_transferred += ret * TARGET_PAGE_SIZE;
 if (ret == 0) { /* no more blocks */
 break;
-- 
1.6.6.1

[Qemu-devel] Re: [PATCH] fix migration with large mem

[Izik Eidus]

On Tue, 13 Apr 2010 12:33:18 +0300
Izik Eidus  wrote:

> From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
> From: Izik Eidus 
> Date: Tue, 13 Apr 2010 12:24:57 +0300
> Subject: [PATCH] fix migration with large mem

Anyone ???


> 
> In cases of guests with large mem that have pages
> that all their bytes content are the same, we will
> spend alot of time reading the memory from the guest
> (is_dup_page())
> 
> It is happening beacuse ram_save_live() function have
> limit of how much we can send to the dest but not how
> much we read from it, and in cases we have many is_dup_page()
> hits, we might read huge amount of data without updating important
> stuff like the timers...
> 
> The guest lose all its repsonsibility and have many softlock ups
> inside itself.
> 
> this patch add limit on the size we can read from the guest each
> iteration.
> 
> Thanks.
> 
> Signed-off-by: Izik Eidus 
> ---
>  arch_init.c |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/arch_init.c b/arch_init.c
> index cfc03ea..e27b1a0 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -88,6 +88,8 @@ const uint32_t arch_type = QEMU_ARCH;
>  #define RAM_SAVE_FLAG_PAGE   0x08
>  #define RAM_SAVE_FLAG_EOS0x10
>  
> +#define MAX_SAVE_BLOCK_READ 10 * 1024 * 1024
> +
>  static int is_dup_page(uint8_t *page, uint8_t ch)
>  {
>  uint32_t val = ch << 24 | ch << 16 | ch << 8 | ch;
> @@ -175,6 +177,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
> void *opaque)
>  uint64_t bytes_transferred_last;
>  double bwidth = 0;
>  uint64_t expected_time = 0;
> +int data_read = 0;
>  
>  if (stage < 0) {
>  cpu_physical_memory_set_dirty_tracking(0);
> @@ -205,10 +208,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int stage, 
> void *opaque)
>  bytes_transferred_last = bytes_transferred;
>  bwidth = qemu_get_clock_ns(rt_clock);
>  
> -while (!qemu_file_rate_limit(f)) {
> +while (!qemu_file_rate_limit(f) && data_read < MAX_SAVE_BLOCK_READ) {
>  int ret;
>  
>  ret = ram_save_block(f);
> +data_read += ret * TARGET_PAGE_SIZE;
>  bytes_transferred += ret * TARGET_PAGE_SIZE;
>  if (ret == 0) { /* no more blocks */
>  break;

Re: [Qemu-devel] [PATCH] fix migration with large mem

[Izik Eidus]

On Mon, 10 May 2010 15:24:20 -0500
Anthony Liguori  wrote:

> On 04/13/2010 04:33 AM, Izik Eidus wrote:
> >  From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00
> > 2001 From: Izik Eidus
> > Date: Tue, 13 Apr 2010 12:24:57 +0300
> > Subject: [PATCH] fix migration with large mem
> >
> > In cases of guests with large mem that have pages
> > that all their bytes content are the same, we will
> > spend alot of time reading the memory from the guest
> > (is_dup_page())
> >
> > It is happening beacuse ram_save_live() function have
> > limit of how much we can send to the dest but not how
> > much we read from it, and in cases we have many is_dup_page()
> > hits, we might read huge amount of data without updating important
> > stuff like the timers...
> >
> > The guest lose all its repsonsibility and have many softlock ups
> > inside itself.
> >
> > this patch add limit on the size we can read from the guest each
> > iteration.
> >
> >  Thanks.
> >
> > Signed-off-by: Izik Eidus
> > ---
> >   arch_init.c |6 +-
> >   1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch_init.c b/arch_init.c
> > index cfc03ea..e27b1a0 100644
> > --- a/arch_init.c
> > +++ b/arch_init.c
> > @@ -88,6 +88,8 @@ const uint32_t arch_type = QEMU_ARCH;
> >   #define RAM_SAVE_FLAG_PAGE0x08
> >   #define RAM_SAVE_FLAG_EOS 0x10
> >
> > +#define MAX_SAVE_BLOCK_READ 10 * 1024 * 1024
> > +
> >   static int is_dup_page(uint8_t *page, uint8_t ch)
> >   {
> >   uint32_t val = ch<<  24 | ch<<  16 | ch<<  8 | ch;
> > @@ -175,6 +177,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f,
> > int stage, void *opaque) uint64_t bytes_transferred_last;
> >   double bwidth = 0;
> >   uint64_t expected_time = 0;
> > +int data_read = 0;
> >
> >   if (stage<  0) {
> >   cpu_physical_memory_set_dirty_tracking(0);
> > @@ -205,10 +208,11 @@ int ram_save_live(Monitor *mon, QEMUFile *f,
> > int stage, void *opaque) bytes_transferred_last = bytes_transferred;
> >   bwidth = qemu_get_clock_ns(rt_clock);
> >
> > -while (!qemu_file_rate_limit(f)) {
> > +while (!qemu_file_rate_limit(f)&&  data_read<
> > MAX_SAVE_BLOCK_READ) { 
> 
> The effect of this patch is that we'll never send more than 10mb/s 
> during live migration?  If so, it's totally wrong as a fix to the
> problem.

It is 100mb/s... (if I remember correct the migration code will run
this thing 10 times for each iteration)

My feeling is that limit it with the network 32mb/s limit is too low,
reading memory for 100mb/s is not such a problem as long as we don`t
read gigas out of memory every sec...

(Still we want to optimize the billion of zeros cases of windows guests)

Anyway if the above does not make sense to you, I will just change it
into what you suggested

So ?

> 
> It would be better to account the deduplicated pages as part of the
> rate limiting calculations.
> 
> Regards,
> 
> Anthony Liguori
> 
> >   int ret;
> >
> >   ret = ram_save_block(f);
> > +data_read += ret * TARGET_PAGE_SIZE;
> >   bytes_transferred += ret * TARGET_PAGE_SIZE;
> >   if (ret == 0) { /* no more blocks */
> >   break;
> >
> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 09:57:48 -0600
Anthony Liguori  wrote:

> Yaniv Kamay wrote:
> > Hi,
> >
> > Spice project is now open, for more information visit
> > http://spice-space.org, due to a server relocation the site will be
> > down during this weekend.
> >
> > Spice ship patched QEMU based on fairly old KVM snapshot as a
> > reference implementation. The Spice team plane to push all the
> > relevant bits into QEMU upstream.
> >   
> 
> Historically, we have not supported multiple display mechanisms
> favoring making one mechanism as good as it can be.
> 
> Supporting both Spice and VNC would go against this policy.  It's not 
> outside the realm of possibility, but there has to be a good 
> justification for it.
> 
> We need to separate the advantages of having a paravirtual display 
> driver from the advantages of a remote display protocol.  For
> instance, VNC is capable of doing ARGB cursor offloading to the
> client.  We do not support it in QEMU because the VGA drivers we
> emulate do not support this functionality.  Likewise, VNC can support
> sound tunneling and QEMU does implement this (although virt-manager
> does not yet).
> 
> So from a protocol perspective, what are the advantages of Spice over
> VNC?


Spice desgien is highly diffrence than VNC
The first thing about spice is that it isnt just a framebuffer drawing
and not a bitmaps protocol.

Spice protocl support multiple graphics commands, multiple surfaces
drawings, Spice is desgined to render as less as it can on the server
and instead to render on the client side much of the work,
To achive this spice use all kind of techniques such as depth viewing
tree.

We already have patchs that support offscreen surfaces -> the
architacture for high end 3d, this make things even more complicated.

Spice is a library, it is library for remote display, it handle by
itself all the connection between the spice client to the host that run
the guest, it include:
sound, display, keyboard, usb, network tunneling (for printers) and so
on...

The patchs that we wanted to push into qemu were what is called VDI
interfaces, it allow to qemu work with what ever interface it want,
what so bad about that?

I think we should allow freedom of choice to the users to decide what
protcol they want to use, Spice and VNC are all diffrent and were born
to meet diffrent goals.

I would happy to answer more questions if anyone have

Thanks.


> 
> Obviously, the disadvantages are that for all practical purposes,
> it's a closed protocol.  While there is now a specification, there is
> not a clear mechanism for extending it by third parties.  VNC has a
> published protocol and there's a documented process for extending by
> third parties.  There are a large number of existing VNC clients so
> from an interoperability perspective, VNC clearly wins.
> 
> Since VNC is extensible (and we've extended it many times for QEMU),
> if Spice possesses unique encoding mechanisms that are advantageous,
> why wouldn't we just add those mechanisms to VNC as an extension?
> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 20:48:28 +0200
Izik Eidus  wrote:

> On Fri, 11 Dec 2009 09:57:48 -0600
> Anthony Liguori  wrote:
> 
> > Yaniv Kamay wrote:
> > > Hi,
> > >
> > > Spice project is now open, for more information visit
> > > http://spice-space.org, due to a server relocation the site will
> > > be down during this weekend.
> > >
> > > Spice ship patched QEMU based on fairly old KVM snapshot as a
> > > reference implementation. The Spice team plane to push all the
> > > relevant bits into QEMU upstream.
> > >   
> > 
> > Historically, we have not supported multiple display mechanisms
> > favoring making one mechanism as good as it can be.
> > 
> > Supporting both Spice and VNC would go against this policy.  It's
> > not outside the realm of possibility, but there has to be a good 
> > justification for it.
> > 
> > We need to separate the advantages of having a paravirtual display 
> > driver from the advantages of a remote display protocol.  For
> > instance, VNC is capable of doing ARGB cursor offloading to the
> > client.  We do not support it in QEMU because the VGA drivers we
> > emulate do not support this functionality.  Likewise, VNC can
> > support sound tunneling and QEMU does implement this (although
> > virt-manager does not yet).
> > 
> > So from a protocol perspective, what are the advantages of Spice
> > over VNC?
> 
> 
> Spice desgien is highly diffrence than VNC
> The first thing about spice is that it isnt just a framebuffer drawing
> and not a bitmaps protocol.
> 
> Spice protocl support multiple graphics commands, multiple surfaces
> drawings, Spice is desgined to render as less as it can on the server
> and instead to render on the client side much of the work,
> To achive this spice use all kind of techniques such as depth viewing
> tree.
> 
> We already have patchs that support offscreen surfaces -> the
> architacture for high end 3d, this make things even more complicated.
> 
> Spice is a library, it is library for remote display, it handle by
> itself all the connection between the spice client to the host that
> run the guest, it include:
> sound, display, keyboard, usb, network tunneling (for printers) and so
> on...
> 

I want to add that qemu is not the sole user of spice, Spice will be
used as a protocol to connect into physical windows/linux machines

So how can we change the library just for qemu?

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 18:57:17 +
Ben Taylor  wrote:

> I think the simple point is that, AFAICS, the spice folks are
> expecting the qemu team to integrate their big ugly tarball, instead
> of doing what everyone else does, which is forward port everything to
> current head and then provide a current set of patches against GIT
> head.


This was never the issue.
We have planes to send the vdi interfaces to qemu, we just open sourced
spice, it take time.

I think you guys totaly didnt understand us.

We will send patchs to qemu-devel adding the vdi interfaces.

But again spice itself is library and it have more than one user other
than qemu, so the way the protocol work is spice specific and not qemu
specific.

And this why we are adding the VDI interfaces, it allow qemu to work
with whatever library the users will want to use.

What so bad about that?

> 
> Anything else is just a waste of time. The paths both projects are
> at are too far apart.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
malc  wrote:

> On Fri, 11 Dec 2009, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 09:57:48 -0600
> > Anthony Liguori  wrote:
> > 
> [..snip..]
> 
> > 
> > Spice desgien is highly diffrence than VNC
> > The first thing about spice is that it isnt just a framebuffer
> > drawing and not a bitmaps protocol.
> > 
> > Spice protocl support multiple graphics commands, multiple surfaces
> > drawings, Spice is desgined to render as less as it can on the
> > server and instead to render on the client side much of the work,
> > To achive this spice use all kind of techniques such as depth
> > viewing tree.
> > 
> > We already have patchs that support offscreen surfaces -> the
> > architacture for high end 3d, this make things even more
> > complicated.
> > 
> > Spice is a library, it is library for remote display, it handle by
> > itself all the connection between the spice client to the host that
> > run the guest, it include:
> > sound, display, keyboard, usb, network tunneling (for printers) and
> > so on...
> > 
> > The patchs that we wanted to push into qemu were what is called VDI
> > interfaces, it allow to qemu work with what ever interface it want,
> > what so bad about that?
> > 
> > I think we should allow freedom of choice to the users to decide
> > what protcol they want to use, Spice and VNC are all diffrent and
> > were born to meet diffrent goals.
> > 
> > I would happy to answer more questions if anyone have
> 
> Any particular reason for implementing audio as a driver instead of
> a capture?


Spice doesnt have paravirtual audio driver, it use the AC97 device.
> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:04:02 -0600
Anthony Liguori  wrote:

> Hi Izik,
> 
> Thanks for the explanation.
> 
> Izik Eidus wrote:
> >> So from a protocol perspective, what are the advantages of Spice
> >> over VNC?
> >> 
> >
> >
> > Spice desgien is highly diffrence than VNC
> > The first thing about spice is that it isnt just a framebuffer
> > drawing and not a bitmaps protocol.
> >
> > Spice protocl support multiple graphics commands,
> 
> VNC actually does have high level 2d commands like CopyRect.  The
> higher end encodings (like Tight and ZRLE) provide for mechanisms to
> do operations like fill even with different types of patterns.
> 
> Do you have any performance data that demonstrates where SPICE does
> well compared to something like VNC?

I should speek with the marketing guys, will be able to answer on that
specific question in few days.


But simple 2D Commands are just not enougth for spice.
We have multiple drawing surfaces, that are depended on each other.
We Dont renender untill the very moment that the guest try to read its
video memory, we have video streaming, and we have cache based by the
guest driver.
We have private channels for stuff like keyboard, display and so on...


> 
> >  multiple surfaces
> > drawings,
> 
> VNC does not have a notion of off-screen pixmaps but it would be
> pretty easy to add.  I think the simpliest approach would be to
> introduce the notion of a Viewport which clips the visible screen to
> a smaller size. That way, you could resize the screen to 2x or 3x the
> viewable screen.  You could us things like CopyRect to blt from an
> off-screen surface to the on-screen surface.  I think the real
> question though is how much of a win is off-screen drawing?
> 
> We've always been very limited by the VGA devices we emulate so we've 
> never really tried to make the most out of VNC.
> 
> >  Spice is desgined to render as less as it can on the server
> > and instead to render on the client side much of the work,
> > To achive this spice use all kind of techniques such as depth
> > viewing tree.
> >   
> 
> I'm not familiar with what a "depth viewing tree".  Can you elaborate?

In it simplest way of working, we will take the simplest case of what
it is doing:
If you have application that rendered a window, and then it renendered
another window on top of it, you dont want to send the commands that
rendered the old window, beacuse the new commands hide the older one...

When the guest will try to read the video memory, you wont want the
server to render the old commands.

But you will want to rendner the old commands in case the new commands
are depended on the older commands...

> 
> > The patchs that we wanted to push into qemu were what is called VDI
> > interfaces, it allow to qemu work with what ever interface it want,
> > what so bad about that?
> >   
> 
> Those patches never made it to the list.


It will take some time, it is in our todo, we never expected qemu to
merge spice without this patches!


> 
> > I think we should allow freedom of choice to the users to decide
> > what protcol they want to use, Spice and VNC are all diffrent and
> > were born to meet diffrent goals.
> >   
> 
> What would be ideal, is if there was a mechanism whereas a client
> could connect to the VNC server, and get VNC traffic if it's a normal
> VNC client, but if it was a smarter client, got a more sophisticated 
> stream.  If that was something that was Spice or Spice-like, that
> would be perfect.
> 
> But to introduce another protocol where a user has to make a choice
> to use Spice over VNC, I think we need a really good justification
> for that.  It's really about complexity.  A user shouldn't have to
> know about Spice or VNC.  They shouldn't have to contemplate the
> trade-offs of whether their management tool is aware or not.  It
> should Just Work.


This why we suggest the VDI interface, to solve all this choicses we
made for the users,

Think about qemu give infastracture to multiple librarys to use it?
For example one user can use qemu with  VNC, one with SPICE, and one
can use qemu with diffrent private local rendering soultion (for highly
fast local 3d rendering...)


> 
> > I would happy to answer more questions if anyone have
> >   
> 
> Thanks.
> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:06:47 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines
> >
> > So how can we change the library just for qemu?
> >   
> A library is not necessarily a problem.
> 
> What would be a probably is if the library maintains guest visible 
> state.  There are a lot of advantages to keeping qemu as the sole 
> maintainer of guest visible state as it simplifies things like live 
> migration.  More importantly, it allows us to do things like Avi's 
> suggested security sandboxing using seccomp().  For that to work, we 
> need to make sure that we can isolate any code that interacts
> directly with the guest.

Spice guest visible state inside qemu is just its PCI QXL device.
This part is qemu specificed.


> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 17:07:13 -0200
Glauber Costa  wrote:

> >>
> >> Spice is a library, it is library for remote display, it handle by
> >> itself all the connection between the spice client to the host that
> >> run the guest, it include:
> >> sound, display, keyboard, usb, network tunneling (for printers)
> >> and so on...
> >>
> >
> > I want to add that qemu is not the sole user of spice, Spice will be
> > used as a protocol to connect into physical windows/linux
> > machines
> >
> > So how can we change the library just for qemu?
> >
> I don't fully understand spice yet, but what's the difficulty here?
> libraries changes every single day to try to acomodate for the needs
> of specific users, be it through generalizations, shims, or whatever.
> 
> This is just another day in the OSS world.
> 
> 

We are working on spice for physical machines, the library contain all
what need for remote displays.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 17:15:02 -0200
Glauber Costa  wrote:

> >
> > But to introduce another protocol where a user has to make a choice
> > to use Spice over VNC, I think we need a really good justification
> > for that.  It's really about complexity.  A user shouldn't have to
> > know about Spice or VNC. They shouldn't have to contemplate the
> > trade-offs of whether their management tool is aware or not.  It
> > should Just Work.
> >
> >> I would happy to answer more questions if anyone have
> >>
> >
> > Thanks.
> 
> Just to make a point clear:
> 
> AFAIU, there are two parts of qemu spice support. The protocol
> (vnc-like), and the guest device (vga-like). I am right?
> 
> 

qemu spice support is built by just 2 parts

qxl pci device - para virtual display device,
vdi interfaces - what allow to qemu to connect into the spice library.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
malc  wrote:

> On Fri, 11 Dec 2009, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > malc  wrote:
> > 
> > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > 
> > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > Anthony Liguori  wrote:
> > > > 
> > > [..snip..]
> > > 
> > > > 
> 
> [..snip..]
> 
> > > 
> > > Any particular reason for implementing audio as a driver instead
> > > of a capture?
> > 
> > 
> > Spice doesnt have paravirtual audio driver, it use the AC97 device.
> 
> Yes it has - interface_audio_driver in audio/vd_interface_audio.c
> 

I think the file name here is missleading you...

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:30:22 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > I should speek with the marketing guys, will be able to answer on
> > that specific question in few days.
> >
> >
> > But simple 2D Commands are just not enougth for spice.
> > We have multiple drawing surfaces, that are depended on each other.
> > We Dont renender untill the very moment that the guest try to read
> > its video memory, we have video streaming, and we have cache based
> > by the guest driver.
> > We have private channels for stuff like keyboard, display and so
> > on... 
> 
> The video streaming is an encoding heuristic though, right?
> 
> The lack of guest visible rendering is interesting.

The video streaming now is motiation jpeg due to patents problems.

What you mean lack of guest visible rendering?, I might didnt
understand you


> 
>   
> 
> >> I'm not familiar with what a "depth viewing tree".  Can you
> >> elaborate? 
> >
> > In it simplest way of working, we will take the simplest case of
> > what it is doing:
> > If you have application that rendered a window, and then it
> > renendered another window on top of it, you dont want to send the
> > commands that rendered the old window, beacuse the new commands
> > hide the older one... 
> 
> Ah, this is unique to a windowing protocol.  A framebuffer protocol
> does not have to worry about this because the OS does it for you.

Not true.
This is optimization for remote rendering, in physical machines we can
rendner what ever we want, it take more cpu to try to use trees in
order to render the right things
But with remote machines, we dont want to stress the network, so we
want to transfer just what we really need.

> 
> How well does this work with a Linux guest?  To get a lot of this
> level of information, you have to hook in at the X protocol level
> (which is what NX does).  Can you really do much at the X driver
> level?

Well we have X driver, why would there be any problems with X?

Spice driver to X (I mean from the X prespective on things) is just
another display driver.


> 
> Of course, a lot of interesting stuff (like drawing ops and text 
> rendering) doesn't even happen in the X server these days.
> 
> >>> I think we should allow freedom of choice to the users to decide
> >>> what protcol they want to use, Spice and VNC are all diffrent and
> >>> were born to meet diffrent goals.
> >>>   
> >>>   
> >> What would be ideal, is if there was a mechanism whereas a client
> >> could connect to the VNC server, and get VNC traffic if it's a
> >> normal VNC client, but if it was a smarter client, got a more
> >> sophisticated stream.  If that was something that was Spice or
> >> Spice-like, that would be perfect.
> >>
> >> But to introduce another protocol where a user has to make a choice
> >> to use Spice over VNC, I think we need a really good justification
> >> for that.  It's really about complexity.  A user shouldn't have to
> >> know about Spice or VNC.  They shouldn't have to contemplate the
> >> trade-offs of whether their management tool is aware or not.  It
> >> should Just Work.
> >> 
> >
> >
> > This why we suggest the VDI interface, to solve all this choicses we
> > made for the users,
> >   
> 
> Okay, but it's hard to evaluate that suggestion without seeing the
> VDI interface :-)

No problems!
http://www.spice-space.org/docs/vd_interfaces.pdf

> 
> > Think about qemu give infastracture to multiple librarys to use it?
> > For example one user can use qemu with  VNC, one with SPICE, and one
> > can use qemu with diffrent private local rendering soultion (for
> > highly fast local 3d rendering...)
> >   
> 
> As I said, I don't have a problem with externalizing things.  I think 
> there's some discussion about how best to do that.  For instance, I 
> think we want to avoid shared library plugins as it introduces a good 
> deal of instability into our address space.

Well why libc is diffrent then?

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 13:30:22 -0600
> > Anthony Liguori  wrote:
> >
> >   
> >> Izik Eidus wrote:
> >> 
> >>> I should speek with the marketing guys, will be able to answer on
> >>> that specific question in few days.
> >>>
> >>>
> >>> But simple 2D Commands are just not enougth for spice.
> >>> We have multiple drawing surfaces, that are depended on each
> >>> other. We Dont renender untill the very moment that the guest try
> >>> to read its video memory, we have video streaming, and we have
> >>> cache based by the guest driver.
> >>> We have private channels for stuff like keyboard, display and so
> >>> on... 
> >>>   
> >> The video streaming is an encoding heuristic though, right?
> >>
> >> The lack of guest visible rendering is interesting.
> >> 
> >
> > The video streaming now is motiation jpeg due to patents problems.
> >   
> 
> The approach taken by THINC was to support just a YUV overlay.  That 
> gets you half way there in terms of compressing a video stream.
> Since most hardware provides YUV->RGB acceleration, it fits very well
> into existing driver architectures.  For instance, VMware VGA
> supports YUV overlays because X has the Xv interface for this.
> 
> The other important bit is tiling.  That's easy enough to support in 
> something like VNC since it's rectangle based.  The one real missing
> bit is tile motion.  I would think you wouldn't get that with mjpeg
> anyway.
> 
> The other equally important piece is hardware scaling.  Obviously, if 
> you have a normal desktop resolution and are full screening an NTSC
> dvd, you can save a huge amount of bandwidth by supporting a scaled
> overlay.
> 
> I think adding both of these things to VNC would be pretty easy.  I 
> think the result would probably be better than a heuristic based
> mjpeg (simply because of the accelerated scaling).
> 
> Any thoughts on that?  Am I misunderstanding how the mjpeg works with 
> Spice and QXL?


I personaly dont like mjpeg, and yes in the end of the day you can add
the video streaming into vnc, but what is the point here?

We acctuly want to kick away that video streaming, and move into the
DirectX and X video extentions video support (that will be made using
the qxl driver) - will give much better performence.


> 
> > What you mean lack of guest visible rendering?, I might didnt
> > understand you
> >   
> 
> Sorry, I meant what Spice does with video memory (that it doesn't
> render a bitmap until the guest tries to read video memory).  If I
> understood that correctly, it sounds very interesting.  Again, I'd
> love to see the perf details around that.
> >>>> I'm not familiar with what a "depth viewing tree".  Can you
> >>>> elaborate? 
> >>>> 
> >>> In it simplest way of working, we will take the simplest case of
> >>> what it is doing:
> >>> If you have application that rendered a window, and then it
> >>> renendered another window on top of it, you dont want to send the
> >>> commands that rendered the old window, beacuse the new commands
> >>> hide the older one... 
> >>>   
> >> Ah, this is unique to a windowing protocol.  A framebuffer protocol
> >> does not have to worry about this because the OS does it for you.
> >> 
> >
> > Not true.
> > This is optimization for remote rendering, in physical machines we
> > can rendner what ever we want, it take more cpu to try to use trees
> > in order to render the right things
> > But with remote machines, we dont want to stress the network, so we
> > want to transfer just what we really need.
> >   
> 
> If the z-order of the window is such that one window is not
> displayed, then it's contents will not be rendered.  In Windows,
> individual windows only receive a WM_PAINT message with the visible
> region.  Not all apps clip accordingly of course.
> 
> For X, only windows that are visible receive expose events and again, 
> they're given a clipping region with what is actually displayed.
> 
> By the time we get to video memory, the display server has already 
> straightened out what portions of the screen are visible and what 
> aren't.  It will not render a hidden window and then render another 
> window on top of it.

I dont understand, if you have applciation that draw Rectangle, and
just another Recta

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
malc  wrote:

> On Fri, 11 Dec 2009, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> > malc  wrote:
> > 
> > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > 
> > > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > > malc  wrote:
> > > > 
> > > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > > 
> > > > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > > > Anthony Liguori  wrote:
> > > > > > 
> > > > > [..snip..]
> > > > > 
> > > > > > 
> > > 
> > > [..snip..]
> > > 
> > > > > 
> > > > > Any particular reason for implementing audio as a driver
> > > > > instead of a capture?
> > > > 
> > > > 
> > > > Spice doesnt have paravirtual audio driver, it use the AC97
> > > > device.
> > > 
> > > Yes it has - interface_audio_driver in audio/vd_interface_audio.c
> > > 
> > 
> > I think the file name here is missleading you...
> 
> I think you just don't understand what i'm asking. Let me try to
> expand: one way to implement audio interception is by having a special
> audio_driver (wavaudio.c vd_interface_audio.c) the other is by using
> a capture interface atop of existing driver (wavcapture.c vnc.c)
> 
> I was curious as to why the former was chosen.
> 

I see what you mean, I didnt write this part, so i will have to ask who
wrote it and will come back to you with an answer why he did it like
that.

Thanks.

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 13:51:53 -0600
Anthony Liguori  wrote:

> libc is not a plugin.  It implements very well defined behaviors that 
> have well understood behaviors.  Also, glibc generally does not crash 
> :-)  I would not want a user to replace glibc with a different libc.

I think it problomatic to say "I dont want to use this library" beacuse
"Librarys can crush", do you have any reason to say it on spice? did
you look on the code and saw huge ugly bugs?

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 14:46:55 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > I personaly dont like mjpeg, and yes in the end of the day you can
> > add the video streaming into vnc, but what is the point here?
> >   
> 
> What I'm trying to understand is, what can we do with Spice that we 
> couldn't possibly do with vnc.  That means understanding each feature 
> and then figuring out if there's a vnc analog.
> 
> If there are compellingly unique features to Spice that can't be 
> duplicated in vnc, then it's a no brainer.  If you can do most things
> in vnc but it would be hackish whereas Spice makes it all elegant,
> then provided we can merge Spice without a huge amount of pain, then
> it's a net win.
> 
> However, if we need to make a few changes to vnc in order to get the 
> same performance as Spice, then it's not quite as clear that it's
> what we should be using.
> 
> We're talking about a major change here.  There is a ton of
> management software that assumes vnc today.  Even though there are
> Spice clients out there, there are embedded vnc clients in certain
> tools today along with java applets.
> 
> That's not to say we shouldn't embrace Spice, we just have to make
> sure we have a good reason to.

Ok, I understand your concerns.

But even though that spice and vnc achive in the end of the day the
same thing - they both allow remote rendering, they have fendumental
diffrent architacture.

Spice server work with a ring to the guest, it was build from day one
to work like that, In addition it was built from day one so that the
server will render only what it must to render (to allow much higher
virtualization denticity).

Just to make clear how much spice is diffrence from VNC is by the fact
that only the library itself (not including the drivers) have 128,277
lines of code inside it. (In my old qemu repo i see almost 600,000
lines for qemu) so this should give better prespective on how much
spice is diffrent from vnc.

So ofcurse in theory you can take all this 128,000 lines and push them
into qemu-vnc.c ?, but you got to remember that spice is not just
specific qemu thing, Spice should be used to work on physical machines
too, just cutting all this lines of code from spice and throw it into
qemu-vnc.c will be meaning a fork of spice inside qemu

It isnt just the rings and the rendering style that make spice
diffrence, it is the channels it have for each compoment, it is the
multiple drawing surfaces, and so on...

This why the VDI interfaces were made, it was made so who ever used
VNC, can still use it, whoever want to use SPICE can still use spice,

By merging SPICE you just merge VDI interfaces, not the library
itself, it is so self contained thanks to the VDI interfaces, that it
almost dont touch anything inside qemu, I belive this was one of the
best aurgoments when Avi pushed kvm into the kernel - the fact that it
was a module that can be easyly removed if ppl dont want to use it. 


> 
> > We acctuly want to kick away that video streaming, and move into the
> > DirectX and X video extentions video support (that will be made
> > using the qxl driver) - will give much better performence.
> >   
> 
> Okay, I suspect we're in agreement here then.

Thanks God ! ;-)


> 
> >> By the time we get to video memory, the display server has already 
> >> straightened out what portions of the screen are visible and what 
> >> aren't.  It will not render a hidden window and then render
> >> another window on top of it.
> >> 
> >
> > I dont understand, if you have applciation that draw Rectangle, and
> > just another Rectanlge on top of it, wont it hide it?, doesnt we
> > want just to send the newest Rectangle?
> >   
> 
> If you're using something like gdk, the toolkit double buffers
> windows by default and does a single flip on expose.  So this sort of
> thing never makes it way to the X server.  But the other point is, if
> you draw a rectangle with gdk, all the X server ever sees is the
> drawing of an image.

Spice work on the driver primitives it doesnt know what is GDK, if the
X driver will draw rectangle and then another rectangle, VNC will have
to draw it twice, spice not.


> 
> > Well any driver can use what ever spice commands it want, the X
> > driver doesnt have to use all the spice commands, what is so bad
> > about that? 
> 
> What I'm asking is what's the performance of the X driver vs. say,
> VNC? Do these high level operations really make sense for a Linux
> guest if we cannot ever implement them in an X driver?

Ohh, The performence is much better user interactive and higher density
the user interactive come from the paravirtual device and t

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 14:48:53 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 13:51:53 -0600
> > Anthony Liguori  wrote:
> >
> >   
> >> libc is not a plugin.  It implements very well defined behaviors
> >> that have well understood behaviors.  Also, glibc generally does
> >> not crash :-)  I would not want a user to replace glibc with a
> >> different libc. 
> >
> > I think it problomatic to say "I dont want to use this library"
> > beacuse "Librarys can crush", do you have any reason to say it on
> > spice? did you look on the code and saw huge ugly bugs?
> >   
> 
> Libraries are fine.  But libraries are not plugins.
> 
> It's the difference between qemu writing directly to libspice verses 
> having a libspice-vdi that implements the VDI plugin interface and
> then a mechanism in qemu to load arbitrary libraries that implement
> the VDI interface.
> 
> If I understand correctly, VDI is a plugin interface.

Ok, I guess you think VDI-interfaces are doing much more than they do
in reiality.

It is just simple interface to Allow Spice / VNC / whatever not have to
de-duplicate code in order to get information from - lets say the
keyboard

Is it really diffrence from any other function callbacks that used for
such purpuse?


> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 15:54:52 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> >>>> By the time we get to video memory, the display server has
> >>>> already straightened out what portions of the screen are visible
> >>>> and what aren't.  It will not render a hidden window and then
> >>>> render another window on top of it.
> >>>> 
> >>>> 
> >>> I dont understand, if you have applciation that draw Rectangle,
> >>> and just another Rectanlge on top of it, wont it hide it?, doesnt
> >>> we want just to send the newest Rectangle?
> >>>   
> >>>   
> >> If you're using something like gdk, the toolkit double buffers
> >> windows by default and does a single flip on expose.  So this sort
> >> of thing never makes it way to the X server.  But the other point
> >> is, if you draw a rectangle with gdk, all the X server ever sees
> >> is the drawing of an image.
> >> 
> >
> > Spice work on the driver primitives it doesnt know what is GDK, if
> > the X driver will draw rectangle and then another rectangle, VNC
> > will have to draw it twice, spice not.
> >   
> 
> The point is, there isn't a "draw a rectangle" primitive in X.  There 
> also isn't a "draw some text using this font" in X.[1]
> 
> These things exist at higher levels (like GTK and QT).
> 
> [1] there actually are but modern applications don't use them.


While X can use just the Fill and Copy commands for spice, no one block
driver writer to add the GTK / QT levels you are talking about and send
this commands into spice (Xrender???), In addition to the Fill and Copy
commands spice can help improve performence with offscreen surfaces
support that allowing sending the pixmaps in the background while the
network is idle.

We are currently at the moment just implmented the X driver and we are
working to add better support for spice in this area (probably
it will be improvments regerding to xrender), so this parts have still
big potential to improve in spice.

In addition when we will merge the 3d support, driver would be able to
translate opengl commands into spice 3d commands.



> 
> > Ohh, The performence is much better user interactive and higher
> > density the user interactive come from the paravirtual device and
> > the fact that we dont send commands that were "hide" into the
> > client.
> >
> > The higher density come from the fact that the server that run the
> > VM (qemu) almost never have to render the stuff
> >   
> 
> With the Linux guest driver?  If you can quantify that, it would be
> very useful.

The X driver is still very new, we have still a way to go to add all
what X need to achive the performence spice can offer.

> 
> >> Are there plans to integrate Spice support in gdk (or cairo)?  I
> >> think that would be required to get performance parity with
> >> Windows. 
> >
> > Can you expline more what you mean?
> > Spice work on the driver primitives, so I am not sure I understand
> > here what you suggest...
> >   
> 
> I think the point I'm trying to get across, is that Windows has a 
> centralized architecture of drawing primitives and interfaces that is 
> relatively easy for drivers to hook into.
> 
> Linux doesn't have this.  Different things are handled in different 
> places and some layers (like GDK) aren't really made for hooking into.
> 
> What I'm trying to understand is whether it will be possible to 
> implement a lot of the Spice accelerations for Linux guests.



Xrender, and Opengl would be possible to be implment in spice
I think Xrender is what Cairo use for hardware accelration and this
much of what you need no?

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 23:08:01 +0100
Alexander Graf  wrote:

> 
> On 11.12.2009, at 22:13, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 14:46:55 -0600
> > Anthony Liguori  wrote:
> > 
> >> Izik Eidus wrote:
> >>> I personaly dont like mjpeg, and yes in the end of the day you can
> >>> add the video streaming into vnc, but what is the point here?
> >>> 
> >> 
> >> What I'm trying to understand is, what can we do with Spice that
> >> we couldn't possibly do with vnc.  That means understanding each
> >> feature and then figuring out if there's a vnc analog.
> >> 
> >> If there are compellingly unique features to Spice that can't be 
> >> duplicated in vnc, then it's a no brainer.  If you can do most
> >> things in vnc but it would be hackish whereas Spice makes it all
> >> elegant, then provided we can merge Spice without a huge amount of
> >> pain, then it's a net win.
> >> 
> >> However, if we need to make a few changes to vnc in order to get
> >> the same performance as Spice, then it's not quite as clear that
> >> it's what we should be using.
> >> 
> >> We're talking about a major change here.  There is a ton of
> >> management software that assumes vnc today.  Even though there are
> >> Spice clients out there, there are embedded vnc clients in certain
> >> tools today along with java applets.
> >> 
> >> That's not to say we shouldn't embrace Spice, we just have to make
> >> sure we have a good reason to.
> > 
> > Ok, I understand your concerns.
> > 
> > But even though that spice and vnc achive in the end of the day the
> > same thing - they both allow remote rendering, they have fendumental
> > diffrent architacture.
> > 
> > Spice server work with a ring to the guest, it was build from day
> > one to work like that, In addition it was built from day one so
> > that the server will render only what it must to render (to allow
> > much higher virtualization denticity).
> 
> The ring is from qemu <-> guest, right? I mean, qemu <-> client would
> be a TCP transport anyways, so the ring argument is void.


Beside the fact that we dont have the network overhead...

> 
> > Just to make clear how much spice is diffrence from VNC is by the
> > fact that only the library itself (not including the drivers) have
> > 128,277 lines of code inside it. (In my old qemu repo i see almost
> > 600,000 lines for qemu) so this should give better prespective on
> > how much spice is diffrent from vnc.
> > 
> > So ofcurse in theory you can take all this 128,000 lines and push
> > them into qemu-vnc.c ?, but you got to remember that spice is not
> > just specific qemu thing, Spice should be used to work on physical
> > machines too, just cutting all this lines of code from spice and
> > throw it into qemu-vnc.c will be meaning a fork of spice inside
> > qemu
> 
> I definitely understand your point of having a single protocol. The
> good news is that your physical machine stuff isn't released yet
> (AFAIK), so luckily there's still time to change parts of the
> protocol :-).
> 
> > It isnt just the rings and the rendering style that make spice
> > diffrence, it is the channels it have for each compoment, it is the
> > multiple drawing surfaces, and so on...
> 
> These should be fairly easy to implement in VNC too. In fact, I
> remember a project implementing off-screen drawing in VNC using a
> larger region of the screen than what was visible and then copyrect
> them in.

In theory you can even change the whole of VNC into SPICE or the whole
of VI into EMACS, so???, I personaly think changing code isnt the
problem, the problem is always the desgien, and SPICE have fandumental
diffrent desgien than VNC, (Here you can say: OK I can make my VNC
desgien like SPICE, or you can say I think SPICE dsgien is bad, or you
can just use SPICE...)

> 
> > This why the VDI interfaces were made, it was made so who ever used
> > VNC, can still use it, whoever want to use SPICE can still use
> > spice,
> > 
> > By merging SPICE you just merge VDI interfaces, not the library
> > itself, it is so self contained thanks to the VDI interfaces, that
> > it almost dont touch anything inside qemu, I belive this was one of
> > the best aurgoments when Avi pushed kvm into the kernel - the fact
> > that it was a module that can be easyly removed if ppl dont want to
> > use it. 
> > 
> > 
> >> 
> >>> We acctuly want

[Qemu-devel] Re: X support for QXL and SPICE

[Izik Eidus]

On 12 Dec 2009 00:58:13 +0100
Soeren Sandmann  wrote:

> 
> However, as things stand right now, there is not much point in adding
> this support, because X applications essentially always work like
> this:
> 
> - render to offscreen pixmap
> - copy pixmap to screen
> 
> There is not yet support for offscreen pixmaps in SPICE, so at the
> moment, solid fill and CopyArea are the two main things that actually
> make a difference.

I Have patch that already add this support, we delayed it integration
in order that we will make sure that the new surfaces/offscreens
architacture would work well for all the users (windows and X), we
should see it in very soon.

Thanks.

> 
> 
> Soren

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 00:54:47 +0100
Alexander Graf  wrote:

> 
> On 11.12.2009, at 23:46, Izik Eidus wrote:
> 
> > On Fri, 11 Dec 2009 23:08:01 +0100
> > Alexander Graf  wrote:
> > 
> >> 
> >> On 11.12.2009, at 22:13, Izik Eidus wrote:
> >> 
> >>> On Fri, 11 Dec 2009 14:46:55 -0600
> >>> Anthony Liguori  wrote:
> >>> 
> >>>> Izik Eidus wrote:
> >>>>> I personaly dont like mjpeg, and yes in the end of the day you
> >>>>> can add the video streaming into vnc, but what is the point
> >>>>> here?
> >>>>> 
> >>>> 
> >>>> What I'm trying to understand is, what can we do with Spice that
> >>>> we couldn't possibly do with vnc.  That means understanding each
> >>>> feature and then figuring out if there's a vnc analog.
> >>>> 
> >>>> If there are compellingly unique features to Spice that can't be 
> >>>> duplicated in vnc, then it's a no brainer.  If you can do most
> >>>> things in vnc but it would be hackish whereas Spice makes it all
> >>>> elegant, then provided we can merge Spice without a huge amount
> >>>> of pain, then it's a net win.
> >>>> 
> >>>> However, if we need to make a few changes to vnc in order to get
> >>>> the same performance as Spice, then it's not quite as clear that
> >>>> it's what we should be using.
> >>>> 
> >>>> We're talking about a major change here.  There is a ton of
> >>>> management software that assumes vnc today.  Even though there
> >>>> are Spice clients out there, there are embedded vnc clients in
> >>>> certain tools today along with java applets.
> >>>> 
> >>>> That's not to say we shouldn't embrace Spice, we just have to
> >>>> make sure we have a good reason to.
> >>> 
> >>> Ok, I understand your concerns.
> >>> 
> >>> But even though that spice and vnc achive in the end of the day
> >>> the same thing - they both allow remote rendering, they have
> >>> fendumental diffrent architacture.
> >>> 
> >>> Spice server work with a ring to the guest, it was build from day
> >>> one to work like that, In addition it was built from day one so
> >>> that the server will render only what it must to render (to allow
> >>> much higher virtualization denticity).
> >> 
> >> The ring is from qemu <-> guest, right? I mean, qemu <-> client
> >> would be a TCP transport anyways, so the ring argument is void.
> > 
> > 
> > Beside the fact that we dont have the network overhead...
> 
> Eh - when you connect to the VM remotely you still get the network
> overhead, because you're connecting to it via the network :-).

Yes but you send the data from the HOST networking, not from the
virtualized guest networking (That will later send it from the Host
networking)...


> 
> > 
> >> 
> >>> Just to make clear how much spice is diffrence from VNC is by the
> >>> fact that only the library itself (not including the drivers) have
> >>> 128,277 lines of code inside it. (In my old qemu repo i see almost
> >>> 600,000 lines for qemu) so this should give better prespective on
> >>> how much spice is diffrent from vnc.
> >>> 
> >>> So ofcurse in theory you can take all this 128,000 lines and push
> >>> them into qemu-vnc.c ?, but you got to remember that spice is not
> >>> just specific qemu thing, Spice should be used to work on physical
> >>> machines too, just cutting all this lines of code from spice and
> >>> throw it into qemu-vnc.c will be meaning a fork of spice inside
> >>> qemu
> >> 
> >> I definitely understand your point of having a single protocol. The
> >> good news is that your physical machine stuff isn't released yet
> >> (AFAIK), so luckily there's still time to change parts of the
> >> protocol :-).
> >> 
> >>> It isnt just the rings and the rendering style that make spice
> >>> diffrence, it is the channels it have for each compoment, it is
> >>> the multiple drawing surfaces, and so on...
> >> 
> >> These should be fairly easy to implement in VNC too. In fact, I
> >> remember a project implementing off-screen drawing in VNC using a
> >> 

Re: [Qemu-devel] Re: X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 01:05:36 +0100
Alexander Graf  wrote:


> 
> What does performance look like in comparison to Xrdp? That one does
> implement bitmap caches. It should be really really close, right?

Untill Spice wont have the opengl support merged, I dont think it fair
to compare it into other stuff that do X, the opengl 3d rendering
should take much of spice advantages and work on spice better (at
least this my opinion)

And beside Linux you got Windows that in that area Spice is much more
advanced... 

> 
> Don't get me wrong - I'm not trying to talk anyone into what's best
> for anyone. I'm trying to understand what speed we can expect from
> which solution and what actually speeds up what :-).


We dont get you wrong :).


> 
> Alex
> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 01:27:09 +0100
Alexander Graf  wrote:

> 
> On 12.12.2009, at 01:14, Izik Eidus wrote:
> 
> > On Sat, 12 Dec 2009 00:54:47 +0100
> > Alexander Graf  wrote:
> > 
> >> 
> >> On 11.12.2009, at 23:46, Izik Eidus wrote:
> >> 
> >>> On Fri, 11 Dec 2009 23:08:01 +0100
> >>> Alexander Graf  wrote:
> >>> 
> >>>> 
> >>>> On 11.12.2009, at 22:13, Izik Eidus wrote:
> >>>> 
> >>>>> On Fri, 11 Dec 2009 14:46:55 -0600
> >>>>> Anthony Liguori  wrote:
> >>>>> 
> >>>>>> Izik Eidus wrote:
> >>>>>>> I personaly dont like mjpeg, and yes in the end of the day you
> >>>>>>> can add the video streaming into vnc, but what is the point
> >>>>>>> here?
> >>>>>>> 
> >>>>>> 
> >>>>>> What I'm trying to understand is, what can we do with Spice
> >>>>>> that we couldn't possibly do with vnc.  That means
> >>>>>> understanding each feature and then figuring out if there's a
> >>>>>> vnc analog.
> >>>>>> 
> >>>>>> If there are compellingly unique features to Spice that can't
> >>>>>> be duplicated in vnc, then it's a no brainer.  If you can do
> >>>>>> most things in vnc but it would be hackish whereas Spice makes
> >>>>>> it all elegant, then provided we can merge Spice without a
> >>>>>> huge amount of pain, then it's a net win.
> >>>>>> 
> >>>>>> However, if we need to make a few changes to vnc in order to
> >>>>>> get the same performance as Spice, then it's not quite as
> >>>>>> clear that it's what we should be using.
> >>>>>> 
> >>>>>> We're talking about a major change here.  There is a ton of
> >>>>>> management software that assumes vnc today.  Even though there
> >>>>>> are Spice clients out there, there are embedded vnc clients in
> >>>>>> certain tools today along with java applets.
> >>>>>> 
> >>>>>> That's not to say we shouldn't embrace Spice, we just have to
> >>>>>> make sure we have a good reason to.
> >>>>> 
> >>>>> Ok, I understand your concerns.
> >>>>> 
> >>>>> But even though that spice and vnc achive in the end of the day
> >>>>> the same thing - they both allow remote rendering, they have
> >>>>> fendumental diffrent architacture.
> >>>>> 
> >>>>> Spice server work with a ring to the guest, it was build from
> >>>>> day one to work like that, In addition it was built from day
> >>>>> one so that the server will render only what it must to render
> >>>>> (to allow much higher virtualization denticity).
> >>>> 
> >>>> The ring is from qemu <-> guest, right? I mean, qemu <-> client
> >>>> would be a TCP transport anyways, so the ring argument is void.
> >>> 
> >>> 
> >>> Beside the fact that we dont have the network overhead...
> >> 
> >> Eh - when you connect to the VM remotely you still get the network
> >> overhead, because you're connecting to it via the network :-).
> > 
> > Yes but you send the data from the HOST networking, not from the
> > virtualized guest networking (That will later send it from the Host
> > networking)...
> 
> Exactly. So you'd get the same as with virtio-fb and VNC :-).

Yes, virtio-fb and spice have the same overhead for the ring part,
but this not what i understood when you said:
"The ring is from qemu <-> guest, right? I mean, qemu <-> client
 would be a TCP transport anyways, so the ring argument is void."

But leave it :).

> 
> > 
> > 
> >> 
> >>> 
> >>>> 
> >>>>> Just to make clear how much spice is diffrence from VNC is by
> >>>>> the fact that only the library itself (not including the
> >>>>> drivers) have 128,277 lines of code inside it. (In my old qemu
> >>>>> repo i see almost 600,000 lines for qemu) so this should give
> >>>>> better prespective on how much spice is diffrent from vnc.
> >>>>> 

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 02:08:05 +0100
Alexander Graf  wrote:

> So the thing I dislike is the "take all of QXL and SPICE or leave
> everything" sort of attitude that's coming over. I'd love to use QXL,
> but I don't want to use SPICE :-). Thus I want to make sure we're
> going in a really modular direction, so all the bits can be combined
> to every users' liking. Thus creating choice.

We are palning to add local rendering support for qxl inside qemu...

> 
> 
> Alex
> 

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Fri, 11 Dec 2009 21:31:34 -0600
Anthony Liguori  wrote:
> 
> Okay, that's in line with what my expectations were.  So what's the 
> future of Spice for X?  Anything clever or is Windows the only target 
> right now?

Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.

I dont understand what you want here?

Spice is not responsible for how X work the fact that X doesnt have
many things that windows have - doesnt mean it is bad spice DOES have
them...

Btw Xrender is used by cario hardware accelration...

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 09:13:51 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Fri, 11 Dec 2009 21:31:34 -0600
> > Anthony Liguori  wrote:
> >   
> >> Okay, that's in line with what my expectations were.  So what's
> >> the future of Spice for X?  Anything clever or is Windows the only
> >> target right now?
> >> 
> >
> > Offscreen pixmaps, Xrender, opengl 3d commands, Video extention.
> >
> > I dont understand what you want here?
> >   
> 
> To understand what makes Spice special.


Spice is interesting beacuse unlike the great VNC protocol it already
have what it take to make VDI possible to the user.

If you think all the above features are pointless and if you think that
Windows graphic systems (90% of the world wide desktops users) is not
important, I really dont know what to tell you.

It is easy to say about everything "We can implment it in VNC..." yes.
and I can write my own new operation system and tell everyone "Haa,
right now i dont have it, but it is easy to implement"...

It is naive to think that software is all about features..., In this
case Linux / Freebsd are the same thing..., ohh wait they are diffrent
no?.

Wait, I think Google, Yahoo and Bing, does`nt they all have the same
features, How come ppl still prefer to use Google in that case?

VNC is much older than spice, but still why it didnt get all this SPICE
protocol goodies? why? (I mean it is so easy to add this into VNC...)

> 
> > Spice is not responsible for how X work the fact that X doesnt have
> > many things that windows have - doesnt mean it is bad spice DOES
> > have them...
> >   
> 
> Don't confuse trying to understand Spice with attempts to poke holes
> or criticize Spice.  There is very little information about what
> makes Spice interesting.

There is a complete protocol paper that expline the whole protocol,
There is me answering you to any question that you ask,
There is the whole source open, what more do you need?

> 
> Regards,
> 
> Anthony Liguori
> 

[Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 09:25:00 -0600
Anthony Liguori  wrote:

> How does this work?
> 
> Does Spice only work with QXL or can it also work with Cirrus and 
> std-vga?  Does it degrade into basically a framebuffer based
> protocol? How does it encode the bitmap data in this mode?

It work with std-vga
It send bitmaps using the dirty bit from kvm/qemu

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 16:43:43 +0100
Alexander Graf  wrote:
> 
> 
> I'm always having a hard time understanding why VNC is slow. I've
> seriously always been wondering. And I'm still puzzled as to why RDP
> is so much superior performance-wise. After all, it basically only
> implements framebuffer updates too.

Not really, RDP does have commands in its protocol.
The latest RDP 7 is even more advance in that but lack the abilaty to
enjoy it when not using "same codecs / dx" support.

> 
> So now you bring in SPICE to that equation. I don't know _why_ SPICE
> is faster. I know that it is and I hear all those awesome great
> features. But I still don't have a feeling on which part of it really
> is the performance booster. As with the example above, I would never
> have guessed that doing synchronous updates is the performance
> killer. I'm still trying to figure out what is going wrong in VNC :-).
> 
> So don't take this as an offense. It's about learning from you guys.
> You're the ones that measured what makes things fast - and we want to
> know! Even if we're not building code on it, but using SPICE, it'd
> still be very valuable to know why exactly it is performing better.
> And best case also by how much each single feature saves us.


From my point of view, Effective commands transfer, Smart Depth tree
usage, Effective Cache, (the soon to be merged offscreens), Effective
Compression, and Effective Video streaming, this what need to have for
making things fast...

But It is not that easy as it sound, beacuse spice is really not just
about sending simple "draw_line command".

it is system that was desgiened to send commands from day one, and to
be used by kvm to reduce host cpu usage, The QXL driver, the QXL
Device, the Spice server, The spice Client, all of this peice of
software togather bring spice into what it is.

(As you saw above, you said it yourself, in the middle of making such
 system there are alot of performence questions, some times the answers
 are not absolute, And I sure VNC beat spice in some cases, But this is
 the whole point, allowing the user to choce what ever protocol he
 want)

Thanks.

> 
> 
> Alex
> 
> PS: Let me explain my background on those questions:
> 
> I'm stuck with VNC for SUSE Studio for now. While I can't make
> fundamental changes to the protocol, I can easily modify the guest
> and I can also easily modify the VNC viewer to add a few new
> commands. If I can get a throughput reduction of 50% by using 2 out
> of 10 features SPICE has as VNC protocol extensions, I'd gladly
> implement them. That'd just make user experience on our side a lot
> better. If that means using QXL inside the guest, so be it :-).
> 

[Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 11:19:19 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Sat, 12 Dec 2009 09:25:00 -0600
> > Anthony Liguori  wrote:
> >
> >   
> >> How does this work?
> >>
> >> Does Spice only work with QXL or can it also work with Cirrus and 
> >> std-vga?  Does it degrade into basically a framebuffer based
> >> protocol? How does it encode the bitmap data in this mode?
> >> 
> >
> > It work with std-vga
> > It send bitmaps using the dirty bit from kvm/qemu
> >   
> 
> How does it compress the bitmaps?

What you mean? how can it compress it? or what method?

When there is no driver installed, we use compression that based on
LZ...
How does it compress it?, it just send it to the spice server as
"Draw bitmap" command and the spice server send it to the client.

> 
> Regards,
> 
> Anthony Liguori

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 11:35:24 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > What you mean? how can it compress it? or what method?
> >
> > When there is no driver installed, we use compression that based on
> > LZ...
> >   
> 
> Okay, that's what I was asking.  I'm curious because during guest 
> installation, I assume that even if you're using QXL, you are still 
> stuck in VESA mode.


Correct.

> 
> I'm curious if LZ on it's own is significantly different than some of 
> the vnc encodings.  Both ZRLE and Tight have some pre-encoding 
> techniques that introduce a palette and in the case of Tight, also 
> support efficient gradient encoding.  The idea is that you end up
> with much more compressable data this way.
> 
> It's the sort of thing I think would be interesting to measure.  I
> think being able to use VNC style encodings could also be interesting
> for Spice in order to improve this "legacy mode" use-case.


That specific area in spice will be changed very soon due to new
requiments that the offscreens will add.
Windows direct draw allow modifying offscreen (or even primary)
surfaces using a pointer giving to the user, this mean we can`t know
what parts of the surface was changed... (In some modes the primary
screen can be changed without we know about this)

We already thought about few algorithems we might want to add to spice
to better address this "changed without notifications surfaces", But it
is still not in a state I can confirm in what direction we will go in
the end (We still need to test most of the cases to know what fit us
best)

Thanks.

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Re: Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 11:40:21 -0600
Anthony Liguori  wrote:

> FWIW, I don't see any reason why Spice couldn't be made to be
> separate from guest emulation.  I think it would just require the
> right interfacing in qemu.  I think that's purely an implementation
> detail.

The QXL device is one of the core compoments of spice..., how can you
separate it from the guest visible state? (it is pci device)

> 
> Regards,
> 
> Anthony Liguori
> 
> 

Re: [Qemu-devel] Re: Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 13:26:30 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > On Sat, 12 Dec 2009 11:40:21 -0600
> > Anthony Liguori  wrote:
> >
> >   
> >> FWIW, I don't see any reason why Spice couldn't be made to be
> >> separate from guest emulation.  I think it would just require the
> >> right interfacing in qemu.  I think that's purely an implementation
> >> detail.
> >> 
> >
> > The QXL device is one of the core compoments of spice..., how can
> > you separate it from the guest visible state? (it is pci device)
> >   
> 
> How does live migration work then?  Do you have to query libspice for 
> it's state?  Does it return an opaque blob?  How can it integrate
> with VMState since libspice doesn't have any knowledge of something
> like VMState?

QXL transfer the device states by itself using qemu migration
mechanisem.

The spice server just need that the pci memory (and the qxl ram/rom
state) will be migrate. (From the point of view of guest visible state)

All this guest visible states are transfered by the qxl device using
qemu.

> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] Re: Spice and legacy VGA drivers

[Izik Eidus]

On Sat, 12 Dec 2009 13:28:18 -0600
Anthony Liguori  wrote:

> Izik Eidus wrote:
> > That specific area in spice will be changed very soon due to new
> > requiments that the offscreens will add.
> > Windows direct draw allow modifying offscreen (or even primary)
> > surfaces using a pointer giving to the user, this mean we can`t know
> > what parts of the surface was changed... (In some modes the primary
> > screen can be changed without we know about this)
> >
> > We already thought about few algorithems we might want to add to
> > spice to better address this "changed without notifications
> > surfaces", But it is still not in a state I can confirm in what
> > direction we will go in the end (We still need to test most of the
> > cases to know what fit us best)
> >   
> 
> Okay, I'm interested in hearing more about this as it develops.  I
> think good support for legacy modes is an important requirement.
> 
> For instance, I very often interact with VMs in text console mode.
> In cloud deployments, it's pretty common to have minimal appliances
> that don't have a full X session.

Sure, this exactly why we still dont sure what kind of algorithem we
will use... , we are searching for something that wont deprived any
usage (Such as text console mode, or "modified by pointer surface")

Thanks.


> 
> Regards,
> 
> Anthony Liguori
> 

Re: [Qemu-devel] Re: Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 18:18:01 -0600
Anthony Liguori  wrote:

> Andrea Arcangeli wrote:
> > On Sat, Dec 12, 2009 at 05:52:49PM -0600, Anthony Liguori wrote:
> >   
> >> This is the bit that confuses me.  VNC is not a driver.  When I
> >> say it cannot crash the guest, I mean that if the VNC server makes
> >> a mistake, there may be a SEGV in qemu or it may just result in a
> >> VNC client seeing corruption.  The guest does not see a bad VGA
> >> register content though or something like that.  VNC is a host
> >> driver or backend service or whatever you want to call it.  VNC
> >> does not have migration state because it has no guest visible
> >> state. 
> >
> > Again, a guest crash because of qlx interaction is not what I
> > mean. And the reason I wasn't even thinking about this scenario is
> > that the kind of paravirt-driver related guest crash you are talking
> > about, if it can happen, can happen even if spice lib in the qemu
> > side lives in a separate address space.
> 
> Yes, that's absolutely true.
> 
> >  This is why this case of pure guest
> > crash through qlx is not relevant to decide if to have spice lib
> > inside our outside of qemu address space, I think that is more about
> > the qlx driver and not spice on the qemu side.
> >   
> 
> The guest visible state thing has nothing to do with where it lives.  
> Sorry if that's gotten mixed in with this discussion.

The guest visible state is just the qxl device.
It is pci device..., and it migrate just like any other pci device
inside qemu...

What am I missing here?

Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 22:26:59 +0200
Izik Eidus  wrote:

> On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
> malc  wrote:
> 
> > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > 
> > > On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
> > > malc  wrote:
> > > 
> > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > 
> > > > > On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
> > > > > malc  wrote:
> > > > > 
> > > > > > On Fri, 11 Dec 2009, Izik Eidus wrote:
> > > > > > 
> > > > > > > On Fri, 11 Dec 2009 09:57:48 -0600
> > > > > > > Anthony Liguori  wrote:
> > > > > > > 
> > > > > > [..snip..]
> > > > > > 
> > > > > > > 
> > > > 
> > > > [..snip..]
> > > > 
> > > > > > 
> > > > > > Any particular reason for implementing audio as a driver
> > > > > > instead of a capture?
> > > > > 
> > > > > 
> > > > > Spice doesnt have paravirtual audio driver, it use the AC97
> > > > > device.
> > > > 
> > > > Yes it has - interface_audio_driver in
> > > > audio/vd_interface_audio.c
> > > > 
> > > 
> > > I think the file name here is missleading you...
> > 
> > I think you just don't understand what i'm asking. Let me try to
> > expand: one way to implement audio interception is by having a
> > special audio_driver (wavaudio.c vd_interface_audio.c) the other is
> > by using a capture interface atop of existing driver (wavcapture.c
> > vnc.c)
> > 
> > I was curious as to why the former was chosen.
> > 
> 
> I see what you mean, I didnt write this part, so i will have to ask
> who wrote it and will come back to you with an answer why he did it
> like that.

Why sould we be any differnt from alsa or ogg, we are just another
audio player.


> 
> Thanks.
> 
> 

Re: [Qemu-devel] [PATCHv2] add "info ioapic" monitor command

[Izik Eidus]

On Wed, 30 Dec 2009 14:05:10 +0200
Gleb Natapov  wrote:

> On Wed, Dec 30, 2009 at 12:01:28PM +, Blue Swirl wrote:
> > On Wed, Dec 30, 2009 at 11:50 AM, Gleb Natapov  wrote:
> > > Knowing ioapic configuration is very useful for the poor soles
> > > how need to debug guest occasionally.
> > 
> > > +static struct IOAPICState *ioapic;
> > 
> > Ugly. 
> > 
> Agree

And now it seems like even you dont agree with me!!!

Re: [Qemu-devel] emulate the Intel-VT behavior on any type of CPU

[Izik Eidus]

andrzej zaborowski wrote:

On 20/01/2008, Alexander Graf <[EMAIL PROTECTED]> wrote:
  

He was talking about running SVM code in KQemu/KVM. It might work with
kqemu (I honestly have not tested it, but see no reason it shouldn't),
but definitely not with KVM. Simply said, you can not run KVM inside
of a KVM virtualized machine.



What would be the problem with supporting that in KVM? The host SVM
should just report that the guest is trying to execute an SVM insn and
generate an Illegal Operation which would be handled by qemu.

Regards


  
right now kvm never call to qemu for cpu emulation, qemu is used just 
for the devices,
if kvm have something that it need to emulate it have a small emulator 
inside the kernel,


(ofcruse with modification what you just said is possible)

[Qemu-devel] [PATCH] allow setting static slot values for pci devices from the command line

[Izik Eidus]

hi,
2 months ago i sent a patch that was called "static devfn" i described 
it as a patch that allow setting static value for the devfn
due to a bad name that i gave it there was a confusion about this patch, 
what it really was doing is allowing setting static values

for the pci slot,
i cleaned this patch again and change some stuff in it to make it more 
clear and send it now again.


this patch make it possible to define from the command line the static 
slot value for each pci device,
it was wrote for addressing a problem that right now qemu devices get 
their slot value in random way

(almost random, by the order in fact)
the problem with this is that when adding and removing devices some slot 
values can be changed

for each device,
this make at least windows unable to understand what happned to the 
device and mark it in yellow

color. (and will want you to reinstall it)

thanks

--
woof.

diff --git a/qemu/hw/pci.c b/qemu/hw/pci.c
index 545901c..9362ae7 100644
--- a/qemu/hw/pci.c
+++ b/qemu/hw/pci.c
@@ -85,6 +85,9 @@ static int  pcibus_load(QEMUFile *f, void *opaque, int version_id)
 return 0;
 }
 
+char static_slots[PCI_DEVICES_MAX][64];
+int static_slots_index = 0;
+
 PCIBus *pci_register_bus(pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
  qemu_irq *pic, int devfn_min, int nirq)
 {
@@ -146,6 +149,67 @@ int pci_device_load(PCIDevice *s, QEMUFile *f)
 return 0;
 }
 
+int pci_read_static_slot(PCIBus *bus, const char *name)
+{
+int i;
+int y;
+int count;
+
+for (i = 0; i < static_slots_index; i++) {
+count = 0;
+for (y = 0; y < sizeof(static_slots[0]) && name[y]; y++) {
+if (tolower(static_slots[i][y]) != tolower(name[y]))
+continue;
+count++;
+}
+/*if count is y we found slot value for this device name */
+if (count == y && y < sizeof(static_slots[0]) &&
+static_slots[i][y] == '=') {
+int slot;
+char *value_buffer;
+
+static_slots[i][sizeof(static_slots[0]) - 1] = '\0';
+value_buffer = strstr(static_slots[i], "=");
+if (!value_buffer)
+return -1;
+value_buffer++;
+slot = atoi(value_buffer);
+if (slot < 0)
+return -1;
+/*
+ * check if the slot is already registered in case this pci device
+ * is registering now not for the first time.
+ * in this case we increase the value of the slot by one untill
+ * we find a free slot
+ * note: you should provide devices we big enougth spaces beteween
+ * them if you want to register the same devices more than once
+ */
+for (; slot < 32; slot++)
+if (!bus->devices[slot * 8])
+return slot;
+return -1;
+}
+}
+return -1;
+}
+
+int pci_is_static_slot(int slot)
+{
+int i;
+char *value_buffer;
+
+for (i = 0; i < static_slots_index; i++) {
+static_slots[i][sizeof(static_slots[0]) - 1] = '\0';
+value_buffer = strstr(static_slots[i], "=");
+if (!value_buffer)
+continue;
+value_buffer++;
+if (slot == atoi(value_buffer))
+return 1;
+}
+return 0;
+}
+
 /* -1 for devfn means auto assign */
 PCIDevice *pci_register_device(PCIBus *bus, const char *name,
int instance_size, int devfn,
@@ -158,13 +222,20 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
 return NULL;
 
 if (devfn < 0) {
-for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
-if (!bus->devices[devfn])
-goto found;
-}
-return NULL;
-found: ;
+int slot;
+
+slot = pci_read_static_slot(bus, name);
+if (slot < 0) {
+for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
+if (!bus->devices[devfn] && !pci_is_static_slot(devfn / 8))
+goto found;
+}
+return NULL;
+found: ;
+} else
+devfn = slot * 8;
 }
+
 pci_dev = qemu_mallocz(instance_size);
 if (!pci_dev)
 return NULL;
diff --git a/qemu/vl.c b/qemu/vl.c
index 756e13d..54ddb9e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -29,6 +29,7 @@
 #include "hw/fdc.h"
 #include "hw/audiodev.h"
 #include "hw/isa.h"
+#include "hw/pci.h"
 #include "net.h"
 #include "console.h"
 #include "sysemu.h"
@@ -906,6 +907,26 @@ static void rtc_stop_timer(struct qemu_alarm_timer *t);
 
 #endif /* _WIN32 */
 
+static void set_static_slot(const char *optarg)
+{
+int i;
+extern int static_slots_index;
+extern char static_slots[PCI_DEVICES_MAX][64];
+  
+if (static_slots_index >= PCI_DEVICES_MAX) {
+fprintf(stderr, "Too many static-slots registred\n");
+exit(1);
+}
+pstrcpy(static_slots[st

[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support

[Izik Eidus]

On Thu, 2008-01-31 at 16:36 -0600, Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts.  The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been.  It also introduces CMOS support so the BIOS can build
> the appropriate e820 tables.
the CMOS addresses that we used to register the above 4 giga memory are
reserved and therefor the qemu bios does not know them
you have to patch the bios as well to make it work with above 4 giga

i once wrote this patch to qemu,

hope it still apply.

commit 21ea5f8286fd9cd7124dfa0865a213613b51add5
Author: Izik Eidus <[EMAIL PROTECTED]>
Date:   Mon Aug 20 17:46:04 2007 +0300

kvm: bios: add support to memory above the pci hole

the new memory region is mapped after address 0x1,
the bios take the size of the memory after the 0x1 from
three new cmos bytes.

diff --git a/bios/rombios.c b/bios/rombios.c
index 9ea2dbc..ac918ad 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -4078,22 +4078,25 @@ BX_DEBUG_INT15("case default:\n");
 #endif
 

-void set_e820_range(ES, DI, start, end, type)
+void set_e820_range(ES, DI, start, end, extra_start, extra_end, type)
  Bit16u ES;
  Bit16u DI;
  Bit32u start;
  Bit32u end;
+ Bit8u extra_start;
+ Bit8u extra_end;
  Bit16u type;
 {
 write_word(ES, DI, start);
 write_word(ES, DI+2, start >> 16);
-write_word(ES, DI+4, 0x00);
+write_word(ES, DI+4, extra_start);
 write_word(ES, DI+6, 0x00);
 
 end -= start;
+extra_end -= extra_start;
 write_word(ES, DI+8, end);
 write_word(ES, DI+10, end >> 16);
-write_word(ES, DI+12, 0x);
+write_word(ES, DI+12, extra_end);
 write_word(ES, DI+14, 0x);
 
 write_word(ES, DI+16, type);
@@ -4106,7 +4109,9 @@ int15_function32(regs, ES, DS, FLAGS)
   Bit16u ES, DS, FLAGS;
 {
   Bit32u  extended_memory_size=0; // 64bits long
+  Bit32u  extra_lowbits_memory_size=0;
   Bit16u  CX,DX;
+  Bit8u   extra_highbits_memory_size=0;
 
 BX_DEBUG_INT15("int15 AX=%04x\n",regs.u.r16.ax);
 
@@ -4179,11 +4184,18 @@ ASM_END
 extended_memory_size *= 1024;
 }
 
+extra_lowbits_memory_size = inb_cmos(0x5c);
+extra_lowbits_memory_size <<= 8;
+extra_lowbits_memory_size |= inb_cmos(0x5b);
+extra_lowbits_memory_size *= 64;
+extra_lowbits_memory_size *= 1024;
+extra_highbits_memory_size = inb_cmos(0x5d);
+
 switch(regs.u.r16.bx)
 {
 case 0:
 set_e820_range(ES, regs.u.r16.di,
-   0x000L, 0x0009fc00L, 1);
+   0x000L, 0x0009fc00L, 0, 0, 1);
 regs.u.r32.ebx = 1;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4192,7 +4204,7 @@ ASM_END
 break;
 case 1:
 set_e820_range(ES, regs.u.r16.di,
-   0x0009fc00L, 0x000aL, 2);
+   0x0009fc00L, 0x000aL, 0, 0, 2);
 regs.u.r32.ebx = 2;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4201,7 +4213,7 @@ ASM_END
 break;
 case 2:
 set_e820_range(ES, regs.u.r16.di,
-   0x000e8000L, 0x0010L, 2);
+   0x000e8000L, 0x0010L, 0, 0, 2);
 regs.u.r32.ebx = 3;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4211,7 +4223,7 @@ ASM_END
 case 3:
 set_e820_range(ES, regs.u.r16.di,
0x0010L,
-   extended_memory_size - ACPI_DATA_SIZE, 
1);
+   extended_memory_size - ACPI_DATA_SIZE 
,0, 0, 1);
 regs.u.r32.ebx = 4;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4221,7 +4233,7 @@ ASM_END
 case 4:
 set_e820_range(ES, regs.u.r16.di,
extended_memory_size - ACPI_DATA_SIZE,
-   extended_memory_size, 3); // ACPI RAM
+   extended_memory_size ,0, 0, 3); // ACPI 
RAM
 regs.u.r32.ebx = 5;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4231,7 +4243,20 @@ ASM_END
 case

[Qemu-devel] Re: [PATCH 2/6] Use correct types to enable > 2G support (v2)

[Izik Eidus]

On Sun, 2008-02-03 at 19:56 -0600, Anthony Liguori wrote:
> Hi Izik,

Hi

> 
> Anthony Liguori wrote:
> > Index: qemu/cpu-all.h
> > ===
> > --- qemu.orig/cpu-all.h 2008-02-01 15:24:45.0 -0600
> > +++ qemu/cpu-all.h  2008-02-01 15:28:48.0 -0600
> > @@ -695,7 +695,7 @@
> >  
> >  /* page related stuff */
> >  
> > -#define TARGET_PAGE_SIZE (1 << TARGET_PAGE_BITS)
> > +#define TARGET_PAGE_SIZE (1ul << TARGET_PAGE_BITS)
> >  #define TARGET_PAGE_MASK ~(TARGET_PAGE_SIZE - 1)
> >  #define TARGET_PAGE_ALIGN(addr) (((addr) + TARGET_PAGE_SIZE - 1) & 
> > TARGET_PAGE_MASK
> 
> Do you recall what this change fixed?  As Paul pointed out in IRC, using 
> the host type here doesn't really fix the problem (target_ulong would be 
> more appropriate).  However, we're both curious what problem it's 
> actually fixing since sign extending the int should just work.

ok the commit say:

   kvm: qemu: change the type of the various page masks to unsigned long

   prevents truncation with >=4GB of guest physical memory


as far as i remember it was used to address something with
cpu_physical_memory_rw() probably related to &TARGET_PAGE_SIZE
or ~TARGET_PAGE_SIZE,

the fact is that i dont know if it ever fixed anything

[Qemu-devel] Re: [kvm-devel] [PATCH 1/5] Use correct types to enable > 2G support (v3)

[Izik Eidus]

On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
> KVM supports more than 2GB of memory for x86_64 hosts.  The following patch
> fixes a number of type related issues where int's were being used when they
> shouldn't have been.  It also introduces CMOS support so the BIOS can build
> the appropriate e820 tables.

again, you need patch the bios for this, as the bochs bios doesnt know
how to map memory above 4 giga, and it doesnt know about this CMOS
addresses, (look at the patch that i sent)

> 
> For v2 of this patch, I've moved ram_addr_t to cpu-all.h and switched
> ram_size to be a ram_addr_t.  I've also removed the memory limit check for
> x86_64 (provided kqemu isn't enabled) and enabled the use of a 'M' or 'G'
> suffix for the -m option.  I've also tried to do a more thorough job of
> updating the code to use the proper types.
> 
> This patch also includes support for setting up > 2GB of memory for
> TARGET_I386.  KVM works quite happily with 5GB of ram but I suspect there
> are still some uint32_t's in the non-KVM does not work when using more than
> 3GB of RAM.

yes, the patch for kvm was never desgiend to solve the problems qemu
would have with above 4 giga memory.

[Qemu-devel] Re: [kvm-devel] [PATCH 1/5] Use correct types to enable > 2G support (v3)

[Izik Eidus]

On Mon, 2008-02-04 at 09:33 -0600, Anthony Liguori wrote:
> Izik Eidus wrote:
> > On Mon, 2008-02-04 at 09:11 -0600, Anthony Liguori wrote:
> >   
> >> KVM supports more than 2GB of memory for x86_64 hosts.  The following patch
> >> fixes a number of type related issues where int's were being used when they
> >> shouldn't have been.  It also introduces CMOS support so the BIOS can build
> >> the appropriate e820 tables.
> >> 
> >
> > again, you need patch the bios for this, as the bochs bios doesnt know
> > how to map memory above 4 giga, and it doesnt know about this CMOS
> > addresses, (look at the patch that i sent)
> >   
> 
> Right, but the important point is, that in the absence of the bochs 
> BIOS, this patch does no harm.

yes, you are right, but beacuse that i saw that you patching the bios
i thought you wanted to do it as well and just didnt see my email...

> 
> Regards,
> 
> Anthony Liguori
> 

[Qemu-devel] adding support for above 2giga for qemu. ( include patchs )

[Izik Eidus]

hey,
i have wrote a patch to qemu to allow it to run with above the 2giga 
limitations we have now.
i tested it on qemu that used kvm with 14giga of ram, and it was tested at 
other place with 32giga of ram to the guest ( 32bits, and 64bits).

the patch that i send here, is patch to qemu without kvm,
it include patch to the bochs bios, and patch to the qemu.
part of the patch to qemu fix the typedefs varibles to unsigned long, and it is 
based on patch i saw at this list
that target sparc.

for some reason the mapping that i do inside qemu with 
cpu_register_physical_memory dont work, and with this patchs
qemu could not work with more than 3.75giga of ram. ( with kvm it does 
working... )

this is request for comment, i probbley doing something wrong inside qemu, so 
anyone have idea how to solve it
please comment :)


anyway for to make it easy to run i put here compiled patched bios.

have fun! :-)


bochs_bios_ram_patch
Description: bochs_bios_ram_patch


qemu_ram_patch
Description: qemu_ram_patch

Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )

[Izik Eidus]

well, i used kind of older patch from you,
for to get it to work in pc, you have to change the cmos
and the vga page0, and page1 as well...

anyway you have anyidea why it is working with kvm above 4giga and not
with qemu??? can you look at how i did the mapping in qemu?

Re: [Qemu-devel] adding support for above 2giga for qemu. ( include patchs )

[Izik Eidus]

On Thu, 2007-08-16 at 21:41 +0300, Blue Swirl wrote:
> On 8/14/07, Izik Eidus <[EMAIL PROTECTED]> wrote:
> > anyway you have anyidea why it is working with kvm above 4giga and not
> > with qemu??? can you look at how i did the mapping in qemu?
> 
> Kqemu is not compatible with >2G, does it change anything if you run
> without kqemu?
> 

i compiled it without Kqemu support.
i dont work with qemu emulator, but was working with kvm + qemu tested
on 32giga ram.
> Also the assembly versions of softmmu access functions would need
> changing. To avoid that, you could try qemu on x86_64 or comment out
> the line for ASM_SOFTMMU in target-i386/op.c.
> 

i will check this
> 

[Qemu-devel] Re: Updated >2G memory patch

[Izik Eidus]

Blue Swirl wrote:

I updated the >2G memory patch a bit. It seems that Linux and the BSDs
do not support having more than 4G of memory on Sparc32. There may
have been real machines with up to 5G of memory and even 16G on Crays,
but probably Linux hasn't been ported to those systems.

Therefore I don't have much interest to continue to this direction. Is
the patch OK for other targets? I'd like to commit this soon.
  

few notes about code from my side:
pc.c:
cpu_register_physical_memory(0x1, above_bios_mem_size, ram_addr 
+ ram_size);

should be
cpu_register_physical_memory(0x1, above_bios_mem_size,  ram_size);

cmos_init(ram_size - 128 * 1024 * 1024, above_bios_mem_size, 
boot_device, bs_table);

should be
cmos_init(ram_size, above_bios_mem_size, boot_device, bs_table);


+val = (unsigned int)above_bios_ram_size / 65536;
+rtc_set_memory(s, 0x5b, val);
+rtc_set_memory(s, 0x5c, val >> 8);
+rtc_set_memory(s, 0x5d, above_bios_ram_size/0x1);
would better be:
if (above_bios_ram_size)
   rtc_set_memory(s, 0x5b, (unsigned int) above_bios_ram_size>> 16);
   rtc_set_memory(s, 0x5c, (unsigned int)above_bios_ram_size>> 24);
   rtc_set_memory(s, 0x5d, above_bios_ram_size>> 32);
   }

vga.c:
unsigned long page0, page1;
should be
long page0, page1;

and of curse the patch to the bios is neccsery, i add here bios patch to 
the bios from the bochs cvs.


tomorrow i will check how all this stuff compile and run on machine with 
alot of ram.


thanks.

diff --git a/bios/rombios.c b/bios/rombios.c
index 9ea2dbc..ac918ad 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -4078,22 +4078,25 @@ BX_DEBUG_INT15("case default:\n");
 #endif
 
 
-void set_e820_range(ES, DI, start, end, type)
+void set_e820_range(ES, DI, start, end, extra_start, extra_end, type)
  Bit16u ES;
  Bit16u DI;
  Bit32u start;
  Bit32u end;
+ Bit8u extra_start;
+ Bit8u extra_end;
  Bit16u type;
 {
 write_word(ES, DI, start);
 write_word(ES, DI+2, start >> 16);
-write_word(ES, DI+4, 0x00);
+write_word(ES, DI+4, extra_start);
 write_word(ES, DI+6, 0x00);
 
 end -= start;
+extra_end -= extra_start;
 write_word(ES, DI+8, end);
 write_word(ES, DI+10, end >> 16);
-write_word(ES, DI+12, 0x);
+write_word(ES, DI+12, extra_end);
 write_word(ES, DI+14, 0x);
 
 write_word(ES, DI+16, type);
@@ -4106,7 +4109,9 @@ int15_function32(regs, ES, DS, FLAGS)
   Bit16u ES, DS, FLAGS;
 {
   Bit32u  extended_memory_size=0; // 64bits long
+  Bit32u  extra_lowbits_memory_size=0;
   Bit16u  CX,DX;
+  Bit8u   extra_highbits_memory_size=0;
 
 BX_DEBUG_INT15("int15 AX=%04x\n",regs.u.r16.ax);
 
@@ -4179,11 +4184,18 @@ ASM_END
 extended_memory_size *= 1024;
 }
 
+extra_lowbits_memory_size = inb_cmos(0x5c);
+extra_lowbits_memory_size <<= 8;
+extra_lowbits_memory_size |= inb_cmos(0x5b);
+extra_lowbits_memory_size *= 64;
+extra_lowbits_memory_size *= 1024;
+extra_highbits_memory_size = inb_cmos(0x5d);
+
 switch(regs.u.r16.bx)
 {
 case 0:
 set_e820_range(ES, regs.u.r16.di,
-   0x000L, 0x0009fc00L, 1);
+   0x000L, 0x0009fc00L, 0, 0, 1);
 regs.u.r32.ebx = 1;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4192,7 +4204,7 @@ ASM_END
 break;
 case 1:
 set_e820_range(ES, regs.u.r16.di,
-   0x0009fc00L, 0x000aL, 2);
+   0x0009fc00L, 0x000aL, 0, 0, 2);
 regs.u.r32.ebx = 2;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4201,7 +4213,7 @@ ASM_END
 break;
 case 2:
 set_e820_range(ES, regs.u.r16.di,
-   0x000e8000L, 0x0010L, 2);
+   0x000e8000L, 0x0010L, 0, 0, 2);
 regs.u.r32.ebx = 3;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4211,7 +4223,7 @@ ASM_END
 case 3:
 set_e820_range(ES, regs.u.r16.di,
0x0010L,
-   extended_memory_size - ACPI_DATA_SIZE, 1);
+   extended_memory_size - ACPI_DATA_SIZE ,0, 0, 1);
 regs.u.r32.ebx = 4;
 regs.u.r32.eax = 0x534D4150;
 regs.u.r32.ecx = 0x14;
@@ -4221,7 +4233,7 @@ ASM_END
  

Re: [Qemu-devel] Re: Updated >2G memory patch

[Izik Eidus]

Izik Eidus wrote:

Blue Swirl wrote:

cpu_register_physical_memory(0x1, above_bios_mem_size, 
ram_addr + ram_size);

should be
cpu_register_physical_memory(0x1, above_bios_mem_size,  
ram_size);
sorry, in qemu cvs cpu_register_physical_memory(0x1, 
above_bios_mem_size, ram_addr + ram_size); should be kept
cpu_register_physical_memory(0x1, above_bios_mem_size, ram_addr 
+ ram_size);

:)

[Qemu-devel] [PATCH] allow setting static devfn values for pci devices from the command line

[Izik Eidus]

hi,
this patch make it possible to define from the command line a static 
devfn value for each pci

device.
it was wrote for addressing a problem that right now qemu devices get 
their devfn in random way

(almost random)
the problem with this is that with adding and removing devices some 
devfn values can be changed

for each device.
this make (at least) windows unable to understand what happned to your 
device and mark it

in yellow color. (and will want you to reinstall it)

in this patch i simply use the device name that was registred with the 
pci device registration

function.
in case you have few devices from the same type (same name), it will 
simply increase each by one
so in this case all you have to do is give long enough  offset for the 
devfns from each other.


thanks
>From 3b26c9a10ddc01bf68c8d8e488559e3a082fa36b Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 17:41:49 +0200
Subject: [PATCH] qemu: allow setting static devfn for pci devices from the command line

Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
 hw/pci.c |   78 ++
 vl.c |   66 
 2 files changed, 139 insertions(+), 5 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 0b5e7bf..d12184c 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -52,6 +52,9 @@ target_phys_addr_t pci_mem_base;
 static int pci_irq_index;
 static PCIBus *first_bus;
 
+char static_devfns[PCI_DEVICES_MAX][128];
+int static_devfns_index = 0;
+
 PCIBus *pci_register_bus(pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
  qemu_irq *pic, int devfn_min, int nirq)
 {
@@ -98,6 +101,67 @@ int pci_device_load(PCIDevice *s, QEMUFile *f)
 return 0;
 }
 
+int pci_read_static_devfn(PCIBus *bus, const char *name)
+{
+int i;
+int y;
+int count;
+
+for (i = 0; i < static_devfns_index; i++) {
+count = 0;
+for (y = 0; y < sizeof(static_devfns[0]) && name[y]; y++) {
+if (tolower(static_devfns[i][y]) != tolower(name[y]))
+continue;
+count++;
+}
+/*if count is y we found devfn value for this device name */
+if (count == y && y < sizeof(static_devfns[0]) &&
+static_devfns[i][y] == '=') {
+int devfn;
+char *value_buffer;
+
+static_devfns[i][sizeof(static_devfns[0]) - 1] = '\0';
+value_buffer = strstr(static_devfns[i], "=");
+if (!value_buffer)
+return -1;
+value_buffer++;
+devfn = atoi(value_buffer);
+if (devfn < 0)
+return -1;
+/*
+ * check if the devfn is already registered in case this pci device
+ * is registering now not for the first time.
+ * in this case we increase the value of the devfn by one untill
+ * we find a free devfn
+ * note: you should provide devices we big enougth spaces beteween
+ * them if you want to register the same devices more than once
+ */
+for (; devfn < 256; devfn++)
+if (!bus->devices[devfn])
+return devfn;
+return -1;
+}
+}
+return -1;
+}
+
+int pci_is_static_devfn(int devfn)
+{
+int i;
+char *value_buffer;
+
+for (i = 0; i < static_devfns_index; i++) {
+static_devfns[i][sizeof(static_devfns[0]) - 1] = '\0';
+value_buffer = strstr(static_devfns[i], "=");
+value_buffer++;
+if (!value_buffer)
+continue;
+if (devfn == atoi(value_buffer))
+return 1;
+}
+return 0;
+}
+
 /* -1 for devfn means auto assign */
 PCIDevice *pci_register_device(PCIBus *bus, const char *name,
int instance_size, int devfn,
@@ -110,13 +174,17 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
 return NULL;
 
 if (devfn < 0) {
-for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
-if (!bus->devices[devfn])
-goto found;
+devfn = pci_read_static_devfn(bus, name);
+if (devfn < 0) {
+for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
+if (!bus->devices[devfn] && !pci_is_static_devfn(devfn))
+goto found;
+}
+return NULL;
+found: ;
 }
-return NULL;
-found: ;
 }
+
 pci_dev = qemu_mallocz(instance_size);
 if (!pci_dev)
 return NULL;
diff --git a/vl.c b/vl.c
index 8b2b5bd..7ae7275 100644
--- a/vl.c
+++ b/vl.c
@@ -29,6 +29,7 @@
 #include "hw/fdc.h"
 #include "hw/audiodev.h"
 #include "hw/isa.h"
+#include "hw/pci.h"
 #include 

Re: [Qemu-devel] [PATCH] allow setting static devfn values for pci devices from the command line

[Izik Eidus]

Izik Eidus wrote:

hi,
this patch make it possible to define from the command line a static 
devfn value for each pci

device.
it was wrote for addressing a problem that right now qemu devices get 
their devfn in random way

(almost random)
the problem with this is that with adding and removing devices some 
devfn values can be changed

for each device.
this make (at least) windows unable to understand what happned to your 
device and mark it

in yellow color. (and will want you to reinstall it)

in this patch i simply use the device name that was registred with the 
pci device registration

function.
in case you have few devices from the same type (same name), it will 
simply increase each by one
so in this case all you have to do is give long enough  offset for the 
devfns from each other.


thanks

ok here is a fix to two issues that i noticed:
1.in one place i declared static_devfns[MAX_PCI_DEVICS][64] and in other 
place: static_devfns[MAX_PCI_DEVICS][128]


2.in one place i did a calculation on a pointer line before i checked if 
it is vaild pointer...


anyway here it is again and fixed.
>From 6570e2859a43a1bc5178dc2130b1e91672fec6ae Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 18:49:48 +0200
Subject: [PATCH] qemu: allow setting static devfn for pci devices from the command line

Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
 hw/pci.c |   78 ++
 vl.c |   66 
 2 files changed, 139 insertions(+), 5 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index 0b5e7bf..3914704 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -52,6 +52,9 @@ target_phys_addr_t pci_mem_base;
 static int pci_irq_index;
 static PCIBus *first_bus;
 
+char static_devfns[PCI_DEVICES_MAX][64];
+int static_devfns_index = 0;
+
 PCIBus *pci_register_bus(pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
  qemu_irq *pic, int devfn_min, int nirq)
 {
@@ -98,6 +101,67 @@ int pci_device_load(PCIDevice *s, QEMUFile *f)
 return 0;
 }
 
+int pci_read_static_devfn(PCIBus *bus, const char *name)
+{
+int i;
+int y;
+int count;
+
+for (i = 0; i < static_devfns_index; i++) {
+count = 0;
+for (y = 0; y < sizeof(static_devfns[0]) && name[y]; y++) {
+if (tolower(static_devfns[i][y]) != tolower(name[y]))
+continue;
+count++;
+}
+/*if count is y we found devfn value for this device name */
+if (count == y && y < sizeof(static_devfns[0]) &&
+static_devfns[i][y] == '=') {
+int devfn;
+char *value_buffer;
+
+static_devfns[i][sizeof(static_devfns[0]) - 1] = '\0';
+value_buffer = strstr(static_devfns[i], "=");
+if (!value_buffer)
+return -1;
+value_buffer++;
+devfn = atoi(value_buffer);
+if (devfn < 0)
+return -1;
+/*
+ * check if the devfn is already registered in case this pci device
+ * is registering now not for the first time.
+ * in this case we increase the value of the devfn by one untill
+ * we find a free devfn
+ * note: you should provide devices we big enougth spaces beteween
+ * them if you want to register the same devices more than once
+ */
+for (; devfn < 256; devfn++)
+if (!bus->devices[devfn])
+return devfn;
+return -1;
+}
+}
+return -1;
+}
+
+int pci_is_static_devfn(int devfn)
+{
+int i;
+char *value_buffer;
+
+for (i = 0; i < static_devfns_index; i++) {
+static_devfns[i][sizeof(static_devfns[0]) - 1] = '\0';
+value_buffer = strstr(static_devfns[i], "=");
+if (!value_buffer)
+continue;
+value_buffer++;
+if (devfn == atoi(value_buffer))
+return 1;
+}
+return 0;
+}
+
 /* -1 for devfn means auto assign */
 PCIDevice *pci_register_device(PCIBus *bus, const char *name,
int instance_size, int devfn,
@@ -110,13 +174,17 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
 return NULL;
 
 if (devfn < 0) {
-for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
-if (!bus->devices[devfn])
-goto found;
+devfn = pci_read_static_devfn(bus, name);
+if (devfn < 0) {
+for(devfn = bus->devfn_min ; devfn < 256; devfn += 8) {
+if (!bus->devices[devfn] && !pci_is_static_devfn(devfn))
+goto found;
+}
+return NULL;
+found: ;
 }
-return NULL;
-found: ;
 }

Re: [Qemu-devel] [PATCH] allow setting static devfn values for pci devices from the command line

[Izik Eidus]

Jocelyn Mayer wrote:

On Mon, 2007-11-19 at 18:53 +0200, Izik Eidus wrote:
  

Izik Eidus wrote:


hi,
this patch make it possible to define from the command line a static 
devfn value for each pci

device.
it was wrote for addressing a problem that right now qemu devices get 
their devfn in random way

(almost random)
the problem with this is that with adding and removing devices some 
devfn values can be changed

for each device.
this make (at least) windows unable to understand what happned to your 
device and mark it

in yellow color. (and will want you to reinstall it)

in this patch i simply use the device name that was registred with the 
pci device registration

function.
in case you have few devices from the same type (same name), it will 
simply increase each by one
so in this case all you have to do is give long enough  offset for the 
devfns from each other.


thanks
  

ok here is a fix to two issues that i noticed:
1.in one place i declared static_devfns[MAX_PCI_DEVICS][64] and in other 
place: static_devfns[MAX_PCI_DEVICS][128]


2.in one place i did a calculation on a pointer line before i checked if 
it is vaild pointer...


anyway here it is again and fixed.



It seems that you cannot impose the PCI device numbers mapping, which is
likely to be architecture dependant. What you could however change is
the PCI bus & slot the device is inserted into, the same way you can
choose the PCI slot you put a PCI card into on a real machine. The
architecture could then determine what is the corresponding PCI device
number, given this PCI bus & slot numbers.

i will check this.

For other PCI devices, like PCI bridges or other internal devices, the
PCI slots / devfn are fixed by the architecture. You cannot change them
in any way, then it seems pointless to have an option that would change
the behavior for any of those devices.
The last problem I see is that it seems very ugly to hardcode the device
names the way you did in vl.c. This is even false in most cases, as most
of those devices are only available for a few machines and are not
tunable at all (for example macio or uninorth are only available in some
Apple Mac machines, not even all). 
  

so how will i inform the user with the devices name?

[Qemu-devel] [PATCH 1/2] Add missing hvdos public domain attribution:

[Izik Eidus]

hvf.c and vmx.h contain code from hvdos.c that is released as public domain:

from hvdos github: https://github.com/mist64/hvdos

"License

See LICENSE.txt (2-clause-BSD).

In order to simplify use of this code as a template, you can consider any parts 
from "hvdos.c" and "interface.h" as being in the public domain."

Signed-off-by: Izik Eidus 
---
 target/i386/hvf/hvf.c | 3 +++
 target/i386/hvf/vmx.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index 010866ed22..ab4820c3f5 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -17,6 +17,9 @@
  *
  * You should have received a copy of the GNU Lesser General Public
  * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * This file contain code under public domain from the hvdos project:
+ * https://github.com/mist64/hvdos
  */
 #include "qemu/osdep.h"
 #include "qemu-common.h"
diff --git a/target/i386/hvf/vmx.h b/target/i386/hvf/vmx.h
index 9dfcd2f2eb..162a7d51ae 100644
--- a/target/i386/hvf/vmx.h
+++ b/target/i386/hvf/vmx.h
@@ -17,6 +17,9 @@
  *
  * You should have received a copy of the GNU Lesser General Public
  * License along with this program; if not, see <http://www.gnu.org/licenses/>.
+ *
+ * This file contain code under public domain from the hvdos project:
+ * https://github.com/mist64/hvdos
  */
 
 #ifndef VMX_H
-- 
2.13.6 (Apple Git-96)

[Qemu-devel] [PATCH 2/2] ept_emulation_fault() need NetApp BSD attribution:

[Izik Eidus]

Moving it to a new file and add the BSD license there.

Signed-off-by: Izik Eidus 
---
 target/i386/hvf/ept_fault.h | 70 +
 target/i386/hvf/hvf.c   | 38 +---
 2 files changed, 71 insertions(+), 37 deletions(-)
 create mode 100644 target/i386/hvf/ept_fault.h

diff --git a/target/i386/hvf/ept_fault.h b/target/i386/hvf/ept_fault.h
new file mode 100644
index 00..c2938d2bd4
--- /dev/null
+++ b/target/i386/hvf/ept_fault.h
@@ -0,0 +1,70 @@
+/*-
+ * Copyright (c) 2011 NetApp, Inc.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY NETAPP, INC ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL NETAPP, INC OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef EPT_FAULT_H
+#define EPT_FAULT_H
+
+#include "hvf-i386.h"
+
+static inline bool ept_emulation_fault(hvf_slot *slot, uint64_t gpa, uint64_t 
ept_qual)
+{
+int read, write;
+
+/* EPT fault on an instruction fetch doesn't make sense here */
+if (ept_qual & EPT_VIOLATION_INST_FETCH) {
+return false;
+}
+
+/* EPT fault must be a read fault or a write fault */
+read = ept_qual & EPT_VIOLATION_DATA_READ ? 1 : 0;
+write = ept_qual & EPT_VIOLATION_DATA_WRITE ? 1 : 0;
+if ((read | write) == 0) {
+return false;
+}
+
+if (write && slot) {
+if (slot->flags & HVF_SLOT_LOG) {
+memory_region_set_dirty(slot->region, gpa - slot->start, 1);
+hv_vm_protect((hv_gpaddr_t)slot->start, (size_t)slot->size,
+  HV_MEMORY_READ | HV_MEMORY_WRITE);
+}
+}
+
+/*
+ * The EPT violation must have been caused by accessing a
+ * guest-physical address that is a translation of a guest-linear
+ * address.
+ */
+if ((ept_qual & EPT_VIOLATION_GLA_VALID) == 0 ||
+(ept_qual & EPT_VIOLATION_XLAT_VALID) == 0) {
+return false;
+}
+
+return !slot;
+}
+
+
+#endif
diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
index ab4820c3f5..94d8d119d5 100644
--- a/target/i386/hvf/hvf.c
+++ b/target/i386/hvf/hvf.c
@@ -36,6 +36,7 @@
 #include "x86_emu.h"
 #include "x86_task.h"
 #include "x86hvf.h"
+#include "ept_fault.h"
 
 #include 
 #include 
@@ -292,43 +293,6 @@ void hvf_cpu_synchronize_post_init(CPUState *cpu_state)
 run_on_cpu(cpu_state, _hvf_cpu_synchronize_post_init, RUN_ON_CPU_NULL);
 }
 
-static bool ept_emulation_fault(hvf_slot *slot, uint64_t gpa, uint64_t 
ept_qual)
-{
-int read, write;
-
-/* EPT fault on an instruction fetch doesn't make sense here */
-if (ept_qual & EPT_VIOLATION_INST_FETCH) {
-return false;
-}
-
-/* EPT fault must be a read fault or a write fault */
-read = ept_qual & EPT_VIOLATION_DATA_READ ? 1 : 0;
-write = ept_qual & EPT_VIOLATION_DATA_WRITE ? 1 : 0;
-if ((read | write) == 0) {
-return false;
-}
-
-if (write && slot) {
-if (slot->flags & HVF_SLOT_LOG) {
-memory_region_set_dirty(slot->region, gpa - slot->start, 1);
-hv_vm_protect((hv_gpaddr_t)slot->start, (size_t)slot->size,
-  HV_MEMORY_READ | HV_MEMORY_WRITE);
-}
-}
-
-/*
- * The EPT violation must have been caused by accessing a
- * guest-physical address that is a translation of a guest-linear
- * address.
- */
-if ((ept_qual & EPT_VIOLATION_GLA_VALID) == 0 ||
-(ept_qual & EPT_VIOLATION_XLAT_VALID) == 0) {
-return false;
-}
-
-return !slot;
-}
-
 static void hvf_set_dirty_tracking(MemoryRegionSection *section, bool on)
 {
 hvf_slot *slot;
-- 
2.13.6 (Apple Git-96)

[Qemu-devel] [PATCH 0/2] Add missing attributions to hvf:

[Izik Eidus]

The following 2 patch's add a missing attributions to the hvf code

Re: [Qemu-devel] [PATCH 2/2] ept_emulation_fault() need NetApp BSD attribution:

[Izik Eidus]

On Fri, Jan 26, 2018 at 11:39 AM, Paolo Bonzini  wrote:
> On 23/01/2018 13:36, Izik Eidus wrote:
>> Moving it to a new file and add the BSD license there.
>>
>> Signed-off-by: Izik Eidus 
>
> Since it's compatible, I'm just adding the NetApp BSD license to the file.

Sure.

>
> What is the original source?  xhyve or something like that?

This function is from freebsd:
sys/amd64/vmm/intel/vmx.c
http://web.mit.edu/freebsd/head/sys/amd64/vmm/intel/vmx.c


Thanks.

>
> Paolo
>
>> ---
>>  target/i386/hvf/ept_fault.h | 70 
>> +
>>  target/i386/hvf/hvf.c   | 38 +---
>>  2 files changed, 71 insertions(+), 37 deletions(-)
>>  create mode 100644 target/i386/hvf/ept_fault.h
>>
>> diff --git a/target/i386/hvf/ept_fault.h b/target/i386/hvf/ept_fault.h
>> new file mode 100644
>> index 00..c2938d2bd4
>> --- /dev/null
>> +++ b/target/i386/hvf/ept_fault.h
>> @@ -0,0 +1,70 @@
>> +/*-
>> + * Copyright (c) 2011 NetApp, Inc.
>> + * All rights reserved.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY NETAPP, INC ``AS IS'' AND
>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
>> PURPOSE
>> + * ARE DISCLAIMED.  IN NO EVENT SHALL NETAPP, INC OR CONTRIBUTORS BE LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, 
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>> + * SUCH DAMAGE.
>> + */
>> +
>> +#ifndef EPT_FAULT_H
>> +#define EPT_FAULT_H
>> +
>> +#include "hvf-i386.h"
>> +
>> +static inline bool ept_emulation_fault(hvf_slot *slot, uint64_t gpa, 
>> uint64_t ept_qual)
>> +{
>> +int read, write;
>> +
>> +/* EPT fault on an instruction fetch doesn't make sense here */
>> +if (ept_qual & EPT_VIOLATION_INST_FETCH) {
>> +return false;
>> +}
>> +
>> +/* EPT fault must be a read fault or a write fault */
>> +read = ept_qual & EPT_VIOLATION_DATA_READ ? 1 : 0;
>> +write = ept_qual & EPT_VIOLATION_DATA_WRITE ? 1 : 0;
>> +if ((read | write) == 0) {
>> +return false;
>> +}
>> +
>> +if (write && slot) {
>> +if (slot->flags & HVF_SLOT_LOG) {
>> +memory_region_set_dirty(slot->region, gpa - slot->start, 1);
>> +hv_vm_protect((hv_gpaddr_t)slot->start, (size_t)slot->size,
>> +  HV_MEMORY_READ | HV_MEMORY_WRITE);
>> +}
>> +}
>> +
>> +/*
>> + * The EPT violation must have been caused by accessing a
>> + * guest-physical address that is a translation of a guest-linear
>> + * address.
>> + */
>> +if ((ept_qual & EPT_VIOLATION_GLA_VALID) == 0 ||
>> +(ept_qual & EPT_VIOLATION_XLAT_VALID) == 0) {
>> +return false;
>> +}
>> +
>> +return !slot;
>> +}
>> +
>> +
>> +#endif
>> diff --git a/target/i386/hvf/hvf.c b/target/i386/hvf/hvf.c
>> index ab4820c3f5..94d8d119d5 100644
>> --- a/target/i386/hvf/hvf.c
>> +++ b/target/i386/hvf/hvf.c
>> @@ -36,6 +36,7 @@
>>  #include "x86_emu.h"
>>  #include "x86_task.h"
>>  #include "x86hvf.h"
>> +#include "ept_fault.h"
>>
>>  #include 
>>  #include 
>> @@ -292,43 +293,6 @@ void hvf_cpu_synchronize_post_init(CPUState *cpu_state)
>>  run_on_cpu(cpu_state, _hvf_cpu_synchronize_post_init, RUN_ON_CPU

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Thu, Aug 31, 2017 at 2:26 PM, Paolo Bonzini  wrote:

>
>
> Il 31 ago 2017 9:43 AM, "Stefan Hajnoczi"  ha scritto:
>
> On Wed, Aug 30, 2017 at 03:07:38PM +0100, Daniel P. Berrange wrote:
> > On Wed, Aug 30, 2017 at 03:26:51AM -0500, Sergio Andres Gomez Del Real
> wrote:
> > > diff --git a/target/i386/hvf-utils/x86.c b/target/i386/hvf-utils/x86.c
> > > new file mode 100644
> > > index 00..e3db2c9c8b
> > > --- /dev/null
> > > +++ b/target/i386/hvf-utils/x86.c
> > > @@ -0,0 +1,174 @@
> > > +/*
> > > + * Copyright (C) 2016 Veertu Inc,
> > > + * Copyright (C) 2017 Google Inc,
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU General Public License as
> > > + * published by the Free Software Foundation; either version 2 or
> > > + * (at your option) version 3 of the License.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU General Public License
> along
> > > + * with this program; if not, see .
> > > + */
> >
> > Again  v2-or-v3-only.
> >
> > There's many more files with this same problem but I'll stop pointing
> > them out now.
> >
> > If this is to be included in QEMU,  Veertu & Google (and any other
> > copyright holders) would have to agree to change these files to
> > v2-or-later
>
> Sergio: Have you or Paolo had any contact with the Veertu or Google
> authors about your Hypervisor.framework project?  If you're already in
> contact with them you could raise the issue and ask them to join this
> email thread.
>
>
> Izik, Vincent (assuming you are the right person to contact at Google),
> can you reply to Daniel and Stefan?
>

Hi,

What I suggest is that we will send our patch' again as gpl2+ and clean the
entire stuff to make sure they are falling into the right copyright
category as required by QEMU.

I think it will be easier to me to just integrate it all to QEMU  however I
need to know if to use the Google code or not (it is anyway not a big issue
from time perspective)

BTW, another thing that need to be integrated in order to make this stuff
useful is the vmnet patch's, it is apple NAT for vms that allow guests to
have networking... (altho that it come with a trick, without certificate it
will require root permission, while hypverisor framework itself can run
without root)

What do you guys think?


>
> Sergio worked on completing the QEMU port to Hypervisor.framework. The
> hvf-all.c file that Daniel pointed out as v2-only is derived from kvm-all.c
> and hax-all.c, and should be under v2-or-later license. The others seem to
> be either original or derived from Bochs, which is LGPL, so they could be
> LGPL or GPLv2+.
>
> Thanks,
>
> Paolo
>
>
> There are benefits to having this code upstream.  If they ever want to
> rebase on qemu.git there will be less work for them.
>
> Stefan
>
>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini  wrote:

> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
>
> > Izik, Vincent (assuming you are the right person to contact at Google),
> > can you reply to Daniel and Stefan?
> >
>
> Hi,
>
> What I suggest is that we will send our patch' again as gpl2+ and clean the
> entire stuff to make sure they are falling into the right copyright
> category as required by QEMU.
>
>
> That's not necessary. Just you and Vincent replying to this thread with a
> "Signed-off-by" line would be enough for Sergio to use the right license in
> his v3 submission. Sergio already made some non-trivial changes that are
> needed for inclusion in QEMU from a supportability (e.g. dirty page
> tracking for graphics) or maintainability perspective (e.g. -cpu support),
> so the simplest thing to do is to retrofit the right license to his
> submission. You can do so if you can confirm that the code you used only
> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
> was written by Veertu).
>

Hi,

Sure fine with us, let me go over all the code and see that all copyright
that are needed are there, and then you can relicense all our code to
GPLv2+, I think I saw a a file that was missing Bochs copyright in it, so I
want to make sure that I fix this before and that all others are fine.

Thanks.


>
> Google has already contributed the HAXN accelerator, so I am moderately
> optimistic that they can help with HVF too.
>
> BTW, another thing that need to be integrated in order to make this stuff
> useful is the vmnet patch's, it is apple NAT for vms that allow guests to
> have networking...
>
>
> People can always use slirp (or tap with some more effort), so these
> patches are already a minimum viable feature and pretty close to being
> mergeable. But of course any other contribution is welcome!
>
> Paolo
>
>
> (altho that it come with a trick, without certificate it
> will require root permission, while hypverisor framework itself can run
> without root)
>
> What do you guys think?
>
>
> >
> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
> > hvf-all.c file that Daniel pointed out as v2-only is derived from
> kvm-all.c
> > and hax-all.c, and should be under v2-or-later license. The others seem
> to
> > be either original or derived from Bochs, which is LGPL, so they could be
> > LGPL or GPLv2+.
> >
> > Thanks,
> >
> > Paolo
> >
> >
> > There are benefits to having this code upstream.  If they ever want to
> > rebase on qemu.git there will be less work for them.
> >
> > Stefan
> >
> >
> >
>
>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Fri, Sep 1, 2017 at 1:02 AM, Frank Yang  wrote:

> + our product manager
>
> If I understand correctly, we will need to reconsider things if I included
> any additional technology in my port. However, I didn't include any
> additional references/source in my port compared to Veertu, that was not in
> the qemu code already (e.g., hax-all/kvm-all) so I think we can just change
> the QEMU upstream port to use gplv2+.
>
> Izik, are you ok with this assessment?
>

Yes we are fine with changing everything to GPLv2+, I am just going over
the code and confirm that all copyright attributions as I saw a file that
was missing Bochs LGPLv2 copyright.



>
> On Thu, Aug 31, 2017 at 2:41 PM, Sergio Andrés Gómez del Real <
> sergio.g.delr...@gmail.com> wrote:
>
>> Hello,
>> Mr. Frank Yang was the guy at Google that introduced the HVF port to
>> Google's Android Emulator QEMU branch.
>> Frank, in this thread we are discussing the licensing issue with the HVF
>> files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu
>> developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs
>> and other GPLv2+ or LGPL software. Because the code at Google was itself
>> derived from Veertu, I'd imagine the same licensing terms would apply in
>> your case. Any light you can throw over this issue would be much
>> appreciated.
>>
>> Thank you.
>>
>> On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini 
>> wrote:
>>
>>> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
>>>
>>> > Izik, Vincent (assuming you are the right person to contact at Google),
>>> > can you reply to Daniel and Stefan?
>>> >
>>>
>>> Hi,
>>>
>>> What I suggest is that we will send our patch' again as gpl2+ and clean
>>> the
>>> entire stuff to make sure they are falling into the right copyright
>>> category as required by QEMU.
>>>
>>>
>>> That's not necessary. Just you and Vincent replying to this thread with
>>> a "Signed-off-by" line would be enough for Sergio to use the right license
>>> in his v3 submission. Sergio already made some non-trivial changes that are
>>> needed for inclusion in QEMU from a supportability (e.g. dirty page
>>> tracking for graphics) or maintainability perspective (e.g. -cpu support),
>>> so the simplest thing to do is to retrofit the right license to his
>>> submission. You can do so if you can confirm that the code you used only
>>> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
>>> was written by Veertu).
>>>
>>> Google has already contributed the HAXN accelerator, so I am moderately
>>> optimistic that they can help with HVF too.
>>>
>>> BTW, another thing that need to be integrated in order to make this stuff
>>> useful is the vmnet patch's, it is apple NAT for vms that allow guests to
>>> have networking...
>>>
>>>
>>> People can always use slirp (or tap with some more effort), so these
>>> patches are already a minimum viable feature and pretty close to being
>>> mergeable. But of course any other contribution is welcome!
>>>
>>
> That's what we do with networking in HVF for android emulator, btw; use
> slirp.
>


Yes, you guys can use our vmnet implemantion together proxy that we are
having to allow to run it without root, I think this proxy is making sense
for the android users as they won't required root, but for QEMU I think
only the vmnet implemantion will be wanted.
after this stuff will get merged we will send the vmnet stuff as GPLv2+ as
now it is GPLv2/GPLv3.

(BTW, I am pretty sure the copyright message that include GPLv2/GPLv3 and
created all this mess was taken from QEMU itself ... :))


>
>
>>
>>> Paolo
>>>
>>>
>>> (altho that it come with a trick, without certificate it
>>> will require root permission, while hypverisor framework itself can run
>>> without root)
>>>
>>> What do you guys think?
>>>
>>>
>>> >
>>> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
>>> > hvf-all.c file that Daniel pointed out as v2-only is derived from
>>> kvm-all.c
>>> > and hax-all.c, and should be under v2-or-later license. The others
>>> seem to
>>> > be either original or derived from Bochs, which is LGPL, so they could
>>> be
>>> > LGPL or GPLv2+.
>>> >
>>> > Thanks,
>>> >
>>> > Paolo
>>> >
>>> >
>>> > There are benefits to having this code upstream.  If they ever want to
>>> > rebase on qemu.git there will be less work for them.
>>> >
>>> > Stefan
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

Hi,

Sergio, I was trying to applying patch  1/13 and 2/13 and then I ran:
./configure and saw: 'HVF support   yes'
after that 'make' was happy
and:

./x86_64-softmmu/qemu-system-x86_64 --help | grep accel

\property accel=accel1[:accel2[:...]] selects accelerator

supported accelerators are kvm, xen, hax, hvf or tcg
(default: tcg)

kernel_irqchip=on|off|split controls accelerated irqchip
support (default=off)


however:

./x86_64-softmmu/qemu-system-x86_64 -cdrom
/Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine
q35,accel=hvf

qemu-system-x86_64: -machine accel=hvf: No accelerator found


What am I doing wrong?

Thanks.




On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real <
sergio.g.delr...@gmail.com> wrote:

> Hello,
> Mr. Frank Yang was the guy at Google that introduced the HVF port to
> Google's Android Emulator QEMU branch.
> Frank, in this thread we are discussing the licensing issue with the HVF
> files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu
> developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs
> and other GPLv2+ or LGPL software. Because the code at Google was itself
> derived from Veertu, I'd imagine the same licensing terms would apply in
> your case. Any light you can throw over this issue would be much
> appreciated.
>
> Thank you.
>
> On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini 
> wrote:
>
>> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
>>
>> > Izik, Vincent (assuming you are the right person to contact at Google),
>> > can you reply to Daniel and Stefan?
>> >
>>
>> Hi,
>>
>> What I suggest is that we will send our patch' again as gpl2+ and clean
>> the
>> entire stuff to make sure they are falling into the right copyright
>> category as required by QEMU.
>>
>>
>> That's not necessary. Just you and Vincent replying to this thread with a
>> "Signed-off-by" line would be enough for Sergio to use the right license in
>> his v3 submission. Sergio already made some non-trivial changes that are
>> needed for inclusion in QEMU from a supportability (e.g. dirty page
>> tracking for graphics) or maintainability perspective (e.g. -cpu support),
>> so the simplest thing to do is to retrofit the right license to his
>> submission. You can do so if you can confirm that the code you used only
>> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
>> was written by Veertu).
>>
>> Google has already contributed the HAXN accelerator, so I am moderately
>> optimistic that they can help with HVF too.
>>
>> BTW, another thing that need to be integrated in order to make this stuff
>> useful is the vmnet patch's, it is apple NAT for vms that allow guests to
>> have networking...
>>
>>
>> People can always use slirp (or tap with some more effort), so these
>> patches are already a minimum viable feature and pretty close to being
>> mergeable. But of course any other contribution is welcome!
>>
>> Paolo
>>
>>
>> (altho that it come with a trick, without certificate it
>> will require root permission, while hypverisor framework itself can run
>> without root)
>>
>> What do you guys think?
>>
>>
>> >
>> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
>> > hvf-all.c file that Daniel pointed out as v2-only is derived from
>> kvm-all.c
>> > and hax-all.c, and should be under v2-or-later license. The others seem
>> to
>> > be either original or derived from Bochs, which is LGPL, so they could
>> be
>> > LGPL or GPLv2+.
>> >
>> > Thanks,
>> >
>> > Paolo
>> >
>> >
>> > There are benefits to having this code upstream.  If they ever want to
>> > rebase on qemu.git there will be less work for them.
>> >
>> > Stefan
>> >
>> >
>> >
>>
>>
>>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini  wrote:

> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
>
> > Izik, Vincent (assuming you are the right person to contact at Google),
> > can you reply to Daniel and Stefan?
> >
>
> Hi,
>
> What I suggest is that we will send our patch' again as gpl2+ and clean the
> entire stuff to make sure they are falling into the right copyright
> category as required by QEMU.
>
>
> That's not necessary. Just you and Vincent replying to this thread with a
> "Signed-off-by" line would be enough for Sergio to use the right license in
> his v3 submission. Sergio already made some non-trivial changes that are
> needed for inclusion in QEMU from a supportability (e.g. dirty page
> tracking for graphics) or maintainability perspective (e.g. -cpu support),
> so the simplest thing to do is to retrofit the right license to his
> submission. You can do so if you can confirm that the code you used only
> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
> was written by Veertu).
>


Hi,

I found 2 functions that can't be licensed as GPLv2+ (only GPLv2) they are
very insignificant and one of them is never being called, As soon as Sergio
reply to me about what I am missing in getting 1/13 and 2/13 patch's to
work, I will send 2/13 again acked by me with full GPLv2+ license code
(without the GPLv2 code) from Veertu and then Google have to approve as
well.

Thanks.


>
> Google has already contributed the HAXN accelerator, so I am moderately
> optimistic that they can help with HVF too.
>
> BTW, another thing that need to be integrated in order to make this stuff
> useful is the vmnet patch's, it is apple NAT for vms that allow guests to
> have networking...
>
>
> People can always use slirp (or tap with some more effort), so these
> patches are already a minimum viable feature and pretty close to being
> mergeable. But of course any other contribution is welcome!
>
> Paolo
>
>
> (altho that it come with a trick, without certificate it
> will require root permission, while hypverisor framework itself can run
> without root)
>
> What do you guys think?
>
>
> >
> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
> > hvf-all.c file that Daniel pointed out as v2-only is derived from
> kvm-all.c
> > and hax-all.c, and should be under v2-or-later license. The others seem
> to
> > be either original or derived from Bochs, which is LGPL, so they could be
> > LGPL or GPLv2+.
> >
> > Thanks,
> >
> > Paolo
> >
> >
> > There are benefits to having this code upstream.  If they ever want to
> > rebase on qemu.git there will be less work for them.
> >
> > Stefan
> >
> >
> >
>
>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini  wrote:

> Il 01 set 2017 7:59 PM, "Izik Eidus"  ha scritto:
>
> Hi,
>
> Sergio, I was trying to applying patch  1/13 and 2/13 and then I ran:
> ./configure and saw: 'HVF support   yes'
> after that 'make' was happy
> and:
>
> ./x86_64-softmmu/qemu-system-x86_64 --help | grep accel
>
> \property accel=accel1[:accel2[:...]] selects accelerator
>
> supported accelerators are kvm, xen, hax, hvf or tcg
> (default: tcg)
>
> kernel_irqchip=on|off|split controls accelerated irqchip
> support (default=off)
>
>
> however:
>
> ./x86_64-softmmu/qemu-system-x86_64 -cdrom
> /Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine
> q35,accel=hvf
>
> qemu-system-x86_64: -machine accel=hvf: No accelerator found
>
>
> What am I doing wrong?
>
>
> Try applying patch 3 too. Most of the early patches will end up squashed.
>

Yea that did the magic, now I have compilation errors but from here I will
take it, and just fix the compilation step for each patch and resend.


>
> Paolo
>
>
> Thanks.
>
>
>
>
> On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real <
> sergio.g.delr...@gmail.com> wrote:
>
> > Hello,
> > Mr. Frank Yang was the guy at Google that introduced the HVF port to
> > Google's Android Emulator QEMU branch.
> > Frank, in this thread we are discussing the licensing issue with the HVF
> > files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu
> > developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs
> > and other GPLv2+ or LGPL software. Because the code at Google was itself
> > derived from Veertu, I'd imagine the same licensing terms would apply in
> > your case. Any light you can throw over this issue would be much
> > appreciated.
> >
> > Thank you.
> >
> > On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini 
> > wrote:
> >
> >> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
> >>
> >> > Izik, Vincent (assuming you are the right person to contact at
> Google),
> >> > can you reply to Daniel and Stefan?
> >> >
> >>
> >> Hi,
> >>
> >> What I suggest is that we will send our patch' again as gpl2+ and clean
> >> the
> >> entire stuff to make sure they are falling into the right copyright
> >> category as required by QEMU.
> >>
> >>
> >> That's not necessary. Just you and Vincent replying to this thread with
> a
> >> "Signed-off-by" line would be enough for Sergio to use the right
> license in
> >> his v3 submission. Sergio already made some non-trivial changes that are
> >> needed for inclusion in QEMU from a supportability (e.g. dirty page
> >> tracking for graphics) or maintainability perspective (e.g. -cpu
> support),
> >> so the simplest thing to do is to retrofit the right license to his
> >> submission. You can do so if you can confirm that the code you used only
> >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
> >> was written by Veertu).
> >>
> >> Google has already contributed the HAXN accelerator, so I am moderately
> >> optimistic that they can help with HVF too.
> >>
> >> BTW, another thing that need to be integrated in order to make this
> stuff
> >> useful is the vmnet patch's, it is apple NAT for vms that allow guests
> to
> >> have networking...
> >>
> >>
> >> People can always use slirp (or tap with some more effort), so these
> >> patches are already a minimum viable feature and pretty close to being
> >> mergeable. But of course any other contribution is welcome!
> >>
> >> Paolo
> >>
> >>
> >> (altho that it come with a trick, without certificate it
> >> will require root permission, while hypverisor framework itself can run
> >> without root)
> >>
> >> What do you guys think?
> >>
> >>
> >> >
> >> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
> >> > hvf-all.c file that Daniel pointed out as v2-only is derived from
> >> kvm-all.c
> >> > and hax-all.c, and should be under v2-or-later license. The others
> seem
> >> to
> >> > be either original or derived from Bochs, which is LGPL, so they could
> >> be
> >> > LGPL or GPLv2+.
> >> >
> >> > Thanks,
> >> >
> >> > Paolo
> >> >
> >> >
> >> > There are benefits to having this code upstream.  If they ever want to
> >> > rebase on qemu.git there will be less work for them.
> >> >
> >> > Stefan
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
>
>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

Hi,

Paolo, my biggest challenge right now is:
hvf-all.c
it include currently the following copyright:

// Copyright 2008 IBM Corporation

//   2008 Red Hat, Inc.

// Copyright 2011 Intel Corporation

// Copyright 2016 Veertu, Inc.
// Copyright 2017 The Android Open Source Project

and it is GPLv2, However we want to integrate this stuff to QEMU in the
required license (GPLv2+), I have a suggestion that maybe the safest way
for us to achieve GPLv2+  would be that we will send you the current
hypervisor framework implementation of Anka that is derived from
xhyve/bhyve + our own changes to make it run windows / linux / macOS, in
such case all copyright go back to BSD2 and we can license it as GPL2v+ or
whatever work for QEMU.
If you want to go in such case what we will do would be the following:
take kvm user space implemantion of qemu that is GPLv2+, integrate to it
the hypervisor framework from Anka (in kvm user space style) - this will
put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the
rest of Sergio changes to this stuff.

I know this is less than ideal as it requires some changes to the current
patch set, however it will make it 100% safe to be GPL2v+, what you guys
think?, we can get this stuff done before the end of this week...

Thanks.


On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus  wrote:

>
>
> On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini 
> wrote:
>
>> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
>>
>> > Izik, Vincent (assuming you are the right person to contact at Google),
>> > can you reply to Daniel and Stefan?
>> >
>>
>> Hi,
>>
>> What I suggest is that we will send our patch' again as gpl2+ and clean
>> the
>> entire stuff to make sure they are falling into the right copyright
>> category as required by QEMU.
>>
>>
>> That's not necessary. Just you and Vincent replying to this thread with a
>> "Signed-off-by" line would be enough for Sergio to use the right license in
>> his v3 submission. Sergio already made some non-trivial changes that are
>> needed for inclusion in QEMU from a supportability (e.g. dirty page
>> tracking for graphics) or maintainability perspective (e.g. -cpu support),
>> so the simplest thing to do is to retrofit the right license to his
>> submission. You can do so if you can confirm that the code you used only
>> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
>> was written by Veertu).
>>
>
> Hi,
>
> Sure fine with us, let me go over all the code and see that all copyright
> that are needed are there, and then you can relicense all our code to
> GPLv2+, I think I saw a a file that was missing Bochs copyright in it, so I
> want to make sure that I fix this before and that all others are fine.
>
> Thanks.
>
>
>>
>> Google has already contributed the HAXN accelerator, so I am moderately
>> optimistic that they can help with HVF too.
>>
>> BTW, another thing that need to be integrated in order to make this stuff
>> useful is the vmnet patch's, it is apple NAT for vms that allow guests to
>> have networking...
>>
>>
>> People can always use slirp (or tap with some more effort), so these
>> patches are already a minimum viable feature and pretty close to being
>> mergeable. But of course any other contribution is welcome!
>>
>> Paolo
>>
>>
>> (altho that it come with a trick, without certificate it
>> will require root permission, while hypverisor framework itself can run
>> without root)
>>
>> What do you guys think?
>>
>>
>> >
>> > Sergio worked on completing the QEMU port to Hypervisor.framework. The
>> > hvf-all.c file that Daniel pointed out as v2-only is derived from
>> kvm-all.c
>> > and hax-all.c, and should be under v2-or-later license. The others seem
>> to
>> > be either original or derived from Bochs, which is LGPL, so they could
>> be
>> > LGPL or GPLv2+.
>> >
>> > Thanks,
>> >
>> > Paolo
>> >
>> >
>> > There are benefits to having this code upstream.  If they ever want to
>> > rebase on qemu.git there will be less work for them.
>>
>>
OK,


> >
>> > Stefan
>> >
>> >
>> >
>>
>>
>>
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Sun, Sep 3, 2017 at 7:35 PM, Paolo Bonzini  wrote:

>
>
> Il 03 set 2017 6:17 PM, "Izik Eidus"  ha scritto:
>
> Hi,
>
> Paolo, my biggest challenge right now is:
> hvf-all.c
> it include currently the following copyright:
>
> // Copyright 2008 IBM Corporation
>
> //   2008 Red Hat, Inc.
>
> // Copyright 2011 Intel Corporation
>
> // Copyright 2016 Veertu, Inc.
> // Copyright 2017 The Android Open Source Project
>
> and it is GPLv2, However we want to integrate this stuff to QEMU in the
> required license (GPLv2+), I have a suggestion that maybe the safest way
> for us to achieve GPLv2+  would be that we will send you the current
> hypervisor framework implementation of Anka that is derived from
> xhyve/bhyve + our own changes to make it run windows / linux / macOS,
>
>
> What code is derived from v2-only sources? IIRC the task switch code is
> derived from KVM, is there anything else?
>


Yes this is exactly the code that I found as well, however considering the
fact that I didn't even know it was there requires me to go and validate
that other stuff are safe for GPL2v+.


>
> If you can identify the functions that cannot be v2-or-later that's
> already okay. There is a lot more refactoring to do in the HVF code to
> remove duplication with other parts of the code, and if it's just a couple
> isolated cases we can maybe try to prioritize them. For example it's part
> of the plan to replace the task switch code with the version in
> seg_helper.c. Worst case, QEMU has done clean room reverse engineering a
> couple times in the past to fix licensing issues.
>
> If you think your plan works better and you can devote a week to it, we
> can also try it. But having a clear answer on what code is from v2-only
> sources may help judging on the better approach. I an worried that some of
> the later patches could be tricky to redo/backport. What are the advantages
> of the newer implementation? Does it reuse more KVM userspace bits?
>


The newer implementation is what we are using in Anka to virtluze macOS
(but it is handling windows/linux/*), in my perspective it is more mature
and handle many more corner case, it is currently not plugged into QEMU,
and all the work that need to happen is: plug it like the KVM user space
bits with the ideas of Sergio, and the recommendations of QEMU for this
patch's.

One big advantage is that we will be more than happy to back port fix's as
they come from Anka to QEMU hvf.

>
> Paolo
>
> in
> such case all copyright go back to BSD2 and we can license it as GPL2v+ or
> whatever work for QEMU.
> If you want to go in such case what we will do would be the following:
> take kvm user space implemantion of qemu that is GPLv2+, integrate to it
> the hypervisor framework from Anka (in kvm user space style) - this will
> put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the
> rest of Sergio changes to this stuff.
>
> I know this is less than ideal as it requires some changes to the current
> patch set, however it will make it 100% safe to be GPL2v+, what you guys
> think?, we can get this stuff done before the end of this week...
>
> Thanks.
>
>
> On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus  wrote:
>
> >
> >
> > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini 
> > wrote:
> >
> >> Il 31 ago 2017 3:54 PM, "Izik Eidus"  ha scritto:
> >>
> >> > Izik, Vincent (assuming you are the right person to contact at
> Google),
> >> > can you reply to Daniel and Stefan?
> >> >
> >>
> >> Hi,
> >>
> >> What I suggest is that we will send our patch' again as gpl2+ and clean
> >> the
> >> entire stuff to make sure they are falling into the right copyright
> >> category as required by QEMU.
> >>
> >>
> >> That's not necessary. Just you and Vincent replying to this thread with
> a
> >> "Signed-off-by" line would be enough for Sergio to use the right
> license in
> >> his v3 submission. Sergio already made some non-trivial changes that are
> >> needed for inclusion in QEMU from a supportability (e.g. dirty page
> >> tracking for graphics) or maintainability perspective (e.g. -cpu
> support),
> >> so the simplest thing to do is to retrofit the right license to his
> >> submission. You can do so if you can confirm that the code you used only
> >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest
> >> was written by Veertu).
> >>
> >
> > Hi,
> >
> > Sure fine with us, let me go over all the code and see that all c

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Sun, Sep 3, 2017 at 8:13 PM, Paolo Bonzini > wrote:

>
>
> Il 03 set 2017 6:54 PM, "Izik Eidus"  > ha scritto:
>
> > What code is derived from v2-only sources? IIRC the task switch code is
> > derived from KVM, is there anything else?
>
> Yes this is exactly the code that I found as well, however considering the
> fact that I didn't even know it was there requires me to go and validate
> that other stuff are safe for GPL2v+.
>
>
> FWIW I didn't find anything else coming from KVM.
>
> The newer implementation is what we are using in Anka to virtluze macOS
> (but it is handling windows/linux/*), in my perspective it is more mature
> and handle many more corner case, it is currently not plugged into QEMU,
> and all the work that need to happen is: plug it like the KVM user space
> bits with the ideas of Sergio, and the recommendations of QEMU for this
> patch's.
>
> One big advantage is that we will be more than happy to back port fix's as
> they come from Anka to QEMU hvf.
>
>
> It's difficult for me to judge without seeing your code (couldn't find it
> from a quick look on GitHub).
>

Yea, we will have to open source that code in such case.


> I expect any code that we merged from Anka would diverge as QEMU's HVF
> integration matures (e.g. adding support for live migration, unifying the
> page walkers, etc.).
>

I think you are right.


> On the other hand if you open-source more hypervisor.framework client code
> or new instruction emulator code we can certainly merge it back into QEMU
> when it makes sense!
>

For now i want to get hypervisor framework merged into QEMU in required
license. I did offer to open source everything needed from anka to the make
QEMU being able to run any os using hypervisor.framework.


>
> I think it's safe to use v2+ for this code once Google agrees. The task
> switch code, which is going to go away soon anyway and is isolated from the
> rest, can be moved to a separate file for the time being.
>


OK, such case would be simpler to me to go if this what you prefer, in such
case, i will send the 1|2|3 patches splited from task switch and
everything  beside task switch as gpl2v+.

Whatever you guys decide...

Thanks.


>
> Paolo
>
>
> >
> > Paolo
> >
> > in
> > such case all copyright go back to BSD2 and we can license it as GPL2v+
> or
> > whatever work for QEMU.
> > If you want to go in such case what we will do would be the following:
> > take kvm user space implemantion of qemu that is GPLv2+, integrate to it
> > the hypervisor framework from Anka (in kvm user space style) - this will
> > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the
> > rest of Sergio changes to this stuff.
> >
> > I know this is less than ideal as it requires some changes to the current
> > patch set, however it will make it 100% safe to be GPL2v+, what you guys
> > think?, we can get this stuff done before the end of this week...
> >
> > Thanks.
> >
> >
> > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus  > wrote:
> >
> > >
> > >
> > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini  >
> > > wrote:
> > >
> > >> Il 31 ago 2017 3:54 PM, "Izik Eidus"  > ha scritto:
> > >>
> > >> > Izik, Vincent (assuming you are the right person to contact at
> > Google),
> > >> > can you reply to Daniel and Stefan?
> > >> >
> > >>
> > >> Hi,
> > >>
> > >> What I suggest is that we will send our patch' again as gpl2+ and
> clean
> > >> the
> > >> entire stuff to make sure they are falling into the right copyright
> > >> category as required by QEMU.
> > >>
> > >>
> > >> That's not necessary. Just you and Vincent replying to this thread
> with
> > a
> > >> "Signed-off-by" line would be enough for Sergio to use the right
> > license in
> > >> his v3 submission. Sergio already made some non-trivial changes that
> are
> > >> needed for inclusion in QEMU from a supportability (e.g. dirty page
> > >> tracking for graphics) or maintainability perspective (e.g. -cpu
> > support),
> > >> so the simplest thing to do is to retrofit the right license to his
> > >> submission. You can do so if you can confirm that the code you used
> only
> > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the
> rest
> > >> was written by Veertu).
> > >>
> > >
>

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Mon, Sep 4, 2017 at 9:47 AM, Paolo Bonzini  wrote:
>
>
>
> Il 03 set 2017 8:49 PM, "Izik Eidus"  ha scritto:
>
> For now i want to get hypervisor framework merged into QEMU in required 
> license. I did offer to open source everything needed from anka to the make 
> QEMU being able to run any os using hypervisor.framework.
>
>
> Having such code as open source will certainly help anyone who is going to 
> work more on QEMU HVF so it would be great.
>
> Sergio, in the meanwhile can you post v3 with an extra patch after 2/13 that:
>
> - moves the task switch code to a new file with v2-only header
>
> - changes all v2-only or v2-v3 headers in HVF files to v2-or-later


Hi,

Paolo, I was reviewing more and more our code and found another issue
regarding licensing of gpl2v+:
the file x86_descr.c include:
#define VMX_SEGMENT_FIELD(seg) that is coming from KVM that is gpl2 code.
unfortunately we had a developer that introduced both this code and
the task_switch, I am reviewing more and more this now to find if we
have any other gpl2v only in our code.

Maybe it does worth to reconsider us donating hypervisor.framework
implemantion that will be clean from such gpl2v only issue? I know it
will slow little bit the integration but we are willing to put all the
effort that is needed, including syncing all Sergio later on patch's
and whatever is needed more.

Thanks.

>
>
> Then Izik and Frank can reply with their Signed-off-by to that extra patch.
>
> Thanks,
>
> Paolo
>
>
>
> >
> > I think it's safe to use v2+ for this code once Google agrees. The task
> > switch code, which is going to go away soon anyway and is isolated from the
> > rest, can be moved to a separate file for the time being.
> >
>
>
> OK, such case would be simpler to me to go if this what you prefer, in such
> case, i will send the 1|2|3 patches splited from task switch and
> everything  beside task switch as gpl2v+.
>
> Whatever you guys decide...
>
> Thanks.
>
>
> >
> > Paolo
> >
> >
> > >
> > > Paolo
> > >
> > > in
> > > such case all copyright go back to BSD2 and we can license it as GPL2v+
> > or
> > > whatever work for QEMU.
> > > If you want to go in such case what we will do would be the following:
> > > take kvm user space implemantion of qemu that is GPLv2+, integrate to it
> > > the hypervisor framework from Anka (in kvm user space style) - this will
> > > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the
> > > rest of Sergio changes to this stuff.
> > >
> > > I know this is less than ideal as it requires some changes to the current
> > > patch set, however it will make it 100% safe to be GPL2v+, what you guys
> > > think?, we can get this stuff done before the end of this week...
> > >
> > > Thanks.
> > >
> > >
> > > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus  > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini  > >
> > > > wrote:
> > > >
> > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus"  > > ha scritto:
>
> > > >>
> > > >> > Izik, Vincent (assuming you are the right person to contact at
> > > Google),
> > > >> > can you reply to Daniel and Stefan?
> > > >> >
> > > >>
> > > >> Hi,
> > > >>
> > > >> What I suggest is that we will send our patch' again as gpl2+ and
> > clean
> > > >> the
> > > >> entire stuff to make sure they are falling into the right copyright
> > > >> category as required by QEMU.
> > > >>
> > > >>
> > > >> That's not necessary. Just you and Vincent replying to this thread
> > with
> > > a
> > > >> "Signed-off-by" line would be enough for Sergio to use the right
> > > license in
> > > >> his v3 submission. Sergio already made some non-trivial changes that
> > are
> > > >> needed for inclusion in QEMU from a supportability (e.g. dirty page
> > > >> tracking for graphics) or maintainability perspective (e.g. -cpu
> > > support),
> > > >> so the simplest thing to do is to retrofit the right license to his
> > > >> submission. You can do so if you can confirm that the code you used
> > only
> > > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the
> > res

Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository

[Izik Eidus]

On Wed, Sep 6, 2017 at 5:28 PM, Paolo Bonzini  wrote:
> Il 06 set 2017 3:29 PM, "Izik Eidus"  ha scritto:
>
> Paolo, I was reviewing more and more our code and found another issue
> regarding licensing of gpl2v+: the file x86_descr.c include:
> #define VMX_SEGMENT_FIELD(seg) that is coming from KVM that is gpl2 code.
>
>
> I don't think that's copyrightable.
>
> unfortunately we had a developer that introduced both this code and the
> task_switch, I am reviewing more and more this now to find if we have any
> other gpl2v only in our code.
>
> Maybe it does worth to reconsider us donating hypervisor.framework
> implemantion that will be clean from such gpl2v only issue? I know it will
> slow little bit the integration but we are willing to put all the
> effort that is needed, including syncing all Sergio later on patch's
> and whatever is needed more.
>
>
> I think we need to be pragmatic and picking the best of the two
> implementations (plus KVM itself) is the best option. There is considerable
> overlap between QEMU and KVM developers, and anyone could say in bad faith
> that people are reusing their KVM knowledge when touching HVF code in QEMU.
>
> What matters more in my non-lawyerly opinion is that we handle HVF code as a
> part of QEMU rather than something bolted on the side. This alone will make
> a lot of functions that _could_ come from external sources go away, as the
> processor emulation stuff from TCG can easily get reused.

OK, fine with me.

Thanks.

>
> Patio
>
> Paolo
>
>
> Thanks.
>
>>
>>
>> Then Izik and Frank can reply with their Signed-off-by to that extra
>> patch.
>>
>> Thanks,
>>
>> Paolo
>>
>>
>>
>> >
>> > I think it's safe to use v2+ for this code once Google agrees. The task
>> > switch code, which is going to go away soon anyway and is isolated from
>> > the
>> > rest, can be moved to a separate file for the time being.
>> >
>>
>>
>> OK, such case would be simpler to me to go if this what you prefer, in
>> such
>> case, i will send the 1|2|3 patches splited from task switch and
>> everything  beside task switch as gpl2v+.
>>
>> Whatever you guys decide...
>>
>> Thanks.
>>
>>
>> >
>> > Paolo
>> >
>> >
>> > >
>> > > Paolo
>> > >
>> > > in
>> > > such case all copyright go back to BSD2 and we can license it as
>> > > GPL2v+
>> > or
>> > > whatever work for QEMU.
>> > > If you want to go in such case what we will do would be the following:
>> > > take kvm user space implemantion of qemu that is GPLv2+, integrate to
>> > > it
>> > > the hypervisor framework from Anka (in kvm user space style) - this
>> > > will
>> > > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port
>> > > the
>> > > rest of Sergio changes to this stuff.
>> > >
>> > > I know this is less than ideal as it requires some changes to the
>> > > current
>> > > patch set, however it will make it 100% safe to be GPL2v+, what you
>> > > guys
>> > > think?, we can get this stuff done before the end of this week...
>> > >
>> > > Thanks.
>> > >
>> > >
>> > > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus > > > wrote:
>> > >
>> > > >
>> > > >
>> > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > > >
>> > > > wrote:
>> > > >
>> > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" > > > ha scritto:
>>
>> > > >>
>> > > >> > Izik, Vincent (assuming you are the right person to contact at
>> > > Google),
>> > > >> > can you reply to Daniel and Stefan?
>> > > >> >
>> > > >>
>> > > >> Hi,
>> > > >>
>> > > >> What I suggest is that we will send our patch' again as gpl2+ and
>> > clean
>> > > >> the
>> > > >> entire stuff to make sure they are falling into the right copyright
>> > > >> category as required by QEMU.
>> > > >>
>> > > >>
>> > > >> That's not necessary. Just you and Vincent replying to this thread
>> > with
>> > > a
>> > > >> "Signed-off-by" line would b