Re: [Qemu-devel] [PATCH for-2.11] tests: Fix broken ivshmem-server-msi/-irq tests
On 29/08/2017 20:13, Thomas Huth wrote:
> Broken with commit b4ba67d9a7025 ("libqos: Change PCI accessors to take
> opaque BAR handle") a while ago, but nobody noticed since the tests are
> only run in SPEED=slow mode: The msix_pba_bar is not correctly initialized
you mean "SPEED=quick"?
> anymore if bir_pba has the same value as bir_table. With this fix,
> "make check SPEED=slow" should work fine again.
>
> Fixes: b4ba67d9a702507793c2724e56f98e9b0f7be02b
> Signed-off-by: Thomas Huth
> ---
> tests/libqos/pci.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tests/libqos/pci.c b/tests/libqos/pci.c
> index 2dcdead..28d576c 100644
> --- a/tests/libqos/pci.c
> +++ b/tests/libqos/pci.c
> @@ -120,6 +120,8 @@ void qpci_msix_enable(QPCIDevice *dev)
> bir_pba = table & PCI_MSIX_FLAGS_BIRMASK;
> if (bir_pba != bir_table) {
> dev->msix_pba_bar = qpci_iomap(dev, bir_pba, NULL);
> +} else {
> +dev->msix_pba_bar = dev->msix_table_bar;
> }
> dev->msix_pba_off = table & ~PCI_MSIX_FLAGS_BIRMASK;
>
> @@ -138,8 +140,11 @@ void qpci_msix_disable(QPCIDevice *dev)
> qpci_config_writew(dev, addr + PCI_MSIX_FLAGS,
> val &
> ~PCI_MSIX_FLAGS_ENABLE);
>
> +if (dev->msix_pba_bar.addr != dev->msix_table_bar.addr) {
> +qpci_iounmap(dev, dev->msix_pba_bar);
> +}
> qpci_iounmap(dev, dev->msix_table_bar);
> -qpci_iounmap(dev, dev->msix_pba_bar);
> +
> dev->msix_enabled = 0;
> dev->msix_table_off = 0;
> dev->msix_pba_off = 0;
>
Reviewed-by: Laurent Vivier
[Qemu-devel] [Bug 1714750] Re: 2.10.0 cannot be installed on case-insensitive file system
The offending commit is https://github.com/u-boot/u-boot/commit/61304dbec36dc445bbe7d2c19b4da0695861e0a8 so it should be possible to downgrade u-boot until it gets fixed upstream, no? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1714750 Title: 2.10.0 cannot be installed on case-insensitive file system Status in QEMU: New Bug description: The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be unpacked on a case-insensitive file system because it has a file qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on most macOS systems since by default the file system is case insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This is a regression from 2.9.0, which didn't have this problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1714750/+subscriptions
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Il 03 set 2017 8:49 PM, "Izik Eidus" ha scritto: For now i want to get hypervisor framework merged into QEMU in required license. I did offer to open source everything needed from anka to the make QEMU being able to run any os using hypervisor.framework. Having such code as open source will certainly help anyone who is going to work more on QEMU HVF so it would be great. Sergio, in the meanwhile can you post v3 with an extra patch after 2/13 that: - moves the task switch code to a new file with v2-only header - changes all v2-only or v2-v3 headers in HVF files to v2-or-later Then Izik and Frank can reply with their Signed-off-by to that extra patch. Thanks, Paolo > > I think it's safe to use v2+ for this code once Google agrees. The task > switch code, which is going to go away soon anyway and is isolated from the > rest, can be moved to a separate file for the time being. > OK, such case would be simpler to me to go if this what you prefer, in such case, i will send the 1|2|3 patches splited from task switch and everything beside task switch as gpl2v+. Whatever you guys decide... Thanks. > > Paolo > > > > > > Paolo > > > > in > > such case all copyright go back to BSD2 and we can license it as GPL2v+ > or > > whatever work for QEMU. > > If you want to go in such case what we will do would be the following: > > take kvm user space implemantion of qemu that is GPLv2+, integrate to it > > the hypervisor framework from Anka (in kvm user space style) - this will > > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the > > rest of Sergio changes to this stuff. > > > > I know this is less than ideal as it requires some changes to the current > > patch set, however it will make it 100% safe to be GPL2v+, what you guys > > think?, we can get this stuff done before the end of this week... > > > > Thanks. > > > > > > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus > wrote: > > > > > > > > > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > > > > wrote: > > > > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" > ha scritto: > > >> > > >> > Izik, Vincent (assuming you are the right person to contact at > > Google), > > >> > can you reply to Daniel and Stefan? > > >> > > > >> > > >> Hi, > > >> > > >> What I suggest is that we will send our patch' again as gpl2+ and > clean > > >> the > > >> entire stuff to make sure they are falling into the right copyright > > >> category as required by QEMU. > > >> > > >> > > >> That's not necessary. Just you and Vincent replying to this thread > with > > a > > >> "Signed-off-by" line would be enough for Sergio to use the right > > license in > > >> his v3 submission. Sergio already made some non-trivial changes that > are > > >> needed for inclusion in QEMU from a supportability (e.g. dirty page > > >> tracking for graphics) or maintainability perspective (e.g. -cpu > > support), > > >> so the simplest thing to do is to retrofit the right license to his > > >> submission. You can do so if you can confirm that the code you used > only > > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the > 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, >
Re: [Qemu-devel] [PATCH] pixman: drop submodule
Hi, > > diff --git a/configure b/configure > > index dd73cce62f..73760430b0 100755 > > --- a/configure > > +++ b/configure > > @@ -930,8 +930,6 @@ for opt do > > ;; > > --with-system-pixman) pixman="system" > > Is there any use case for '--with-system-pixman now? There is "--without-pixman" (so you can turn off pixman if you don't want build the system emulation). So IMHO it makes sense to leave the opposite switch in. The name is a bit strange now, but changing it might break build scripts, so I left it as-is. Maybe configure should accept both "--with-pixman" and "--with-system-pixman"? cheers, Gerd
[Qemu-devel] [Bug 1714750] Re: 2.10.0 cannot be installed on case-insensitive file system
That's apparently a problem with U-Boot. Could you please report this issue to the U-Boot project instead (see https://github.com/u-boot/u-boot)? We only include the u-boot sources in the QEMU tarballs, but we do not maintain them in the QEMU project, so we can not fix this issue here for you, sorry. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1714750 Title: 2.10.0 cannot be installed on case-insensitive file system Status in QEMU: New Bug description: The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be unpacked on a case-insensitive file system because it has a file qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on most macOS systems since by default the file system is case insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This is a regression from 2.9.0, which didn't have this problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1714750/+subscriptions
[Qemu-devel] How to use monitor socket in python to connect VM?
Hi all,
I'm using python socket to connect VM's monitor socket like this:
[root@yf-mos-test-net09 tests]# python
> Python 2.7.5 (default, Jun 24 2015, 00:41:19)
> [GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from socket import *
> >>> sock = socket(AF_INET, SOCK_STREAM, 0)
> >>> sock.connect(('127.0.0.1', 55902))
> >>> sock.recv(1024)
> "QEMU 2.6.0 monitor - type 'help' for more information\r\n(qemu) "
> >>> sock.recv(1024)
> ^CTraceback (most recent call last):
> File "", line 1, in
> KeyboardInterrupt
> >>> sock.send('chardev-add
> socket,id=char-vhost_test_intf1,path=/usr/local/var/run/openvswitch/vhost_test_intf1,server=on')
> 106
> >>> sock.send('netdev_add
> vhost-user,id=vhost_test_intf1,chardev=char-vhost_test_intf1,vhostforce=on')
> 85
> >>> sock.send('device_add
> virtio-net-pci,netdev=vhost_test_intf1,mac=00:22:79:29:d2:6c,id=netdev-vhost_test_intf1')
> 98
> >>> sock.recv(1024)
> 'c\x1b[K\x1b[Dch\x1b[K\x1b[D\x1b[Dcha\x1b[K\x1b[D\x1b[D\x1b[Dchar\x1b[K\x1b[D\x1b[D\x1b[D\x1b[Dchard\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dcharde\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-a\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-ad\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> \x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> s\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> so\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> soc\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> sock\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> socke\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> socket\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> socket,\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> socket,i\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> socket,id\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[D\x1b[Dchardev-add
> socket,id=\x1b[K\x1b[D\x1b[D\x1b[D\x1b[D'
> >>>
But as we see, there are problems:
1. commands like '>>> sock.send('chardev-add
socket,id=char-vhost_test_intf1,path=/usr/local/var/run/openvswitch/vhost_test_intf1,server=on')
106' does not work, this I'm very sure and I use some method to verify it.
2. commands like '>>> sock.recv(1024)' got a lot of unknown characters.
So is there some one who use python(or shell) to connect monitor socket of
VM? Could you please share the code or tell me the way to operate?
For example, should I send command with '(qemu) ' before my command? Should
I recv result by the end of '\r\n' or something?
Thank you~
[Qemu-devel] [PATCH V5 1/3] net/colo-compare.c: Optimize unpredictable tcp options comparison
When network is busy, some tcp options(like sack) will unpredictable
occur in primary side or secondary side. it will make packet size
not same, but the two packet's payload is identical. colo just
care about packet payload, so we skip the option field.
Signed-off-by: Zhang Chen
---
net/colo-compare.c | 40
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/net/colo-compare.c b/net/colo-compare.c
index ca67c68..18a9ebf 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -186,7 +186,10 @@ static int packet_enqueue(CompareState *s, int mode)
* return:0 means packet same
*> 0 || < 0 means packet different
*/
-static int colo_packet_compare_common(Packet *ppkt, Packet *spkt, int offset)
+static int colo_packet_compare_common(Packet *ppkt,
+ Packet *spkt,
+ int poffset,
+ int soffset)
{
if (trace_event_get_state(TRACE_COLO_COMPARE_MISCOMPARE)) {
char pri_ip_src[20], pri_ip_dst[20], sec_ip_src[20], sec_ip_dst[20];
@@ -201,12 +204,14 @@ static int colo_packet_compare_common(Packet *ppkt,
Packet *spkt, int offset)
sec_ip_src, sec_ip_dst);
}
-offset = ppkt->vnet_hdr_len + offset;
+poffset = ppkt->vnet_hdr_len + poffset;
+soffset = ppkt->vnet_hdr_len + soffset;
-if (ppkt->size == spkt->size) {
-return memcmp(ppkt->data + offset,
- spkt->data + offset,
- spkt->size - offset);
+if (ppkt->size == spkt->size ||
+ppkt->size - poffset == spkt->size - soffset) {
+return memcmp(ppkt->data + poffset,
+ spkt->data + soffset,
+ spkt->size - soffset);
} else {
trace_colo_compare_main("Net packet size are not the same");
return -1;
@@ -263,13 +268,22 @@ static int colo_packet_compare_tcp(Packet *spkt, Packet
*ppkt)
* so we just need skip this field.
*/
if (ptcp->th_off > 5) {
-ptrdiff_t tcp_offset;
+ptrdiff_t ptcp_offset, stcp_offset;
-tcp_offset = ppkt->transport_header - (uint8_t *)ppkt->data
- + (ptcp->th_off * 4) - ppkt->vnet_hdr_len;
-res = colo_packet_compare_common(ppkt, spkt, tcp_offset);
+ptcp_offset = ppkt->transport_header - (uint8_t *)ppkt->data
+ + (ptcp->th_off * 4) - ppkt->vnet_hdr_len;
+stcp_offset = spkt->transport_header - (uint8_t *)spkt->data
+ + (stcp->th_off * 4) - spkt->vnet_hdr_len;
+
+/*
+ * When network is busy, some tcp options(like sack) will unpredictable
+ * occur in primary side or secondary side. it will make packet size
+ * not same, but the two packet's payload is identical. colo just
+ * care about packet payload, so we skip the option field.
+ */
+res = colo_packet_compare_common(ppkt, spkt, ptcp_offset, stcp_offset);
} else if (ptcp->th_sum == stcp->th_sum) {
-res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN);
+res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN, ETH_HLEN);
} else {
res = -1;
}
@@ -329,6 +343,7 @@ static int colo_packet_compare_udp(Packet *spkt, Packet
*ppkt)
* the ip payload here.
*/
ret = colo_packet_compare_common(ppkt, spkt,
+ network_header_length + ETH_HLEN,
network_header_length + ETH_HLEN);
if (ret) {
@@ -366,6 +381,7 @@ static int colo_packet_compare_icmp(Packet *spkt, Packet
*ppkt)
* the ip payload here.
*/
if (colo_packet_compare_common(ppkt, spkt,
+ network_header_length + ETH_HLEN,
network_header_length + ETH_HLEN)) {
trace_colo_compare_icmp_miscompare("primary pkt size",
ppkt->size);
@@ -403,7 +419,7 @@ static int colo_packet_compare_other(Packet *spkt, Packet
*ppkt)
sec_ip_src, sec_ip_dst);
}
-return colo_packet_compare_common(ppkt, spkt, 0);
+return colo_packet_compare_common(ppkt, spkt, 0, 0);
}
static int colo_old_packet_check_one(Packet *pkt, int64_t *check_time)
--
2.7.4
[Qemu-devel] [PATCH V5 3/3] net/colo-compare.c: Fix comments and scheme
Signed-off-by: Zhang Chen
---
net/colo-compare.c | 59 --
1 file changed, 31 insertions(+), 28 deletions(-)
diff --git a/net/colo-compare.c b/net/colo-compare.c
index 8dd76e4..c9a7174 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -41,27 +41,27 @@
#define REGULAR_PACKET_CHECK_MS 3000
/*
- + CompareState ++
- | |
- +---+ +---+ +---+
- |conn list +--->conn +->conn |
- +---+ +---+ +---+
- | | | | | |
- +---+ +---v+ +---v++---v+ +---v+
-|primary | |secondary|primary | |secondary
-|packet | |packet +|packet | |packet +
-++ ++++ ++
-| | | |
-+---v+ +---v++---v+ +---v+
-|primary | |secondary|primary | |secondary
-|packet | |packet +|packet | |packet +
-++ ++++ ++
-| | | |
-+---v+ +---v++---v+ +---v+
-|primary | |secondary|primary | |secondary
-|packet | |packet +|packet | |packet +
-++ ++++ ++
-*/
+ * + CompareState ++
+ * | |
+ * +---+ +---+ +---+
+ * | conn list + - > conn + --- > conn + -- > ..
+ * +---+ +---+ +---+
+ * | | | | | |
+ * +---+ +---v+ +---v++---v+ +---v+
+ *|primary | |secondary|primary | |secondary
+ *|packet | |packet +|packet | |packet +
+ *++ ++++ ++
+ *| | | |
+ *+---v+ +---v++---v+ +---v+
+ *|primary | |secondary|primary | |secondary
+ *|packet | |packet +|packet | |packet +
+ *++ ++++ ++
+ *| | | |
+ *+---v+ +---v++---v+ +---v+
+ *|primary | |secondary|primary | |secondary
+ *|packet | |packet +|packet | |packet +
+ *++ ++++ ++
+ */
typedef struct CompareState {
Object parent;
@@ -75,14 +75,14 @@ typedef struct CompareState {
SocketReadState sec_rs;
bool vnet_hdr;
-/* connection list: the connections belonged to this NIC could be found
- * in this list.
- * element type: Connection
+/*
+ * Record the connection that through the NIC
+ * Element type: Connection
*/
GQueue conn_list;
-/* hashtable to save connection */
+/* Record the connection without repetition */
GHashTable *connection_track_table;
-/* compare thread, a thread for each NIC */
+/* This thread just do packet compare job */
QemuThread thread;
GMainContext *worker_context;
@@ -445,8 +445,11 @@ static int colo_old_packet_check_one_conn(Connection *conn,
(GCompareFunc)colo_old_packet_check_one);
if (result) {
-/* do checkpoint will flush old packet */
-/* TODO: colo_notify_checkpoint();*/
+/* Do checkpoint will flush old packet */
+/*
+ * TODO: Notify colo frame to do checkpoint.
+ * colo_compare_inconsistent_notify();
+ */
return 0;
}
--
2.7.4
[Qemu-devel] [PATCH V5 0/3] Optimize COLO-compare performance
In this serise, we do a lot of job to optimize COLO net performance. Mainly focus on TCP protocol. V5: - Fix bug in colo_packet_compare_common(). - Fix patch3 ascii graph style. V4: - Remove the old patch1. V3: - Rebase on upstream. - Remove origin p2. - Move the "checkpoint_time_ms" to CompareState, in order to aviod multi colo-compare instance conflict. - Add "TODO comments" for reset s->checkpoint_time_ms. - Add a new patch fix comments and scheme. V2: - Rename p2's subject. Zhang Chen (3): net/colo-compare.c: Optimize unpredictable tcp options comparison net/colo-compare.c: Adjust net queue pop order for performance net/colo-compare.c: Fix comments and scheme net/colo-compare.c | 103 +++-- 1 file changed, 61 insertions(+), 42 deletions(-) -- 2.7.4
[Qemu-devel] [PATCH V5 2/3] net/colo-compare.c: Adjust net queue pop order for performance
The packet_enqueue() use g_queue_push_tail() to
enqueue net packet, so it is more efficent way use
g_queue_pop_head() to get packet for compare.
That will improve the success rate of comparison.
In my test the performance of ftp put 1000M file
will increase 10%
Signed-off-by: Zhang Chen
---
net/colo-compare.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/colo-compare.c b/net/colo-compare.c
index 18a9ebf..8dd76e4 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -484,7 +484,7 @@ static void colo_compare_connection(void *opaque, void
*user_data)
while (!g_queue_is_empty(&conn->primary_list) &&
!g_queue_is_empty(&conn->secondary_list)) {
-pkt = g_queue_pop_tail(&conn->primary_list);
+pkt = g_queue_pop_head(&conn->primary_list);
switch (conn->ip_proto) {
case IPPROTO_TCP:
result = g_queue_find_custom(&conn->secondary_list,
@@ -522,7 +522,7 @@ static void colo_compare_connection(void *opaque, void
*user_data)
* until next comparison.
*/
trace_colo_compare_main("packet different");
-g_queue_push_tail(&conn->primary_list, pkt);
+g_queue_push_head(&conn->primary_list, pkt);
/* TODO: colo_notify_checkpoint();*/
break;
}
--
2.7.4
Re: [Qemu-devel] [PATCH v2 0/8] ppc: cpu_model handling cleanups
On Wed, Aug 30, 2017 at 03:24:27PM +0200, Igor Mammedov wrote: > > Changelog since v1: > - normalize all cpu model names to lower-case > - check that all cpu model string is consumed > before going to PVR lookup path > - add a new optional patch to remove unused junk > '[PATCH v2 8/8] ppc: remove non implemented cpu models' > - pull in dependency patch from > https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg03364.html > 'ppc: replace cpu_ppc_init() with cpu_generic_init()' > so this series won't depend unnecessarily on another series > > While removing cpu_init() tree-wide, I've stumbled uppon > PPC way of parsing cpu_model which looked way too complex > compared to other targets. > > So here goes cleanups that instead of current inconsistent > way of dealing with cpu models > - mix of case-(in)sensetive lookups and cpu model names > - aliases pointing to another aliases > normalize cpu model names to upper-case and make aliases > point to cpu moldel names. These changes allow to simplify > cpu model handling quite a bit and make it look/behave > a bit more in line with other targets. > > Patches are not must have for cpu_init() removal but make > it a little bit easier without need to deal with way of > conversion of cpu model to cpu type, so pls consider > merging it early once 2.11 merge window is open if > patches make any sense. Patches 1..7 applied to ppc-for-2.11. Still reading the thread of comments on patch 8. > > > repo for testing: > https://github.com/imammedo/qemu.git ppc_cpu_model_cleanups_V2 > > CC: David Gibson > CC: Alexander Graf > CC: qemu-...@nongnu.org > > Igor Mammedov (8): > ppc: replace cpu_ppc_init() with cpu_generic_init() > ppc: use macros to make cpu type name from string literal > ppc: make cpu_model translation to type consistent > ppc: make cpu alias point only to real cpu models > ppc: replace inter-function cyclic dependency/recurssion with 2 simple > lookups > ppc: simplify cpu model lookup by PVR > ppc: drop caching ObjectClass from PowerPCCPUAlias > ppc: remove non implemented cpu models > > target/ppc/cpu-models.h |3 +- > target/ppc/cpu.h|6 +- > target/ppc/kvm_ppc.h|2 +- > hw/ppc/e500.c |3 +- > hw/ppc/mac_newworld.c |3 +- > hw/ppc/mac_oldworld.c |3 +- > hw/ppc/ppc440_bamboo.c |2 +- > hw/ppc/ppc4xx_devs.c|2 +- > hw/ppc/prep.c |5 +- > hw/ppc/spapr_cpu_core.c | 24 +- > hw/ppc/virtex_ml507.c |2 +- > target/ppc/cpu-models.c | 1023 > --- > target/ppc/kvm.c|5 +- > target/ppc/translate_init.c | 105 ++--- > 14 files changed, 344 insertions(+), 844 deletions(-) > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH v8 0/4] Improve error reporting
On 09/04/2017 11:09 AM, Jason Wang wrote: On 2017年07月06日 16:47, Mao Zhongyi wrote: v8: * PATCH 02 & 04 -resetting the error message for the user to read. [Markus Armbruster] -fix the indentation and commit message. [Markus Armbruster] v7: * PATCH 01 -fix the error message.[Daniel P. Berrange] -adjust the indentation problem.[Eric Blake] * PATCH 03 -print a generic message when gethostbyname() failed in parse_host_port(), drop the misleading ": unkonwn host" part.[Markus Armbruster] v6: * PATCH 02 -rename the subject -drop the "qemu: error: " prefix. -correct inappropriate error information settings. * PATCH 03,04 -correct inappropriate error information settings.[Markus Armbruster] v5: * PATCH 01 make the commit message more exact about the actual function. [Markus Armbruster] * PATCH 02, 03, 04 still retains the original function, but specific content and order of each patch has been adjusted substantially, so that ensure each patch is a completed fix.[Markus Armbruster] v4: * PATCH 01 is redoing previous patch 1, replace the fprintf() with error_report() in the 'default' case of net_socket_fd_init() [Markus Armbruster] v3: * PATCH 01 is suggested by Markus and Daniel that removes the dubious 'default' case in the net_socket_fd_init(). Jason agreed. * PATCH 02 is redoing previous patch 4. * PATCH 04 is redoing previous patch 2, improves sort of error messages. v2: * PATCH 02 reworking of patch 2 following Markus's suggestion that convert error_report() in the function called by net_socket_*_init() to Error. Also add many error handling information. * PATCH 03 net_socket_mcast_create(), net_socket_fd_init_dgram() and net_socket_fd_init() use the function such as fprintf, perror to report an error message. Convert it to Error. * PATCH 04 parse_host_port() may fail without reporting an error. Now, fix it to set an error when it fails. Cc: jasow...@redhat.com Cc: arm...@redhat.com Cc: berra...@redhat.com Cc: kra...@redhat.com Cc: pbonz...@redhat.com Cc: ebl...@redhat.com Mao Zhongyi (4): net/socket: Don't treat odd socket type as SOCK_STREAM net/socket: Convert several helper functions to Error net/net: Convert parse_host_port() to Error net/socket: Improve -net socket error reporting include/qemu/sockets.h | 3 +- net/net.c | 22 +-- net/socket.c | 153 - 3 files changed, 106 insertions(+), 72 deletions(-) Hi: Want to apply this, but looks like it does not apply cleanly, could you please send a new version? Thanks OK, I will. Thanks, Mao
Re: [Qemu-devel] [PATCH v8 0/4] Improve error reporting
On 2017年07月06日 16:47, Mao Zhongyi wrote: v8: * PATCH 02 & 04 -resetting the error message for the user to read. [Markus Armbruster] -fix the indentation and commit message. [Markus Armbruster] v7: * PATCH 01 -fix the error message.[Daniel P. Berrange] -adjust the indentation problem.[Eric Blake] * PATCH 03 -print a generic message when gethostbyname() failed in parse_host_port(), drop the misleading ": unkonwn host" part.[Markus Armbruster] v6: * PATCH 02 -rename the subject -drop the "qemu: error: " prefix. -correct inappropriate error information settings. * PATCH 03,04 -correct inappropriate error information settings.[Markus Armbruster] v5: * PATCH 01 make the commit message more exact about the actual function. [Markus Armbruster] * PATCH 02, 03, 04 still retains the original function, but specific content and order of each patch has been adjusted substantially, so that ensure each patch is a completed fix.[Markus Armbruster] v4: * PATCH 01 is redoing previous patch 1, replace the fprintf() with error_report() in the 'default' case of net_socket_fd_init() [Markus Armbruster] v3: * PATCH 01 is suggested by Markus and Daniel that removes the dubious 'default' case in the net_socket_fd_init(). Jason agreed. * PATCH 02 is redoing previous patch 4. * PATCH 04 is redoing previous patch 2, improves sort of error messages. v2: * PATCH 02 reworking of patch 2 following Markus's suggestion that convert error_report() in the function called by net_socket_*_init() to Error. Also add many error handling information. * PATCH 03 net_socket_mcast_create(), net_socket_fd_init_dgram() and net_socket_fd_init() use the function such as fprintf, perror to report an error message. Convert it to Error. * PATCH 04 parse_host_port() may fail without reporting an error. Now, fix it to set an error when it fails. Cc: jasow...@redhat.com Cc: arm...@redhat.com Cc: berra...@redhat.com Cc: kra...@redhat.com Cc: pbonz...@redhat.com Cc: ebl...@redhat.com Mao Zhongyi (4): net/socket: Don't treat odd socket type as SOCK_STREAM net/socket: Convert several helper functions to Error net/net: Convert parse_host_port() to Error net/socket: Improve -net socket error reporting include/qemu/sockets.h | 3 +- net/net.c | 22 +-- net/socket.c | 153 - 3 files changed, 106 insertions(+), 72 deletions(-) Hi: Want to apply this, but looks like it does not apply cleanly, could you please send a new version? Thanks
Re: [Qemu-devel] [PATCH V4 1/3] net/colo-compare.c: Optimize unpredictable tcp options comparison
Hi Chen,
At 09/02/2017 12:02 AM, Zhang Chen wrote:
On 09/01/2017 05:35 PM, Dou Liyang wrote:
Hi chen,
At 08/21/2017 04:55 PM, Zhang Chen wrote:
When network is busy, some tcp options(like sack) will unpredictable
occur in primary side or secondary side. it will make packet size
not same, but the two packet's payload is identical. colo just
care about packet payload, so we skip the option field.
Signed-off-by: Zhang Chen
---
net/colo-compare.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/net/colo-compare.c b/net/colo-compare.c
index ca67c68..f6bda41 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -186,7 +186,10 @@ static int packet_enqueue(CompareState *s, int
mode)
* return:0 means packet same
*> 0 || < 0 means packet different
*/
-static int colo_packet_compare_common(Packet *ppkt, Packet *spkt,
int offset)
+static int colo_packet_compare_common(Packet *ppkt,
+ Packet *spkt,
+ int poffset,
+ int soffset)
{
if (trace_event_get_state(TRACE_COLO_COMPARE_MISCOMPARE)) {
char pri_ip_src[20], pri_ip_dst[20], sec_ip_src[20],
sec_ip_dst[20];
@@ -201,12 +204,13 @@ static int colo_packet_compare_common(Packet
*ppkt, Packet *spkt, int offset)
sec_ip_src, sec_ip_dst);
}
-offset = ppkt->vnet_hdr_len + offset;
+poffset = ppkt->vnet_hdr_len + poffset;
+soffset = ppkt->vnet_hdr_len + soffset;
-if (ppkt->size == spkt->size) {
-return memcmp(ppkt->data + offset,
- spkt->data + offset,
- spkt->size - offset);
+if (ppkt->size == spkt->size || poffset != soffset) {
+return memcmp(ppkt->data + poffset,
+ spkt->data + soffset,
+ spkt->size - soffset);
Here maybe a mistake,
I guess you should make sure
(ppkt->size - poffset) == (spkt->size - soffset) is true in case of
(poffset != soffset) at the same time.
Because, if sack make the header not equal, it is also possible that
the data is not equal at the same time.
Good catch! In rare situation will miss a different packet, I will fix
it in next version.
Thank you very much!
} else {
trace_colo_compare_main("Net packet size are not the same");
return -1;
@@ -263,13 +267,22 @@ static int colo_packet_compare_tcp(Packet
*spkt, Packet *ppkt)
* so we just need skip this field.
*/
if (ptcp->th_off > 5) {
-ptrdiff_t tcp_offset;
+ptrdiff_t ptcp_offset, stcp_offset;
-tcp_offset = ppkt->transport_header - (uint8_t *)ppkt->data
- + (ptcp->th_off * 4) - ppkt->vnet_hdr_len;
-res = colo_packet_compare_common(ppkt, spkt, tcp_offset);
+ptcp_offset = ppkt->transport_header - (uint8_t *)ppkt->data
+ + (ptcp->th_off * 4) - ppkt->vnet_hdr_len;
+stcp_offset = spkt->transport_header - (uint8_t *)spkt->data
+ + (stcp->th_off * 4) - spkt->vnet_hdr_len;
+
+/*
+ * When network is busy, some tcp options(like sack) will
unpredictable
+ * occur in primary side or secondary side. it will make
packet size
+ * not same, but the two packet's payload is identical. colo
just
+ * care about packet payload, so we skip the option field.
+ */
+res = colo_packet_compare_common(ppkt, spkt, ptcp_offset,
stcp_offset);
we add a new parameter in xxx_common() just for xxx_tcp().
In my opinion, it seems not good.
Can we split the tcp related code out from xxx_common, and make the
xxx_common function just do like what its name says.
We introduce this parameter for all protocol, just tcp is the first user.
We should have the ability of compare all kinds of packet.
Maybe we must use different offset for other protocol except tcp in the
future.
Got it,
Thanks,
dou.
Thanks
Zhang Chen
} else if (ptcp->th_sum == stcp->th_sum) {
-res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN);
+res = colo_packet_compare_common(ppkt, spkt, ETH_HLEN,
ETH_HLEN);
} else {
res = -1;
}
@@ -329,6 +342,7 @@ static int colo_packet_compare_udp(Packet *spkt,
Packet *ppkt)
* the ip payload here.
*/
ret = colo_packet_compare_common(ppkt, spkt,
+ network_header_length + ETH_HLEN,
network_header_length + ETH_HLEN);
ditto
if (ret) {
@@ -366,6 +380,7 @@ static int colo_packet_compare_icmp(Packet *spkt,
Packet *ppkt)
* the ip payload here.
*/
if (colo_packet_compare_common(ppkt, spkt,
+ network_header_length + ETH_HLEN,
network_header_length + ETH_HLEN)) {
ditto
trace_colo_compare_icmp_miscompare("pri
Re: [Qemu-devel] [PATCH] x86/acpi: build SRAT when memory hotplug is enabled
Hi Eduardo, Thadeu,
At 09/02/2017 12:11 AM, Eduardo Habkost wrote:
On Fri, Sep 01, 2017 at 12:45:42PM -0300, Thadeu Lima de Souza Cascardo wrote:
Linux uses SRAT to determine the maximum memory in a system, which is
used to determine whether to use the swiotlb for IOMMU or not for a
device that supports only 32 bits of addresses.
Do you have a pointer to the corresponding Linux code, for
reference? Which SRAT entries Linux uses to make this decision?
When there is no NUMA configuration, qemu will not build SRAT. And when
memory hotplug is done, some Linux device drivers start failing.
Tested by running with -m 512M,slots=8,maxmem=1G, adding the memory,
putting that online and using the system. Without the patch, swiotlb is
not used and ATA driver fails. With the patch, swiotlb is used, no
driver failure is observed.
Signed-off-by: Thadeu Lima de Souza Cascardo
As far as I can see, this will only add APIC entries and a memory
affinity entry for the first 640KB (which would be obviously
wrong) if pcms->numa_nodes is 0.
In my opinion, this may also add the hotpluggable memory, and see the
following commemts.
/*
* Entry is required for Windows to enable memory hotplug in OS
* and for Linux to enable SWIOTLB when booted with less than
* 4G of RAM. Windows works better if the entry sets proximity
* to the highest NUMA node in the machine.
* Memory devices may override proximity set by this entry,
* providing _PXM method if necessary.
*/
if (hotplugabble_address_space_size) {
numamem = acpi_data_push(table_data, sizeof *numamem);
build_srat_memory(numamem, pcms->hotplug_memory.base,
hotplugabble_address_space_size,
pcms->numa_nodes - 1,
MEM_AFFINITY_HOTPLUGGABLE |
MEM_AFFINITY_ENABLED);
}
Thanks,
dou.
Once we apply the "Fix SRAT memory building in case of node 0
without RAM" patch from Dou Liyang, no memory affinity entries
will be generated if pcms->numa_nodes is 0. Would this cause the
problem to happen again?
---
hw/i386/acpi-build.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 98dd424678..fb94249779 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -2645,6 +2645,9 @@ void acpi_build(AcpiBuildTables *tables, MachineState
*machine)
GArray *tables_blob = tables->table_data;
AcpiSlicOem slic_oem = { .id = NULL, .table_id = NULL };
Object *vmgenid_dev;
+ram_addr_t hotplugabble_address_space_size =
+object_property_get_int(OBJECT(pcms), PC_MACHINE_MEMHP_REGION_SIZE,
+NULL);
acpi_get_pm_info(&pm);
acpi_get_misc_info(&misc);
@@ -2708,7 +2711,7 @@ void acpi_build(AcpiBuildTables *tables, MachineState
*machine)
build_tpm2(tables_blob, tables->linker);
}
}
-if (pcms->numa_nodes) {
+if (pcms->numa_nodes || hotplugabble_address_space_size) {
acpi_add_table(table_offsets, tables_blob);
build_srat(tables_blob, tables->linker, machine);
if (have_numa_distance) {
--
2.11.0
Re: [Qemu-devel] [PATCH] memory: Rename queue to mrqueue (memory region queue)
Hi Kamil,
On 09/03/2017 01:33 PM, Kamil Rytarowski wrote:
SunOS declares struct queue in .
I didn't check what is this define for, but I'd rather add in
include/sysemu/os-posix.h:
#ifdef queue
#undef queue
#endif
If no QEMU code rely on this netinet queue.
This fixes build on SmartOS (Joyent).
Patch cherry-picked from pkgsrc by jperkin (Joyent).
Signed-off-by: Kamil Rytarowski
---
memory.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/memory.c b/memory.c
index c0adc35410..b9920a6540 100644
--- a/memory.c
+++ b/memory.c
@@ -2701,10 +2701,10 @@ typedef struct MemoryRegionList MemoryRegionList;
struct MemoryRegionList {
const MemoryRegion *mr;
-QTAILQ_ENTRY(MemoryRegionList) queue;
+QTAILQ_ENTRY(MemoryRegionList) mrqueue;
};
-typedef QTAILQ_HEAD(queue, MemoryRegionList) MemoryRegionListHead;
+typedef QTAILQ_HEAD(mrqueue, MemoryRegionList) MemoryRegionListHead;
#define MR_SIZE(size) (int128_nz(size) ? (hwaddr)int128_get64( \
int128_sub((size), int128_one())) : 0)
@@ -2746,7 +2746,7 @@ static void mtree_print_mr(fprintf_function mon_printf,
void *f,
bool found = false;
/* check if the alias is already in the queue */
-QTAILQ_FOREACH(ml, alias_print_queue, queue) {
+QTAILQ_FOREACH(ml, alias_print_queue, mrqueue) {
if (ml->mr == mr->alias) {
found = true;
}
@@ -2755,7 +2755,7 @@ static void mtree_print_mr(fprintf_function mon_printf,
void *f,
if (!found) {
ml = g_new(MemoryRegionList, 1);
ml->mr = mr->alias;
-QTAILQ_INSERT_TAIL(alias_print_queue, ml, queue);
+QTAILQ_INSERT_TAIL(alias_print_queue, ml, mrqueue);
}
mon_printf(f, TARGET_FMT_plx "-" TARGET_FMT_plx
" (prio %d, %s): alias %s @%s " TARGET_FMT_plx
@@ -2783,26 +2783,26 @@ static void mtree_print_mr(fprintf_function mon_printf,
void *f,
QTAILQ_FOREACH(submr, &mr->subregions, subregions_link) {
new_ml = g_new(MemoryRegionList, 1);
new_ml->mr = submr;
-QTAILQ_FOREACH(ml, &submr_print_queue, queue) {
+QTAILQ_FOREACH(ml, &submr_print_queue, mrqueue) {
if (new_ml->mr->addr < ml->mr->addr ||
(new_ml->mr->addr == ml->mr->addr &&
new_ml->mr->priority > ml->mr->priority)) {
-QTAILQ_INSERT_BEFORE(ml, new_ml, queue);
+QTAILQ_INSERT_BEFORE(ml, new_ml, mrqueue);
new_ml = NULL;
break;
}
}
if (new_ml) {
-QTAILQ_INSERT_TAIL(&submr_print_queue, new_ml, queue);
+QTAILQ_INSERT_TAIL(&submr_print_queue, new_ml, mrqueue);
}
}
-QTAILQ_FOREACH(ml, &submr_print_queue, queue) {
+QTAILQ_FOREACH(ml, &submr_print_queue, mrqueue) {
mtree_print_mr(mon_printf, f, ml->mr, level + 1, cur_start,
alias_print_queue);
}
-QTAILQ_FOREACH_SAFE(ml, &submr_print_queue, queue, next_ml) {
+QTAILQ_FOREACH_SAFE(ml, &submr_print_queue, mrqueue, next_ml) {
g_free(ml);
}
}
@@ -2872,13 +2872,13 @@ void mtree_info(fprintf_function mon_printf, void *f,
bool flatview)
}
/* print aliased regions */
-QTAILQ_FOREACH(ml, &ml_head, queue) {
+QTAILQ_FOREACH(ml, &ml_head, mrqueue) {
mon_printf(f, "memory-region: %s\n", memory_region_name(ml->mr));
mtree_print_mr(mon_printf, f, ml->mr, 1, 0, &ml_head);
mon_printf(f, "\n");
}
-QTAILQ_FOREACH_SAFE(ml, &ml_head, queue, ml2) {
+QTAILQ_FOREACH_SAFE(ml, &ml_head, mrqueue, ml2) {
g_free(ml);
}
}
Re: [Qemu-devel] [PATCH] usb-mtp: Add fallback definition of NAME_MAX
Hi Kamil,
On 09/03/2017 01:34 PM, Kamil Rytarowski wrote:
This fixes build on SmartOS (Joyent).
Patch cherry-picked from pkgsrc by jperkin (Joyent).
Signed-off-by: Kamil Rytarowski
---
hw/usb/dev-mtp.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 94c2e94f10..6e8d7b21b5 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -26,6 +26,10 @@
#include "hw/usb.h"
#include "hw/usb/desc.h"
+#ifndef NAME_MAX
+#define NAME_MAX 255
+#endif
this belongs to include/qemu/osdep.h
once moved there:
Reviewed-by: Philippe Mathieu-Daudé
+
/* --- */
enum mtp_container_type {
Regards,
Phil.
Re: [Qemu-devel] [PATCH] target/m68k: Change fpu_rom from const static array to switch
On 09/03/2017 02:05 PM, Laurent Vivier wrote:
Le 03/09/2017 à 18:31, Kamil Rytarowski a écrit :
GCC 4.7.2 on SunOS reports that the values assigned to array members are not
real constants:
target/m68k/fpu_helper.c:32:5: error: initializer element is not constant
target/m68k/fpu_helper.c:32:5: error: (near initialization for 'fpu_rom[0]')
rules.mak:66: recipe for target 'target/m68k/fpu_helper.o' failed
Convert the array to switch() to workaround the issue.
I don't like the idea. It's really an array and should be managed as an
array.
I agree with Laurent.
Could you try to use make_floatx80_init() instead of make_floatx80() ?
I guess the problem comes from the macro which cast as not const:
#define make_floatx80(exp, mant) ((floatx80) { mant, exp })
make_floatx80_init() doesn't cast so it might work,
else we could add a macro such const_floatx80():
#define const_floatx80(exp, mant) ((const floatx80) { mant, exp })
[Qemu-devel] Questions regarding emulated UART in VersatilePB board
Hello all,
I have 2 problems regarding UART (pl011) in the emulated board VersatilePB.
(I am using *QEMU version 2.8.1.*)
*My main goal is*:
Disturbing the UART registers (such UARTCR, UARTLCR_H ... etc) in order to
simulate hardware faults (which can make bit flips in the hardware
registers through radiation for example).
*My 2 questions are:*
*First:*
Are interrupts activated in the emulated pl011 ?
I mean, if I enabled the interrupt bits for UARTTXINTR, will this trigger
an interrupt when the FIFO reaches a certain level?
*Second:*
Another problem is that I can't find some of the UART registers (which are
in the data sheet PrimeCell UART (PL011)), in QEMU's emulated UART pl011.
*These are the registers which I can't find their matches in the structure
PL011State:*
1.) Interrupt FIFO level select register, UARTIFLS
2.) Raw interrupt status register, UARTRIS
3.) Masked interrupt status register, UARTMIS
4.) Interrupt clear register, UARTICR
5.) Peripheral identification registers, UARTPeriphID0-3
6.) PrimeCell identification registers, UARTPCellID0-3
*This is the structure where I get pl011 emulated registers:*
typedef struct PL011State
{
SysBusDevice parent_obj;
MemoryRegion iomem;
uint32_t readbuff;
uint32_t flags;
uint32_t lcr;
uint32_t rsr;
uint32_t cr;
uint32_t dmacr;
uint32_t int_enabled;
uint32_t int_level;
uint32_t read_fifo[16];
uint32_t ilpr;
uint32_t ibrd;
uint32_t fbrd;
uint32_t ifl;
int read_pos;
int read_count;
int read_trigger;
CharBackend chr;
qemu_irq irq;
const unsigned char *id;
} PL011State
--
Best Regards,
Ramy Sameh
Embedded Software Engineer
+2-010-172-777-14
[Qemu-devel] [Bug 1714331] Re: Virtual machines not working anymore on 2.10
I am also unable to boot Windows 10 64 bit since updating to 2.10.0. I was previously using 2.8.0 which worked perfectly. Windows gets stuck at the big Windows logo with the spinning dots underneath and QEMU uses 100% CPU of 1 core. I am using kernel 4.11.9 and the following command line: qemu-system-x86_64 -serial none -parallel none -balloon none -enable-kvm -name Windows10 -display none -M q35,accel=kvm,mem-merge=off -m 10240 -cpu host,kvm=off,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time,hv_vendor_id=whatever -smp 4,sockets=1,cores=4,threads=1 -realtime mlock=on -vga none -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 -drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/OVMF_CODE-pure-efi.fd -drive if=pflash,format=raw,file=/usr/share/ovmf/OVMF_VARS-pure-efi.fd -drive if=none,id=drive0,cache=directsync,aio=native,format=raw,file=/dev/mint-vg/windows -object iothread,id=iothread0 -device virtio-blk-pci,drive=drive0,scsi=off,iothread=iothread0 -drive if=none,id=drive1,cache=directsync,aio=native,format=raw,file=/dev/evo-vg/windows2 -object iothread,id=iothread1 -device virtio-blk-pci,drive=drive1,scsi=off,iothread=iothread1 -net nic,model=virtio -net bridge,br=br0 -rtc base=localtime,clock=host -usb -device usb-host,bus=usb-bus.0,vendorid=0x1b1c,productid=0x1b22 -device usb-host,bus=usb-bus.0,vendorid=0x1b1c,productid=0x1b15 I have now rolled back to 2.8.0 and it is working again. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1714331 Title: Virtual machines not working anymore on 2.10 Status in QEMU: New Bug description: Using 2.10, my virtual machine(s) don't work anymore. This happens 100% of the times. - I use QEMU compiling it from source, on Ubuntu 16.04 amd64. This is the configure command: configure --target-list=x86_64-softmmu --enable-debug --enable-gtk --enable-spice --audio-drv-list=pa I have one virtual disk, with a Windows 10 64-bit, which I launch in two different ways; both work perfectly on 2.9 (and used to do on 2.8, but I haven't used it for a long time). This is the first way: qemu-system-x86_64 -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp -enable-kvm -machine q35,accel=kvm,mem-merge=off -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time -smp 4,cores=4,sockets=1,threads=1 -m 4096 -display gtk -vga qxl -rtc base=localtime -serial none -parallel none -usb -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device virtio-scsi-pci,id=scsi -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=hdd1 -net nic,model=virtio -net user On QEMU 2.10, I get the `Recovery - Your PC/Device needs to be repaired` windows screen; on 2.9, it boots regularly. This is the second way: qemu-system-x86_64 -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp -enable-kvm -machine q35,accel=kvm,mem-merge=off -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time -smp 4,cores=4,sockets=1,threads=1 -m 10240 -vga none -rtc base=localtime -serial none -parallel none -usb -device vfio-pci,host=01:00.0,multifunction=on -device vfio-pci,host=01:00.1 -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device usb-host,vendorid=0x,productid=0x -device virtio-scsi-pci,id=scsi -drive file=/path/to/image-diff.img,id=hdd1,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=hdd1 -net nic,model=virtio -net user On QEMU 2.10, I get the debug window on the linux monitor, and blank screen on VFIO one (no BIOS screen at all); after 10/20 seconds, QEMU crashes without any message. On 2.9, this works perfectly. - I am able to perform a git bisect, if that helps, but if this is the case, I'd need this issue to be reviewed, since bisecting is going to take me a lot of time
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
On Sun, Sep 3, 2017 at 8:13 PM, Paolo Bonzini > wrote: > > > Il 03 set 2017 6:54 PM, "Izik Eidus" > ha scritto: > > > What code is derived from v2-only sources? IIRC the task switch code is > > derived from KVM, is there anything else? > > Yes this is exactly the code that I found as well, however considering the > fact that I didn't even know it was there requires me to go and validate > that other stuff are safe for GPL2v+. > > > FWIW I didn't find anything else coming from KVM. > > The newer implementation is what we are using in Anka to virtluze macOS > (but it is handling windows/linux/*), in my perspective it is more mature > and handle many more corner case, it is currently not plugged into QEMU, > and all the work that need to happen is: plug it like the KVM user space > bits with the ideas of Sergio, and the recommendations of QEMU for this > patch's. > > One big advantage is that we will be more than happy to back port fix's as > they come from Anka to QEMU hvf. > > > It's difficult for me to judge without seeing your code (couldn't find it > from a quick look on GitHub). > Yea, we will have to open source that code in such case. > I expect any code that we merged from Anka would diverge as QEMU's HVF > integration matures (e.g. adding support for live migration, unifying the > page walkers, etc.). > I think you are right. > On the other hand if you open-source more hypervisor.framework client code > or new instruction emulator code we can certainly merge it back into QEMU > when it makes sense! > For now i want to get hypervisor framework merged into QEMU in required license. I did offer to open source everything needed from anka to the make QEMU being able to run any os using hypervisor.framework. > > I think it's safe to use v2+ for this code once Google agrees. The task > switch code, which is going to go away soon anyway and is isolated from the > rest, can be moved to a separate file for the time being. > OK, such case would be simpler to me to go if this what you prefer, in such case, i will send the 1|2|3 patches splited from task switch and everything beside task switch as gpl2v+. Whatever you guys decide... Thanks. > > Paolo > > > > > > Paolo > > > > in > > such case all copyright go back to BSD2 and we can license it as GPL2v+ > or > > whatever work for QEMU. > > If you want to go in such case what we will do would be the following: > > take kvm user space implemantion of qemu that is GPLv2+, integrate to it > > the hypervisor framework from Anka (in kvm user space style) - this will > > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the > > rest of Sergio changes to this stuff. > > > > I know this is less than ideal as it requires some changes to the current > > patch set, however it will make it 100% safe to be GPL2v+, what you guys > > think?, we can get this stuff done before the end of this week... > > > > Thanks. > > > > > > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus > wrote: > > > > > > > > > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > > > > wrote: > > > > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" > ha scritto: > > >> > > >> > Izik, Vincent (assuming you are the right person to contact at > > Google), > > >> > can you reply to Daniel and Stefan? > > >> > > > >> > > >> Hi, > > >> > > >> What I suggest is that we will send our patch' again as gpl2+ and > clean > > >> the > > >> entire stuff to make sure they are falling into the right copyright > > >> category as required by QEMU. > > >> > > >> > > >> That's not necessary. Just you and Vincent replying to this thread > with > > a > > >> "Signed-off-by" line would be enough for Sergio to use the right > > license in > > >> his v3 submission. Sergio already made some non-trivial changes that > are > > >> needed for inclusion in QEMU from a supportability (e.g. dirty page > > >> tracking for graphics) or maintainability perspective (e.g. -cpu > > support), > > >> so the simplest thing to do is to retrofit the right license to his > > >> submission. You can do so if you can confirm that the code you used > only > > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the > rest > > >> was written by Veertu). > > >> > > > > > > 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
Re: [Qemu-devel] [PATCH 0/8] sun4u: change PCI topology to better match a real Ultra 5
On 11/07/17 22:53, Mark Cave-Ayland wrote: > The aim of this patchset is to bring the sun4u machine in line with a real > Ultra 5 > in order to resolve issues related to PCI bridge windows and interrupt > routing. > > The majority of the changes are designed to accommodate the simba PCI bridges > on > the root PCI bus, moving the on-board devices behind busA (as well as making > the NIC > a fixed on-board multi-function device as per a real Ultra 5). > > Finally we mark unavailable PCI bus slots as reserved on all 3 PCI buses to > ensure > that correct interrupt routing is maintained, regardless of how the command > line is > configure with -device. > > Signed-off-by: Mark Cave-Ayland > > Mark Cave-Ayland (8): > sun4u: pass PCIDevice into pci_ebus_init() instead of PCIBus > sun4u: switch to using qdev to instantiate fw_cfg interface > sun4u: expose fw_cfg and NVRAM on ebus PCI IO address space > apb: fix up PCI bus nomenclature > apb: fix endianness for APB and PCI config accesses > apb: add busA qdev property to PBM PCI bridge > sun4u: create single default onboard ne2k_pci NIC for machine > sun4u: move in-built devices behind PCI bridge A > > hw/pci-host/apb.c | 93 > ++-- > hw/sparc64/sun4u.c | 52 + > 2 files changed, 107 insertions(+), 38 deletions(-) Now that the fw_cfg changes are upstream, I'll apply patches 1-6 to my qemu-sparc branch. The plan is to replace the ne2k_pci NIC with another, and the final switch moving devices behind the PCI bridge is dependent upon other patches still pending further review. ATB, Mark.
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Il 03 set 2017 6:54 PM, "Izik Eidus" ha scritto: > What code is derived from v2-only sources? IIRC the task switch code is > derived from KVM, is there anything else? Yes this is exactly the code that I found as well, however considering the fact that I didn't even know it was there requires me to go and validate that other stuff are safe for GPL2v+. FWIW I didn't find anything else coming from KVM. The newer implementation is what we are using in Anka to virtluze macOS (but it is handling windows/linux/*), in my perspective it is more mature and handle many more corner case, it is currently not plugged into QEMU, and all the work that need to happen is: plug it like the KVM user space bits with the ideas of Sergio, and the recommendations of QEMU for this patch's. One big advantage is that we will be more than happy to back port fix's as they come from Anka to QEMU hvf. It's difficult for me to judge without seeing your code (couldn't find it from a quick look on GitHub). 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.). 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! 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. Paolo > > Paolo > > in > such case all copyright go back to BSD2 and we can license it as GPL2v+ or > whatever work for QEMU. > If you want to go in such case what we will do would be the following: > take kvm user space implemantion of qemu that is GPLv2+, integrate to it > the hypervisor framework from Anka (in kvm user space style) - this will > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the > rest of Sergio changes to this stuff. > > I know this is less than ideal as it requires some changes to the current > patch set, however it will make it 100% safe to be GPL2v+, what you guys > think?, we can get this stuff done before the end of this week... > > Thanks. > > > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus wrote: > > > > > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > > wrote: > > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: > >> > >> > Izik, Vincent (assuming you are the right person to contact at > Google), > >> > can you reply to Daniel and Stefan? > >> > > >> > >> Hi, > >> > >> What I suggest is that we will send our patch' again as gpl2+ and clean > >> the > >> entire stuff to make sure they are falling into the right copyright > >> category as required by QEMU. > >> > >> > >> That's not necessary. Just you and Vincent replying to this thread with > a > >> "Signed-off-by" line would be enough for Sergio to use the right > license in > >> his v3 submission. Sergio already made some non-trivial changes that are > >> needed for inclusion in QEMU from a supportability (e.g. dirty page > >> tracking for graphics) or maintainability perspective (e.g. -cpu > support), > >> so the simplest thing to do is to retrofit the right license to his > >> submission. You can do so if you can confirm that the code you used only > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest > >> was written by Veertu). > >> > > > > 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 > >> > > >> >
Re: [Qemu-devel] [PATCH] target/m68k: Change fpu_rom from const static array to switch
Le 03/09/2017 à 18:31, Kamil Rytarowski a écrit : > GCC 4.7.2 on SunOS reports that the values assigned to array members are not > real constants: > > target/m68k/fpu_helper.c:32:5: error: initializer element is not constant > target/m68k/fpu_helper.c:32:5: error: (near initialization for 'fpu_rom[0]') > rules.mak:66: recipe for target 'target/m68k/fpu_helper.o' failed > > Convert the array to switch() to workaround the issue. I don't like the idea. It's really an array and should be managed as an array. Could you try to use make_floatx80_init() instead of make_floatx80() ? Thanks, Laurent
[Qemu-devel] [PATCH] tests: Do not include lutil on SunOS
This fixes build on SmartOS (Joyent). Patch cherry-picked from pkgsrc by jperkin (Joyent). Signed-off-by: Kamil Rytarowski --- tests/Makefile.include | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/Makefile.include b/tests/Makefile.include index f08b7418f0..0e5e6cb9b8 100644 --- a/tests/Makefile.include +++ b/tests/Makefile.include @@ -810,8 +810,10 @@ tests/migration/initrd-stress.img: tests/migration/stress$(EXESUF) rmdir $(INITRD_WORK_DIR) ifeq ($(CONFIG_POSIX),y) +ifneq ($(CONFIG_SOLARIS),y) LIBS += -lutil endif +endif # QTest rules -- 2.14.1
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
On Sun, Sep 3, 2017 at 7:35 PM, Paolo Bonzini wrote: > > > Il 03 set 2017 6:17 PM, "Izik Eidus" ha scritto: > > Hi, > > Paolo, my biggest challenge right now is: > hvf-all.c > it include currently the following copyright: > > // Copyright 2008 IBM Corporation > > // 2008 Red Hat, Inc. > > // Copyright 2011 Intel Corporation > > // Copyright 2016 Veertu, Inc. > // Copyright 2017 The Android Open Source Project > > and it is GPLv2, However we want to integrate this stuff to QEMU in the > required license (GPLv2+), I have a suggestion that maybe the safest way > for us to achieve GPLv2+ would be that we will send you the current > hypervisor framework implementation of Anka that is derived from > xhyve/bhyve + our own changes to make it run windows / linux / macOS, > > > What code is derived from v2-only sources? IIRC the task switch code is > derived from KVM, is there anything else? > Yes this is exactly the code that I found as well, however considering the fact that I didn't even know it was there requires me to go and validate that other stuff are safe for GPL2v+. > > If you can identify the functions that cannot be v2-or-later that's > already okay. There is a lot more refactoring to do in the HVF code to > remove duplication with other parts of the code, and if it's just a couple > isolated cases we can maybe try to prioritize them. For example it's part > of the plan to replace the task switch code with the version in > seg_helper.c. Worst case, QEMU has done clean room reverse engineering a > couple times in the past to fix licensing issues. > > If you think your plan works better and you can devote a week to it, we > can also try it. But having a clear answer on what code is from v2-only > sources may help judging on the better approach. I an worried that some of > the later patches could be tricky to redo/backport. What are the advantages > of the newer implementation? Does it reuse more KVM userspace bits? > The newer implementation is what we are using in Anka to virtluze macOS (but it is handling windows/linux/*), in my perspective it is more mature and handle many more corner case, it is currently not plugged into QEMU, and all the work that need to happen is: plug it like the KVM user space bits with the ideas of Sergio, and the recommendations of QEMU for this patch's. One big advantage is that we will be more than happy to back port fix's as they come from Anka to QEMU hvf. > > Paolo > > in > such case all copyright go back to BSD2 and we can license it as GPL2v+ or > whatever work for QEMU. > If you want to go in such case what we will do would be the following: > take kvm user space implemantion of qemu that is GPLv2+, integrate to it > the hypervisor framework from Anka (in kvm user space style) - this will > put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the > rest of Sergio changes to this stuff. > > I know this is less than ideal as it requires some changes to the current > patch set, however it will make it 100% safe to be GPL2v+, what you guys > think?, we can get this stuff done before the end of this week... > > Thanks. > > > On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus wrote: > > > > > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > > wrote: > > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: > >> > >> > Izik, Vincent (assuming you are the right person to contact at > Google), > >> > can you reply to Daniel and Stefan? > >> > > >> > >> Hi, > >> > >> What I suggest is that we will send our patch' again as gpl2+ and clean > >> the > >> entire stuff to make sure they are falling into the right copyright > >> category as required by QEMU. > >> > >> > >> That's not necessary. Just you and Vincent replying to this thread with > a > >> "Signed-off-by" line would be enough for Sergio to use the right > license in > >> his v3 submission. Sergio already made some non-trivial changes that are > >> needed for inclusion in QEMU from a supportability (e.g. dirty page > >> tracking for graphics) or maintainability perspective (e.g. -cpu > support), > >> so the simplest thing to do is to retrofit the right license to his > >> submission. You can do so if you can confirm that the code you used only > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest > >> was written by Veertu). > >> > > > > Hi, > > > > Sure fine with us, let me go over all the code and see that all 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
[Qemu-devel] [PATCH] e1000: Rename the SEC symbol to SEQEC
SunOS defines SEC in as 1 (commonly used time symbols).
This fixes build on SmartOS (Joyent).
Patch cherry-picked from pkgsrc by jperkin (Joyent).
Signed-off-by: Kamil Rytarowski
---
hw/net/e1000.c | 4 ++--
hw/net/e1000_regs.h| 2 +-
hw/net/e1000e_core.c | 2 +-
hw/net/e1000x_common.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/net/e1000.c b/hw/net/e1000.c
index f2e5072d27..eebe3a9c13 100644
--- a/hw/net/e1000.c
+++ b/hw/net/e1000.c
@@ -1127,7 +1127,7 @@ static uint32_t (*macreg_readops[])(E1000State *, int) = {
getreg(TADV), getreg(ITR), getreg(FCRUC),getreg(IPAV),
getreg(WUC), getreg(WUS), getreg(SCC), getreg(ECOL),
getreg(MCC), getreg(LATECOL), getreg(COLC), getreg(DC),
-getreg(TNCRS),getreg(SEC), getreg(CEXTERR), getreg(RLEC),
+getreg(TNCRS),getreg(SEQEC),getreg(CEXTERR), getreg(RLEC),
getreg(XONRXC), getreg(XONTXC), getreg(XOFFRXC), getreg(XOFFTXC),
getreg(RFC), getreg(RJC), getreg(RNBC), getreg(TSCTFC),
getreg(MGTPRC), getreg(MGTPDC), getreg(MGTPTC), getreg(GORCL),
@@ -1223,7 +1223,7 @@ static const uint8_t mac_reg_access[0x8000] = {
[FFLT]= markflag(MAC),[FFMT]= markflag(MAC),
[SCC] = markflag(MAC),[FCRUC] = markflag(MAC),
[LATECOL] = markflag(MAC),[COLC]= markflag(MAC),
-[SEC] = markflag(MAC),[CEXTERR] = markflag(MAC),
+[SEQEC] = markflag(MAC),[CEXTERR] = markflag(MAC),
[XONTXC] = markflag(MAC),[XOFFRXC] = markflag(MAC),
[RJC] = markflag(MAC),[RNBC]= markflag(MAC),
[MGTPDC] = markflag(MAC),[MGTPTC] = markflag(MAC),
diff --git a/hw/net/e1000_regs.h b/hw/net/e1000_regs.h
index 23eed50b9c..ae99f58bab 100644
--- a/hw/net/e1000_regs.h
+++ b/hw/net/e1000_regs.h
@@ -260,7 +260,7 @@
#define E1000_COLC 0x04028 /* Collision Count - R/clr */
#define E1000_DC 0x04030 /* Defer Count - R/clr */
#define E1000_TNCRS0x04034 /* TX-No CRS - R/clr */
-#define E1000_SEC 0x04038 /* Sequence Error Count - R/clr */
+#define E1000_SEQEC0x04038 /* Sequence Error Count - R/clr */
#define E1000_CEXTERR 0x0403C /* Carrier Extension Error Count - R/clr */
#define E1000_RLEC 0x04040 /* Receive Length Error Count - R/clr */
#define E1000_XONRXC 0x04048 /* XON RX Count - R/clr */
diff --git a/hw/net/e1000e_core.c b/hw/net/e1000e_core.c
index 81405640f0..43a8d89955 100644
--- a/hw/net/e1000e_core.c
+++ b/hw/net/e1000e_core.c
@@ -2855,7 +2855,7 @@ static uint32_t (*e1000e_macreg_readops[])(E1000ECore *,
int) = {
e1000e_getreg(RDLEN0),
e1000e_getreg(RDH1),
e1000e_getreg(LATECOL),
-e1000e_getreg(SEC),
+e1000e_getreg(SEQEC),
e1000e_getreg(XONTXC),
e1000e_getreg(WUS),
e1000e_getreg(GORCL),
diff --git a/hw/net/e1000x_common.h b/hw/net/e1000x_common.h
index 21bf28e0cc..3072ce9d50 100644
--- a/hw/net/e1000x_common.h
+++ b/hw/net/e1000x_common.h
@@ -40,7 +40,7 @@ enum {
defreg(VFTA),defreg(VET), defreg(RDTR),defreg(RADV),
defreg(TADV),defreg(ITR), defreg(SCC), defreg(ECOL),
defreg(MCC), defreg(LATECOL), defreg(COLC),defreg(DC),
-defreg(TNCRS), defreg(SEC), defreg(CEXTERR), defreg(RLEC),
+defreg(TNCRS), defreg(SEQEC), defreg(CEXTERR), defreg(RLEC),
defreg(XONRXC), defreg(XONTXC), defreg(XOFFRXC), defreg(XOFFTXC),
defreg(FCRUC), defreg(AIT), defreg(TDFH),defreg(TDFT),
defreg(TDFHS), defreg(TDFTS), defreg(TDFPC), defreg(WUC),
--
2.14.1
[Qemu-devel] [PATCH] scsi/esp: Rename the ESP symbol to QESP (QEMU ESP)
SunOS defines ESP (x86 register) in as 7.
This fixes build on SmartOS (Joyent).
Signed-off-by: Kamil Rytarowski
---
hw/scsi/esp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index eee831efeb..38ddfd6715 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -593,7 +593,7 @@ const VMStateDescription vmstate_esp = {
};
#define TYPE_ESP "esp"
-#define ESP(obj) OBJECT_CHECK(SysBusESPState, (obj), TYPE_ESP)
+#define QESP(obj) OBJECT_CHECK(SysBusESPState, (obj), TYPE_ESP)
typedef struct {
/*< private >*/
@@ -644,7 +644,7 @@ void esp_init(hwaddr espaddr, int it_shift,
ESPState *esp;
dev = qdev_create(NULL, TYPE_ESP);
-sysbus = ESP(dev);
+sysbus = QESP(dev);
esp = &sysbus->esp;
esp->dma_memory_read = dma_memory_read;
esp->dma_memory_write = dma_memory_write;
@@ -672,7 +672,7 @@ static const struct SCSIBusInfo esp_scsi_info = {
static void sysbus_esp_gpio_demux(void *opaque, int irq, int level)
{
-SysBusESPState *sysbus = ESP(opaque);
+SysBusESPState *sysbus = QESP(opaque);
ESPState *s = &sysbus->esp;
switch (irq) {
@@ -688,7 +688,7 @@ static void sysbus_esp_gpio_demux(void *opaque, int irq,
int level)
static void sysbus_esp_realize(DeviceState *dev, Error **errp)
{
SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
-SysBusESPState *sysbus = ESP(dev);
+SysBusESPState *sysbus = QESP(dev);
ESPState *s = &sysbus->esp;
sysbus_init_irq(sbd, &s->irq);
@@ -706,7 +706,7 @@ static void sysbus_esp_realize(DeviceState *dev, Error
**errp)
static void sysbus_esp_hard_reset(DeviceState *dev)
{
-SysBusESPState *sysbus = ESP(dev);
+SysBusESPState *sysbus = QESP(dev);
esp_hard_reset(&sysbus->esp);
}
--
2.14.1
[Qemu-devel] [PATCH] usb-mtp: Add fallback definition of NAME_MAX
This fixes build on SmartOS (Joyent).
Patch cherry-picked from pkgsrc by jperkin (Joyent).
Signed-off-by: Kamil Rytarowski
---
hw/usb/dev-mtp.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index 94c2e94f10..6e8d7b21b5 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -26,6 +26,10 @@
#include "hw/usb.h"
#include "hw/usb/desc.h"
+#ifndef NAME_MAX
+#define NAME_MAX 255
+#endif
+
/* --- */
enum mtp_container_type {
--
2.14.1
[Qemu-devel] [PATCH] memory: Rename queue to mrqueue (memory region queue)
SunOS declares struct queue in .
This fixes build on SmartOS (Joyent).
Patch cherry-picked from pkgsrc by jperkin (Joyent).
Signed-off-by: Kamil Rytarowski
---
memory.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/memory.c b/memory.c
index c0adc35410..b9920a6540 100644
--- a/memory.c
+++ b/memory.c
@@ -2701,10 +2701,10 @@ typedef struct MemoryRegionList MemoryRegionList;
struct MemoryRegionList {
const MemoryRegion *mr;
-QTAILQ_ENTRY(MemoryRegionList) queue;
+QTAILQ_ENTRY(MemoryRegionList) mrqueue;
};
-typedef QTAILQ_HEAD(queue, MemoryRegionList) MemoryRegionListHead;
+typedef QTAILQ_HEAD(mrqueue, MemoryRegionList) MemoryRegionListHead;
#define MR_SIZE(size) (int128_nz(size) ? (hwaddr)int128_get64( \
int128_sub((size), int128_one())) : 0)
@@ -2746,7 +2746,7 @@ static void mtree_print_mr(fprintf_function mon_printf,
void *f,
bool found = false;
/* check if the alias is already in the queue */
-QTAILQ_FOREACH(ml, alias_print_queue, queue) {
+QTAILQ_FOREACH(ml, alias_print_queue, mrqueue) {
if (ml->mr == mr->alias) {
found = true;
}
@@ -2755,7 +2755,7 @@ static void mtree_print_mr(fprintf_function mon_printf,
void *f,
if (!found) {
ml = g_new(MemoryRegionList, 1);
ml->mr = mr->alias;
-QTAILQ_INSERT_TAIL(alias_print_queue, ml, queue);
+QTAILQ_INSERT_TAIL(alias_print_queue, ml, mrqueue);
}
mon_printf(f, TARGET_FMT_plx "-" TARGET_FMT_plx
" (prio %d, %s): alias %s @%s " TARGET_FMT_plx
@@ -2783,26 +2783,26 @@ static void mtree_print_mr(fprintf_function mon_printf,
void *f,
QTAILQ_FOREACH(submr, &mr->subregions, subregions_link) {
new_ml = g_new(MemoryRegionList, 1);
new_ml->mr = submr;
-QTAILQ_FOREACH(ml, &submr_print_queue, queue) {
+QTAILQ_FOREACH(ml, &submr_print_queue, mrqueue) {
if (new_ml->mr->addr < ml->mr->addr ||
(new_ml->mr->addr == ml->mr->addr &&
new_ml->mr->priority > ml->mr->priority)) {
-QTAILQ_INSERT_BEFORE(ml, new_ml, queue);
+QTAILQ_INSERT_BEFORE(ml, new_ml, mrqueue);
new_ml = NULL;
break;
}
}
if (new_ml) {
-QTAILQ_INSERT_TAIL(&submr_print_queue, new_ml, queue);
+QTAILQ_INSERT_TAIL(&submr_print_queue, new_ml, mrqueue);
}
}
-QTAILQ_FOREACH(ml, &submr_print_queue, queue) {
+QTAILQ_FOREACH(ml, &submr_print_queue, mrqueue) {
mtree_print_mr(mon_printf, f, ml->mr, level + 1, cur_start,
alias_print_queue);
}
-QTAILQ_FOREACH_SAFE(ml, &submr_print_queue, queue, next_ml) {
+QTAILQ_FOREACH_SAFE(ml, &submr_print_queue, mrqueue, next_ml) {
g_free(ml);
}
}
@@ -2872,13 +2872,13 @@ void mtree_info(fprintf_function mon_printf, void *f,
bool flatview)
}
/* print aliased regions */
-QTAILQ_FOREACH(ml, &ml_head, queue) {
+QTAILQ_FOREACH(ml, &ml_head, mrqueue) {
mon_printf(f, "memory-region: %s\n", memory_region_name(ml->mr));
mtree_print_mr(mon_printf, f, ml->mr, 1, 0, &ml_head);
mon_printf(f, "\n");
}
-QTAILQ_FOREACH_SAFE(ml, &ml_head, queue, ml2) {
+QTAILQ_FOREACH_SAFE(ml, &ml_head, mrqueue, ml2) {
g_free(ml);
}
}
--
2.14.1
[Qemu-devel] [PATCH] target/m68k: Change fpu_rom from const static array to switch
GCC 4.7.2 on SunOS reports that the values assigned to array members are not
real constants:
target/m68k/fpu_helper.c:32:5: error: initializer element is not constant
target/m68k/fpu_helper.c:32:5: error: (near initialization for 'fpu_rom[0]')
rules.mak:66: recipe for target 'target/m68k/fpu_helper.o' failed
Convert the array to switch() to workaround the issue.
This fixes build on SmartOS (Joyent).
Signed-off-by: Kamil Rytarowski
---
target/m68k/fpu_helper.c | 108 ++-
1 file changed, 78 insertions(+), 30 deletions(-)
diff --git a/target/m68k/fpu_helper.c b/target/m68k/fpu_helper.c
index bdfc537c68..13ce40db06 100644
--- a/target/m68k/fpu_helper.c
+++ b/target/m68k/fpu_helper.c
@@ -24,35 +24,6 @@
#include "exec/exec-all.h"
#include "exec/cpu_ldst.h"
-/* Undefined offsets may be different on various FPU.
- * On 68040 they return 0.0 (floatx80_zero)
- */
-
-static const floatx80 fpu_rom[128] = {
-[0x00] = floatx80_pi, /* Pi */
-[0x0b] = make_floatx80(0x3ffd, 0x9a209a84fbcff798ULL), /* Log10(2) */
-[0x0c] = make_floatx80(0x4000, 0xadf85458a2bb4a9aULL), /* e*/
-[0x0d] = make_floatx80(0x3fff, 0xb8aa3b295c17f0bcULL), /* Log2(e) */
-[0x0e] = make_floatx80(0x3ffd, 0xde5bd8a937287195ULL), /* Log10(e) */
-[0x0f] = floatx80_zero, /* Zero */
-[0x30] = floatx80_ln2, /* ln(2)*/
-[0x31] = make_floatx80(0x4000, 0x935d8dddaaa8ac17ULL), /* ln(10) */
-[0x32] = floatx80_one, /* 10^0 */
-[0x33] = make_floatx80(0x4002, 0xa000ULL), /* 10^1 */
-[0x34] = make_floatx80(0x4005, 0xc800ULL), /* 10^2 */
-[0x35] = make_floatx80(0x400c, 0x9c40ULL), /* 10^4 */
-[0x36] = make_floatx80(0x4019, 0xbebc2000ULL), /* 10^8 */
-[0x37] = make_floatx80(0x4034, 0x8e1bc9bf0400ULL), /* 10^16*/
-[0x38] = make_floatx80(0x4069, 0x9dc5ada82b70b59eULL), /* 10^32*/
-[0x39] = make_floatx80(0x40d3, 0xc2781f49ffcfa6d5ULL), /* 10^64*/
-[0x3a] = make_floatx80(0x41a8, 0x93ba47c980e98ce0ULL), /* 10^128 */
-[0x3b] = make_floatx80(0x4351, 0xaa7eebfb9df9de8eULL), /* 10^256 */
-[0x3c] = make_floatx80(0x46a3, 0xe319a0aea60e91c7ULL), /* 10^512 */
-[0x3d] = make_floatx80(0x4d48, 0xc976758681750c17ULL), /* 10^1024 */
-[0x3e] = make_floatx80(0x5a92, 0x9e8b3b5dc53d5de5ULL), /* 10^2048 */
-[0x3f] = make_floatx80(0x7525, 0xc46052028a20979bULL), /* 10^4096 */
-};
-
int32_t HELPER(reds32)(CPUM68KState *env, FPReg *val)
{
return floatx80_to_int32(val->d, &env->fp_status);
@@ -387,7 +358,84 @@ void HELPER(ftst)(CPUM68KState *env, FPReg *val)
void HELPER(fconst)(CPUM68KState *env, FPReg *val, uint32_t offset)
{
-val->d = fpu_rom[offset];
+floatx80 tmp;
+
+/* Undefined offsets may be different on various FPU.
+ * On 68040 they return 0.0 (floatx80_zero)
+ */
+switch (offset) {
+case 0x00:
+tmp = floatx80_pi; /* Pi */
+break;
+case 0x0b:
+tmp = make_floatx80(0x3ffd, 0x9a209a84fbcff798ULL); /* Log10(2) */
+break;
+case 0x0c:
+tmp = make_floatx80(0x4000, 0xadf85458a2bb4a9aULL); /* e*/
+break;
+case 0x0d:
+tmp = make_floatx80(0x3fff, 0xb8aa3b295c17f0bcULL); /* Log2(e) */
+break;
+case 0x0e:
+tmp = make_floatx80(0x3ffd, 0xde5bd8a937287195ULL); /* Log10(e) */
+break;
+case 0x0f:
+tmp = floatx80_zero; /* Zero */
+break;
+case 0x30:
+tmp = floatx80_ln2; /* ln(2)*/
+break;
+case 0x31:
+tmp = make_floatx80(0x4000, 0x935d8dddaaa8ac17ULL); /* ln(10) */
+break;
+case 0x32:
+tmp = floatx80_one; /* 10^0 */
+break;
+case 0x33:
+tmp = make_floatx80(0x4002, 0xa000ULL); /* 10^1 */
+break;
+case 0x34:
+tmp = make_floatx80(0x4005, 0xc800ULL); /* 10^2 */
+break;
+case 0x35:
+tmp = make_floatx80(0x400c, 0x9c40ULL); /* 10^4 */
+break;
+case 0x36:
+tmp = make_floatx80(0x4019, 0xbebc2000ULL); /* 10^8 */
+break;
+case 0x37:
+tmp = make_floatx80(0x4034, 0x8e1bc9bf0400ULL); /* 10^16*/
+break;
+case 0x38:
+tmp = make_floatx80(0x4069, 0x9dc5ada82b70b59eULL); /* 10^32*/
+break;
+case 0x39:
+tmp = make_floatx80(0x40d3, 0xc2781f49ffcfa6d5ULL); /* 10^64*/
+break;
+case 0x3a:
+tmp = make_floatx80(0x41a8, 0x93ba47c980e98ce0ULL); /* 10^128 */
+break;
+case 0x3b:
+tmp = make_floatx80(0x4351, 0xaa7eebfb9df9
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Just saw your last message. Will wait for Paolo's response. On Sun, Sep 3, 2017 at 11:33 AM, Sergio Andrés Gómez del Real < sergio.g.delr...@gmail.com> wrote: > Izik, sorry for the late response. Tell me if you have any further issue. > What are the 2 functions that couldn't be relicensed? > > Stefan, as soon as relicensing is available I'll send v3 of the patchset. > > On Sun, Sep 3, 2017 at 8:00 AM, Izik Eidus wrote: > >> >> >> On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini >> wrote: >> >>> Il 01 set 2017 7:59 PM, "Izik Eidus" ha scritto: >>> >>> Hi, >>> >>> Sergio, I was trying to applying patch 1/13 and 2/13 and then I ran: >>> ./configure and saw: 'HVF support yes' >>> after that 'make' was happy >>> and: >>> >>> ./x86_64-softmmu/qemu-system-x86_64 --help | grep accel >>> >>> \property accel=accel1[:accel2[:...]] selects accelerator >>> >>> supported accelerators are kvm, xen, hax, hvf or tcg >>> (default: tcg) >>> >>> kernel_irqchip=on|off|split controls accelerated irqchip >>> support (default=off) >>> >>> >>> however: >>> >>> ./x86_64-softmmu/qemu-system-x86_64 -cdrom >>> /Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine >>> q35,accel=hvf >>> >>> qemu-system-x86_64: -machine accel=hvf: No accelerator found >>> >>> >>> What am I doing wrong? >>> >>> >>> Try applying patch 3 too. Most of the early patches will end up squashed. >>> >> >> Yea that did the magic, now I have compilation errors but from here I >> will take it, and just fix the compilation step for each patch and resend. >> >> >>> >>> Paolo >>> >>> >>> Thanks. >>> >>> >>> >>> >>> On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real < >>> sergio.g.delr...@gmail.com> wrote: >>> >>> > Hello, >>> > Mr. Frank Yang was the guy at Google that introduced the HVF port to >>> > Google's Android Emulator QEMU branch. >>> > Frank, in this thread we are discussing the licensing issue with the >>> HVF >>> > files (their being GPL v2-only). Paolo from Red Hat was asking to >>> Veertu >>> > developer Izik Eidus if the code in Veertu derived only from QEMU, >>> Bochs >>> > and other GPLv2+ or LGPL software. Because the code at Google was >>> itself >>> > derived from Veertu, I'd imagine the same licensing terms would apply >>> in >>> > your case. Any light you can throw over this issue would be much >>> > appreciated. >>> > >>> > Thank you. >>> > >>> > On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini >>> > wrote: >>> > >>> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: >>> >> >>> >> > Izik, Vincent (assuming you are the right person to contact at >>> Google), >>> >> > can you reply to Daniel and Stefan? >>> >> > >>> >> >>> >> Hi, >>> >> >>> >> What I suggest is that we will send our patch' again as gpl2+ and >>> clean >>> >> the >>> >> entire stuff to make sure they are falling into the right copyright >>> >> category as required by QEMU. >>> >> >>> >> >>> >> That's not necessary. Just you and Vincent replying to this thread >>> with a >>> >> "Signed-off-by" line would be enough for Sergio to use the right >>> license in >>> >> his v3 submission. Sergio already made some non-trivial changes that >>> are >>> >> needed for inclusion in QEMU from a supportability (e.g. dirty page >>> >> tracking for graphics) or maintainability perspective (e.g. -cpu >>> support), >>> >> so the simplest thing to do is to retrofit the right license to his >>> >> submission. You can do so if you can confirm that the code you used >>> only >>> >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the >>> rest >>> >> was written by Veertu). >>> >> >>> >> Google has already contributed the HAXN accelerator, so I am >>> moderately >>> >> optimistic that they can help with HVF too. >>> >> >>> >> BTW, another thing that need to be integrated in order to make this >>> stuff >>> >> useful is the vmnet patch's, it is apple NAT for vms that allow >>> guests to >>> >> have networking... >>> >> >>> >> >>> >> People can always use slirp (or tap with some more effort), so these >>> >> patches are already a minimum viable feature and pretty close to being >>> >> mergeable. But of course any other contribution is welcome! >>> >> >>> >> Paolo >>> >> >>> >> >>> >> (altho that it come with a trick, without certificate it >>> >> will require root permission, while hypverisor framework itself can >>> run >>> >> without root) >>> >> >>> >> What do you guys think? >>> >> >>> >> >>> >> > >>> >> > Sergio worked on completing the QEMU port to Hypervisor.framework. >>> The >>> >> > hvf-all.c file that Daniel pointed out as v2-only is derived from >>> >> kvm-all.c >>> >> > and hax-all.c, and should be under v2-or-later license. The others >>> seem >>> >> to >>> >> > be either original or derived from Bochs, which is LGPL, so they >>> could >>> >> be >>> >> > LGPL or GPLv2+. >>> >> > >>> >> > Thanks, >>> >> > >>> >> > Paolo >>> >> > >>> >> > >>> >> > There are benefits to having this code upstream. If they
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Il 03 set 2017 6:17 PM, "Izik Eidus" ha scritto: Hi, Paolo, my biggest challenge right now is: hvf-all.c it include currently the following copyright: // Copyright 2008 IBM Corporation // 2008 Red Hat, Inc. // Copyright 2011 Intel Corporation // Copyright 2016 Veertu, Inc. // Copyright 2017 The Android Open Source Project and it is GPLv2, However we want to integrate this stuff to QEMU in the required license (GPLv2+), I have a suggestion that maybe the safest way for us to achieve GPLv2+ would be that we will send you the current hypervisor framework implementation of Anka that is derived from xhyve/bhyve + our own changes to make it run windows / linux / macOS, What code is derived from v2-only sources? IIRC the task switch code is derived from KVM, is there anything else? 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? Paolo in such case all copyright go back to BSD2 and we can license it as GPL2v+ or whatever work for QEMU. If you want to go in such case what we will do would be the following: take kvm user space implemantion of qemu that is GPLv2+, integrate to it the hypervisor framework from Anka (in kvm user space style) - this will put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the rest of Sergio changes to this stuff. I know this is less than ideal as it requires some changes to the current patch set, however it will make it 100% safe to be GPL2v+, what you guys think?, we can get this stuff done before the end of this week... Thanks. On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus wrote: > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > wrote: > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: >> >> > Izik, Vincent (assuming you are the right person to contact at Google), >> > can you reply to Daniel and Stefan? >> > >> >> Hi, >> >> What I suggest is that we will send our patch' again as gpl2+ and clean >> the >> entire stuff to make sure they are falling into the right copyright >> category as required by QEMU. >> >> >> That's not necessary. Just you and Vincent replying to this thread with a >> "Signed-off-by" line would be enough for Sergio to use the right license in >> his v3 submission. Sergio already made some non-trivial changes that are >> needed for inclusion in QEMU from a supportability (e.g. dirty page >> tracking for graphics) or maintainability perspective (e.g. -cpu support), >> so the simplest thing to do is to retrofit the right license to his >> submission. You can do so if you can confirm that the code you used only >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest >> was written by Veertu). >> > > Hi, > > Sure fine with us, let me go over all the code and see that all 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 wil
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Izik, sorry for the late response. Tell me if you have any further issue. What are the 2 functions that couldn't be relicensed? Stefan, as soon as relicensing is available I'll send v3 of the patchset. On Sun, Sep 3, 2017 at 8:00 AM, Izik Eidus wrote: > > > On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini wrote: > >> Il 01 set 2017 7:59 PM, "Izik Eidus" ha scritto: >> >> Hi, >> >> Sergio, I was trying to applying patch 1/13 and 2/13 and then I ran: >> ./configure and saw: 'HVF support yes' >> after that 'make' was happy >> and: >> >> ./x86_64-softmmu/qemu-system-x86_64 --help | grep accel >> >> \property accel=accel1[:accel2[:...]] selects accelerator >> >> supported accelerators are kvm, xen, hax, hvf or tcg >> (default: tcg) >> >> kernel_irqchip=on|off|split controls accelerated irqchip >> support (default=off) >> >> >> however: >> >> ./x86_64-softmmu/qemu-system-x86_64 -cdrom >> /Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine >> q35,accel=hvf >> >> qemu-system-x86_64: -machine accel=hvf: No accelerator found >> >> >> What am I doing wrong? >> >> >> Try applying patch 3 too. Most of the early patches will end up squashed. >> > > Yea that did the magic, now I have compilation errors but from here I will > take it, and just fix the compilation step for each patch and resend. > > >> >> Paolo >> >> >> Thanks. >> >> >> >> >> On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real < >> sergio.g.delr...@gmail.com> wrote: >> >> > Hello, >> > Mr. Frank Yang was the guy at Google that introduced the HVF port to >> > Google's Android Emulator QEMU branch. >> > Frank, in this thread we are discussing the licensing issue with the HVF >> > files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu >> > developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs >> > and other GPLv2+ or LGPL software. Because the code at Google was itself >> > derived from Veertu, I'd imagine the same licensing terms would apply in >> > your case. Any light you can throw over this issue would be much >> > appreciated. >> > >> > Thank you. >> > >> > On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini >> > wrote: >> > >> >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: >> >> >> >> > Izik, Vincent (assuming you are the right person to contact at >> Google), >> >> > can you reply to Daniel and Stefan? >> >> > >> >> >> >> Hi, >> >> >> >> What I suggest is that we will send our patch' again as gpl2+ and clean >> >> the >> >> entire stuff to make sure they are falling into the right copyright >> >> category as required by QEMU. >> >> >> >> >> >> That's not necessary. Just you and Vincent replying to this thread >> with a >> >> "Signed-off-by" line would be enough for Sergio to use the right >> license in >> >> his v3 submission. Sergio already made some non-trivial changes that >> are >> >> needed for inclusion in QEMU from a supportability (e.g. dirty page >> >> tracking for graphics) or maintainability perspective (e.g. -cpu >> support), >> >> so the simplest thing to do is to retrofit the right license to his >> >> submission. You can do so if you can confirm that the code you used >> only >> >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the >> rest >> >> was written by Veertu). >> >> >> >> Google has already contributed the HAXN accelerator, so I am moderately >> >> optimistic that they can help with HVF too. >> >> >> >> BTW, another thing that need to be integrated in order to make this >> stuff >> >> useful is the vmnet patch's, it is apple NAT for vms that allow guests >> to >> >> have networking... >> >> >> >> >> >> People can always use slirp (or tap with some more effort), so these >> >> patches are already a minimum viable feature and pretty close to being >> >> mergeable. But of course any other contribution is welcome! >> >> >> >> Paolo >> >> >> >> >> >> (altho that it come with a trick, without certificate it >> >> will require root permission, while hypverisor framework itself can run >> >> without root) >> >> >> >> What do you guys think? >> >> >> >> >> >> > >> >> > Sergio worked on completing the QEMU port to Hypervisor.framework. >> The >> >> > hvf-all.c file that Daniel pointed out as v2-only is derived from >> >> kvm-all.c >> >> > and hax-all.c, and should be under v2-or-later license. The others >> seem >> >> to >> >> > be either original or derived from Bochs, which is LGPL, so they >> could >> >> be >> >> > LGPL or GPLv2+. >> >> > >> >> > Thanks, >> >> > >> >> > Paolo >> >> > >> >> > >> >> > There are benefits to having this code upstream. If they ever want >> to >> >> > rebase on qemu.git there will be less work for them. >> >> > >> >> > Stefan >> >> > >> >> > >> >> > >> >> >> >> >> >> >> > >> >> >> >
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
Hi, Paolo, my biggest challenge right now is: hvf-all.c it include currently the following copyright: // Copyright 2008 IBM Corporation // 2008 Red Hat, Inc. // Copyright 2011 Intel Corporation // Copyright 2016 Veertu, Inc. // Copyright 2017 The Android Open Source Project and it is GPLv2, However we want to integrate this stuff to QEMU in the required license (GPLv2+), I have a suggestion that maybe the safest way for us to achieve GPLv2+ would be that we will send you the current hypervisor framework implementation of Anka that is derived from xhyve/bhyve + our own changes to make it run windows / linux / macOS, in such case all copyright go back to BSD2 and we can license it as GPL2v+ or whatever work for QEMU. If you want to go in such case what we will do would be the following: take kvm user space implemantion of qemu that is GPLv2+, integrate to it the hypervisor framework from Anka (in kvm user space style) - this will put us in hvf [1|2|3 / 13] in safe GPLv2+ and then we can back port the rest of Sergio changes to this stuff. I know this is less than ideal as it requires some changes to the current patch set, however it will make it 100% safe to be GPL2v+, what you guys think?, we can get this stuff done before the end of this week... Thanks. On Fri, Sep 1, 2017 at 12:39 AM, Izik Eidus wrote: > > > On Fri, Sep 1, 2017 at 12:21 AM, Paolo Bonzini > wrote: > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: >> >> > Izik, Vincent (assuming you are the right person to contact at Google), >> > can you reply to Daniel and Stefan? >> > >> >> Hi, >> >> What I suggest is that we will send our patch' again as gpl2+ and clean >> the >> entire stuff to make sure they are falling into the right copyright >> category as required by QEMU. >> >> >> That's not necessary. Just you and Vincent replying to this thread with a >> "Signed-off-by" line would be enough for Sergio to use the right license in >> his v3 submission. Sergio already made some non-trivial changes that are >> needed for inclusion in QEMU from a supportability (e.g. dirty page >> tracking for graphics) or maintainability perspective (e.g. -cpu support), >> so the simplest thing to do is to retrofit the right license to his >> submission. You can do so if you can confirm that the code you used only >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest >> was written by Veertu). >> > > Hi, > > Sure fine with us, let me go over all the code and see that all copyright > that are needed are there, and then you can relicense all our code to > GPLv2+, I think I saw a a file that was missing Bochs copyright in it, so I > want to make sure that I fix this before and that all others are fine. > > Thanks. > > >> >> Google has already contributed the HAXN accelerator, so I am moderately >> optimistic that they can help with HVF too. >> >> BTW, another thing that need to be integrated in order to make this stuff >> useful is the vmnet patch's, it is apple NAT for vms that allow guests to >> have networking... >> >> >> People can always use slirp (or tap with some more effort), so these >> patches are already a minimum viable feature and pretty close to being >> mergeable. But of course any other contribution is welcome! >> >> Paolo >> >> >> (altho that it come with a trick, without certificate it >> will require root permission, while hypverisor framework itself can run >> without root) >> >> What do you guys think? >> >> >> > >> > Sergio worked on completing the QEMU port to Hypervisor.framework. The >> > hvf-all.c file that Daniel pointed out as v2-only is derived from >> kvm-all.c >> > and hax-all.c, and should be under v2-or-later license. The others seem >> to >> > be either original or derived from Bochs, which is LGPL, so they could >> be >> > LGPL or GPLv2+. >> > >> > Thanks, >> > >> > Paolo >> > >> > >> > There are benefits to having this code upstream. If they ever want to >> > rebase on qemu.git there will be less work for them. >> >> OK, > > >> > Stefan >> > >> > >> > >> >> >> >
Re: [Qemu-devel] [PATCH v2 02/13] hvf: add code base from Google's QEMU repository
On Sun, Sep 3, 2017 at 9:23 AM, Paolo Bonzini wrote: > Il 01 set 2017 7:59 PM, "Izik Eidus" ha scritto: > > Hi, > > Sergio, I was trying to applying patch 1/13 and 2/13 and then I ran: > ./configure and saw: 'HVF support yes' > after that 'make' was happy > and: > > ./x86_64-softmmu/qemu-system-x86_64 --help | grep accel > > \property accel=accel1[:accel2[:...]] selects accelerator > > supported accelerators are kvm, xen, hax, hvf or tcg > (default: tcg) > > kernel_irqchip=on|off|split controls accelerated irqchip > support (default=off) > > > however: > > ./x86_64-softmmu/qemu-system-x86_64 -cdrom > /Users/izik/Downloads/ubuntu-16.04.3-desktop-amd64.iso -machine > q35,accel=hvf > > qemu-system-x86_64: -machine accel=hvf: No accelerator found > > > What am I doing wrong? > > > Try applying patch 3 too. Most of the early patches will end up squashed. > Yea that did the magic, now I have compilation errors but from here I will take it, and just fix the compilation step for each patch and resend. > > Paolo > > > Thanks. > > > > > On Fri, Sep 1, 2017 at 12:41 AM, Sergio Andrés Gómez del Real < > sergio.g.delr...@gmail.com> wrote: > > > Hello, > > Mr. Frank Yang was the guy at Google that introduced the HVF port to > > Google's Android Emulator QEMU branch. > > Frank, in this thread we are discussing the licensing issue with the HVF > > files (their being GPL v2-only). Paolo from Red Hat was asking to Veertu > > developer Izik Eidus if the code in Veertu derived only from QEMU, Bochs > > and other GPLv2+ or LGPL software. Because the code at Google was itself > > derived from Veertu, I'd imagine the same licensing terms would apply in > > your case. Any light you can throw over this issue would be much > > appreciated. > > > > Thank you. > > > > On Thu, Aug 31, 2017 at 4:21 PM, Paolo Bonzini > > wrote: > > > >> Il 31 ago 2017 3:54 PM, "Izik Eidus" ha scritto: > >> > >> > Izik, Vincent (assuming you are the right person to contact at > Google), > >> > can you reply to Daniel and Stefan? > >> > > >> > >> Hi, > >> > >> What I suggest is that we will send our patch' again as gpl2+ and clean > >> the > >> entire stuff to make sure they are falling into the right copyright > >> category as required by QEMU. > >> > >> > >> That's not necessary. Just you and Vincent replying to this thread with > a > >> "Signed-off-by" line would be enough for Sergio to use the right > license in > >> his v3 submission. Sergio already made some non-trivial changes that are > >> needed for inclusion in QEMU from a supportability (e.g. dirty page > >> tracking for graphics) or maintainability perspective (e.g. -cpu > support), > >> so the simplest thing to do is to retrofit the right license to his > >> submission. You can do so if you can confirm that the code you used only > >> came from QEMU itself, Bochs or other GPLv2+/LGPL software (and the rest > >> was written by Veertu). > >> > >> Google has already contributed the HAXN accelerator, so I am moderately > >> optimistic that they can help with HVF too. > >> > >> BTW, another thing that need to be integrated in order to make this > stuff > >> useful is the vmnet patch's, it is apple NAT for vms that allow guests > to > >> have networking... > >> > >> > >> People can always use slirp (or tap with some more effort), so these > >> patches are already a minimum viable feature and pretty close to being > >> mergeable. But of course any other contribution is welcome! > >> > >> Paolo > >> > >> > >> (altho that it come with a trick, without certificate it > >> will require root permission, while hypverisor framework itself can run > >> without root) > >> > >> What do you guys think? > >> > >> > >> > > >> > Sergio worked on completing the QEMU port to Hypervisor.framework. The > >> > hvf-all.c file that Daniel pointed out as v2-only is derived from > >> kvm-all.c > >> > and hax-all.c, and should be under v2-or-later license. The others > seem > >> to > >> > be either original or derived from Bochs, which is LGPL, so they could > >> be > >> > LGPL or GPLv2+. > >> > > >> > Thanks, > >> > > >> > Paolo > >> > > >> > > >> > There are benefits to having this code upstream. If they ever want to > >> > rebase on qemu.git there will be less work for them. > >> > > >> > Stefan > >> > > >> > > >> > > >> > >> > >> > > > > >
[Qemu-devel] [Bug 1714750] [NEW] 2.10.0 cannot be installed on case-insensitive file system
Public bug reported: The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be unpacked on a case-insensitive file system because it has a file qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on most macOS systems since by default the file system is case insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This is a regression from 2.9.0, which didn't have this problem. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1714750 Title: 2.10.0 cannot be installed on case-insensitive file system Status in QEMU: New Bug description: The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be unpacked on a case-insensitive file system because it has a file qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on most macOS systems since by default the file system is case insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This is a regression from 2.9.0, which didn't have this problem. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1714750/+subscriptions
