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 <pbonz...@redhat.com> 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 <i...@veertu.com>
>
> 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

[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

[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 <i...@veertu.com>
---
 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 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 <i...@veertu.com>
---
 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)

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 <pbonz...@redhat.com> wrote:
> Il 06 set 2017 3:29 PM, "Izik Eidus" <i...@veertu.com> 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 <i...@veertu.com
>> > <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> wrote:
>> > >
>> > > >
>> > > >
>> > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <pbonz...@redhat.com
>> > <javascript:_e(%7B%7D,'cvml','pbonz...@redhat.com');>>
>> > > > wrote:
>> > > >
>> > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com
>> > <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> 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 requir

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 <pbonz...@redhat.com> wrote:
>
>
>
> Il 03 set 2017 8:49 PM, "Izik Eidus" <i...@veertu.com> 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 <i...@veertu.com
> > <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> wrote:
> > >
> > > >
> > > >
> > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <pbonz...@redhat.com
> > <javascript:_e(%7B%7D,'cvml','pbonz...@redhat.com');>>
> > > > wrote:
> > > >
> > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com
> > <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> 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 th

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 <pbonz...@redhat.com
<javascript:_e(%7B%7D,'cvml','pbonz...@redhat.com');>> wrote:

>
>
> Il 03 set 2017 6:54 PM, "Izik Eidus" <i...@veertu.com
> <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> 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 <i...@veertu.com
> <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> wrote:
> >
> > >
> > >
> > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <pbonz...@redhat.com
> <javascript:_e(%7B%7D,'cvml','pbonz...@redhat.com');>>
> > > wrote:
> > >
> > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com
> <javascript:_e(%7B%7D,'cvml','i...@veertu.com');>> 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

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 <pbonz...@redhat.com> wrote:

>
>
> Il 03 set 2017 6:17 PM, "Izik Eidus" <i...@veertu.com> 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 <i...@veertu.com> wrote:
>
> >
> >
> > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <pbonz...@redhat.com>
> > wrote:
> >
> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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,
> &

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 <i...@veertu.com> wrote:

>
>
> On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <pbonz...@redhat.com>
> wrote:
>
>> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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 9:23 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:

> Il 01 set 2017 7:59 PM, "Izik Eidus" <i...@veertu.com> 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 <pbonz...@redhat.com>
> > wrote:
> >
> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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 <pbonz...@redhat.com> wrote:

> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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]

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 <pbonz...@redhat.com>
> wrote:
>
>> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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 1:02 AM, Frank Yang <l...@google.com> 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 <pbonz...@redhat.com>
>> wrote:
>>
>>> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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]

On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini <pbonz...@redhat.com> wrote:

> Il 31 ago 2017 3:54 PM, "Izik Eidus" <i...@veertu.com> 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 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 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 Fleytmandmi...@daynix.com
Signed-off-by: Yan Vugenfirery...@daynix.com
---
  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 y...@ravellosystems.com wrote:
 Adding Izik from Ravello.

 Best regards,
 Yan.

 On Tue, Feb 28, 2012 at 6:43 PM, malc av1...@comtv.ru wrote:
 On Tue, 28 Feb 2012, Yan Vugenfirer wrote:

 From: Dmitry Fleytman dmi...@daynix.com

 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 dmi...@daynix.com
 + * Yan Vugenfirer y...@daynix.com
 + *
 + * 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 Vugenfirery...@ravellosystems.com  wrote:

Adding Izik from Ravello.

Best regards,
Yan.

On Tue, Feb 28, 2012 at 6:43 PM, malcav1...@comtv.ru  wrote:

On Tue, 28 Feb 2012, Yan Vugenfirer wrote:


From: Dmitry Fleytmandmi...@daynix.com

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 Fleytmandmi...@daynix.com
+ * Yan Vugenfirery...@daynix.com
+ *
+ * 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 berra...@redhat.com 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 y...@ravellosystems.com 
 wrote:
  Adding Izik from Ravello.
 
  Best regards,
  Yan.
 
  On Tue, Feb 28, 2012 at 6:43 PM, malc av1...@comtv.ru wrote:
  On Tue, 28 Feb 2012, Yan Vugenfirer wrote:
 
  From: Dmitry Fleytman dmi...@daynix.com
 
  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 dmi...@daynix.com
  + * Yan Vugenfirer y...@daynix.com
  + *
  + * 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] [PATCH] fix migration with large mem

[Izik Eidus]

On Mon, 10 May 2010 15:24:20 -0500
Anthony Liguori anth...@codemonkey.ws wrote:

 On 04/13/2010 04:33 AM, Izik Eidus wrote:
   From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00
  2001 From: Izik Eidusiei...@redhat.com
  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 Eidusiei...@redhat.com
  ---
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;
 
 

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

[Izik Eidus]

On Tue, 13 Apr 2010 12:33:18 +0300
Izik Eidus iei...@redhat.com wrote:

 From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
 From: Izik Eidus iei...@redhat.com
 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 iei...@redhat.com
 ---
  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;

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

[Izik Eidus]

From f881b371e08760a67bf1f5b992a586c3de600f7a Mon Sep 17 00:00:00 2001
From: Izik Eidus iei...@redhat.com
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 iei...@redhat.com
---
 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] adding helper pci functions

[Izik Eidus]

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

From: Izik Eidusiei...@redhat.com
   


The true auther of this patch is Yaniv Kamay.

Thanks.


Signed-off-by: Izik Eidusiei...@redhat.com
Signed-off-by: Gerd Hoffmannkra...@redhat.com
---
   

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

[Izik Eidus]

On Fri, 11 Dec 2009 17:07:13 -0200
Glauber Costa glom...@gmail.com 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.

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

[Izik Eidus]

On Wed, 30 Dec 2009 14:05:10 +0200
Gleb Natapov g...@redhat.com wrote:

 On Wed, Dec 30, 2009 at 12:01:28PM +, Blue Swirl wrote:
  On Wed, Dec 30, 2009 at 11:50 AM, Gleb Natapov g...@redhat.com 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] Re: Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 18:18:01 -0600
Anthony Liguori anth...@codemonkey.ws 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 iei...@redhat.com wrote:

 On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
 malc av1...@comtv.ru wrote:
 
  On Fri, 11 Dec 2009, Izik Eidus wrote:
  
   On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
   malc av1...@comtv.ru wrote:
   
On Fri, 11 Dec 2009, Izik Eidus wrote:

 On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
 malc av1...@comtv.ru wrote:
 
  On Fri, 11 Dec 2009, Izik Eidus wrote:
  
   On Fri, 11 Dec 2009 09:57:48 -0600
   Anthony Liguori anth...@codemonkey.ws 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] X support for QXL and SPICE

[Izik Eidus]

On Sat, 12 Dec 2009 09:13:51 -0600
Anthony Liguori anth...@codemonkey.ws wrote:

 Izik Eidus wrote:
  On Fri, 11 Dec 2009 21:31:34 -0600
  Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 ag...@suse.de 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 anth...@codemonkey.ws wrote:

 Izik Eidus wrote:
  On Sat, 12 Dec 2009 09:25:00 -0600
  Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 anth...@codemonkey.ws wrote:

 Izik Eidus wrote:
  On Sat, 12 Dec 2009 11:40:21 -0600
  Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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] Spice project is now open

[Izik Eidus]

On Fri, 11 Dec 2009 09:57:48 -0600
Anthony Liguori anth...@codemonkey.ws 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 18:57:17 +
Ben Taylor bentaylor.sol...@gmail.com 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 av1...@comtv.ru wrote:

 On Fri, 11 Dec 2009, Izik Eidus wrote:
 
  On Fri, 11 Dec 2009 09:57:48 -0600
  Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 glom...@gmail.com 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 glom...@gmail.com 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 av1...@comtv.ru wrote:

 On Fri, 11 Dec 2009, Izik Eidus wrote:
 
  On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
  malc av1...@comtv.ru wrote:
  
   On Fri, 11 Dec 2009, Izik Eidus wrote:
   
On Fri, 11 Dec 2009 09:57:48 -0600
Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 anth...@codemonkey.ws wrote:

 Izik Eidus wrote:
  On Fri, 11 Dec 2009 13:30:22 -0600
  Anthony Liguori anth...@codemonkey.ws 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 Rectanlge on top of it, wont it hide it?, doesnt we want
just to send the newest Rectangle?

 
  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?

 
 A lot of the things in Spice (from a quick glance at the spec) are
 too high level for just an X driver.  For instance, there are glyph
 based operations presumably for text rendering.  There are also brush 
 primitives.  While X has some support for these things, it's so old
 and broken that in modern applications, most toolkits just render to
 a local buffer, and then do a draw the image to the window.  That
 means

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

[Izik Eidus]

On Fri, 11 Dec 2009 22:53:25 +0300 (MSK)
malc av1...@comtv.ru wrote:

 On Fri, 11 Dec 2009, Izik Eidus wrote:
 
  On Fri, 11 Dec 2009 22:24:38 +0300 (MSK)
  malc av1...@comtv.ru wrote:
  
   On Fri, 11 Dec 2009, Izik Eidus wrote:
   
On Fri, 11 Dec 2009 22:03:33 +0300 (MSK)
malc av1...@comtv.ru wrote:

 On Fri, 11 Dec 2009, Izik Eidus wrote:
 
  On Fri, 11 Dec 2009 09:57:48 -0600
  Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 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


 
 I can see where this is a win with Windows because you can hook into 
 GDI, but I'm not sure that this could ever do better than say, NX 
 without something really clever or really deep integration

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

[Izik Eidus]

On Fri, 11 Dec 2009 14:48:53 -0600
Anthony Liguori anth...@codemonkey.ws wrote:

 Izik Eidus wrote:
  On Fri, 11 Dec 2009 13:51:53 -0600
  Anthony Liguori anth...@codemonkey.ws 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 anth...@codemonkey.ws 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 ag...@suse.de wrote:

 
 On 11.12.2009, at 22:13, Izik Eidus wrote:
 
  On Fri, 11 Dec 2009 14:46:55 -0600
  Anthony Liguori anth...@codemonkey.ws 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 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

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

[Izik Eidus]

On 12 Dec 2009 00:58:13 +0100
Soeren Sandmann sandm...@daimi.au.dk 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 ag...@suse.de wrote:

 
 On 11.12.2009, at 23:46, Izik Eidus wrote:
 
  On Fri, 11 Dec 2009 23:08:01 +0100
  Alexander Graf ag...@suse.de wrote:
  
  
  On 11.12.2009, at 22:13, Izik Eidus wrote:
  
  On Fri, 11 Dec 2009 14:46:55 -0600
  Anthony Liguori anth...@codemonkey.ws 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
  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...)
 
 Oh I'm not trying to talk you or anyone into anything. I was merely
 trying to stress that SPICE isn't really its own protocol but
 extensions to the RDP protocol (IIUC). You could do similar
 extensions to VNC if you liked. Thus I'd love to see a generic
 mid-layer and implementations of RDP and VNC on top of that actually.

One of the decisions we have made in SPICE, was to provide a full
functional remote system, not realying on other system,
We already have far more features than VNC have, so what is the logical
in making spice extention of VNC? it more logical to make VNC extention
of SPICE...

SPICE have networking tunneling, local/server mouse, (in progress) usb
remote, audio / recording channel , private channels for each
compoment, Even if VNC would have part of this stuff, It seems like
they are trying to achive things in diffrent way than SPICE does

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

[Izik Eidus]

On Sat, 12 Dec 2009 01:05:36 +0100
Alexander Graf ag...@suse.de 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 ag...@suse.de wrote:

 
 On 12.12.2009, at 01:14, Izik Eidus wrote:
 
  On Sat, 12 Dec 2009 00:54:47 +0100
  Alexander Graf ag...@suse.de wrote:
  
  
  On 11.12.2009, at 23:46, Izik Eidus wrote:
  
  On Fri, 11 Dec 2009 23:08:01 +0100
  Alexander Graf ag...@suse.de wrote:
  
  
  On 11.12.2009, at 22:13, Izik Eidus wrote:
  
  On Fri, 11 Dec 2009 14:46:55 -0600
  Anthony Liguori anth...@codemonkey.ws 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.
  
  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...)
  
  Oh I'm not trying to talk you or anyone into anything. I was merely
  trying to stress that SPICE isn't really its own protocol but
  extensions to the RDP protocol (IIUC). You could do similar
  extensions to VNC if you liked. Thus I'd love to see a generic
  mid-layer and implementations of RDP and VNC on top of that
  actually.
  
  One of the decisions we have made in SPICE, was to provide a full

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

[Izik Eidus]

On Sat, 12 Dec 2009 02:08:05 +0100
Alexander Graf ag...@suse.de 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 anth...@codemonkey.ws 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

[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] 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 5:
 /* 256KB BIOS area at the end of 4 GB

[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[static_slots_index],
+

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)

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] 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 net.h
 #include console.h
 #include sysemu.h
@@ -871,6 +872,64 @@ static void rtc_stop_timer(struct qemu_alarm_timer *t);
 
 #endif /* _WIN32 */
 
+static void set_static_devfn(const char *optarg)
+{
+int i

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: ;
 }
+
 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

[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
 case 4:

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] 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