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