On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014 11:12, Greg Kurz ha scritto:
int virtio_load(VirtIODevice *vdev, QEMUFile *f)
{
[...]
nheads = vring_avail_idx(vdev-vq[i]) -
vdev-vq[i].last_avail_idx;
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014 11:12, Greg Kurz ha scritto:
int virtio_load(VirtIODevice *vdev, QEMUFile *f)
{
[...]
nheads =
On Thu, 12 Jun 2014 10:54:48 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014 11:12, Greg Kurz ha scritto:
int virtio_load(VirtIODevice
On 12.06.14 09:54, Michael S. Tsirkin wrote:
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014 11:12, Greg Kurz ha scritto:
int virtio_load(VirtIODevice *vdev, QEMUFile *f)
{
[...]
Il 12/06/2014 09:43, Greg Kurz ha scritto:
Since we know that 0 max_nr_ports 32, is it acceptable to guess
the correct endianness with a heuristic ?
if (max_nr_ports tswap32(s-config.max_nr_ports)) {
max_nr_ports = bswap32(max_nr_ports);
}
if (max_nr_ports
On 12.06.14 10:55, Paolo Bonzini wrote:
Il 12/06/2014 09:43, Greg Kurz ha scritto:
Since we know that 0 max_nr_ports 32, is it acceptable to guess
the correct endianness with a heuristic ?
if (max_nr_ports tswap32(s-config.max_nr_ports)) {
max_nr_ports = bswap32(max_nr_ports);
}
if
On Thu, Jun 12, 2014 at 10:47:17AM +0200, Greg Kurz wrote:
On Thu, 12 Jun 2014 10:54:48 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014
On 12.06.14 10:47, Greg Kurz wrote:
On Thu, 12 Jun 2014 10:54:48 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014 11:12, Greg Kurz ha scritto:
On Thu, 12 Jun 2014 10:55:42 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 12/06/2014 09:43, Greg Kurz ha scritto:
Since we know that 0 max_nr_ports 32, is it acceptable to guess
the correct endianness with a heuristic ?
if (max_nr_ports tswap32(s-config.max_nr_ports)) {
On Thu, Jun 12, 2014 at 10:55:40AM +0200, Alexander Graf wrote:
On 12.06.14 09:54, Michael S. Tsirkin wrote:
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/05/2014 11:12, Greg Kurz ha scritto:
int
On 12.06.14 11:07, Michael S. Tsirkin wrote:
On Thu, Jun 12, 2014 at 10:55:40AM +0200, Alexander Graf wrote:
On 12.06.14 09:54, Michael S. Tsirkin wrote:
On Thu, Jun 12, 2014 at 09:43:51AM +0200, Greg Kurz wrote:
On Thu, 29 May 2014 12:16:26 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il
Il 12/06/2014 11:06, Greg Kurz ha scritto:
On Thu, 12 Jun 2014 10:55:42 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 12/06/2014 09:43, Greg Kurz ha scritto:
Since we know that 0 max_nr_ports 32, is it acceptable to guess
the correct endianness with a heuristic ?
if (max_nr_ports
On Thu, Jun 12, 2014 at 11:19:47AM +0200, Paolo Bonzini wrote:
Il 12/06/2014 11:06, Greg Kurz ha scritto:
On Thu, 12 Jun 2014 10:55:42 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 12/06/2014 09:43, Greg Kurz ha scritto:
Since we know that 0 max_nr_ports 32, is it acceptable to guess
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine types?
Then we won't need hacks to migrate it.
For any machine type it's trivial to migrate it. All machine types
including old ones can disregard the migrated values.
Paolo
On 12.06.14 11:39, Paolo Bonzini wrote:
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine types?
Then we won't need hacks to migrate it.
For any machine type it's trivial to migrate it. All machine types
including old ones can disregard
On Thu, 12 Jun 2014 11:43:20 +0200
Alexander Graf ag...@suse.de wrote:
On 12.06.14 11:39, Paolo Bonzini wrote:
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine types?
Then we won't need hacks to migrate it.
For any machine type
Am 12.06.2014 um 12:14 schrieb Greg Kurz gk...@linux.vnet.ibm.com:
On Thu, 12 Jun 2014 11:43:20 +0200
Alexander Graf ag...@suse.de wrote:
On 12.06.14 11:39, Paolo Bonzini wrote:
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine
On Thu, 12 Jun 2014 12:39:27 +0200
Alexander Graf ag...@suse.de wrote:
Am 12.06.2014 um 12:14 schrieb Greg Kurz gk...@linux.vnet.ibm.com:
On Thu, 12 Jun 2014 11:43:20 +0200
Alexander Graf ag...@suse.de wrote:
On 12.06.14 11:39, Paolo Bonzini wrote:
Il 12/06/2014 11:37,
On Thu, Jun 12, 2014 at 11:39:42AM +0200, Paolo Bonzini wrote:
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine types?
Then we won't need hacks to migrate it.
For any machine type it's trivial to migrate it. All machine types
including
On Thu, Jun 12, 2014 at 11:43:20AM +0200, Alexander Graf wrote:
On 12.06.14 11:39, Paolo Bonzini wrote:
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine types?
Then we won't need hacks to migrate it.
For any machine type it's trivial to
On Thu, Jun 12, 2014 at 12:14:40PM +0200, Greg Kurz wrote:
On Thu, 12 Jun 2014 11:43:20 +0200
Alexander Graf ag...@suse.de wrote:
On 12.06.14 11:39, Paolo Bonzini wrote:
Il 12/06/2014 11:37, Michael S. Tsirkin ha scritto:
Maybe just drop unnecessary stuff for new machine types?
Am 12.06.2014 um 12:50 schrieb Greg Kurz gk...@linux.vnet.ibm.com:
On Thu, 12 Jun 2014 12:39:27 +0200
Alexander Graf ag...@suse.de wrote:
Am 12.06.2014 um 12:14 schrieb Greg Kurz gk...@linux.vnet.ibm.com:
On Thu, 12 Jun 2014 11:43:20 +0200
Alexander Graf ag...@suse.de wrote:
On Thu, Jun 12, 2014 at 12:50:56PM +0200, Greg Kurz wrote:
On Thu, 12 Jun 2014 12:39:27 +0200
Alexander Graf ag...@suse.de wrote:
Am 12.06.2014 um 12:14 schrieb Greg Kurz gk...@linux.vnet.ibm.com:
On Thu, 12 Jun 2014 11:43:20 +0200
Alexander Graf ag...@suse.de wrote:
On Thu, 12 Jun 2014 13:59:59 +0300
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jun 12, 2014 at 12:50:56PM +0200, Greg Kurz wrote:
On Thu, 12 Jun 2014 12:39:27 +0200
Alexander Graf ag...@suse.de wrote:
Am 12.06.2014 um 12:14 schrieb Greg Kurz gk...@linux.vnet.ibm.com:
On Tue, 27 May 2014 17:01:38 +0200
Paolo Bonzini pbonz...@redhat.com wrote:
Il 14/05/2014 17:42, Greg Kurz ha scritto:
+{ .name = virtio/is_big_endian,
+ .version_id = 1,
+ .save = virtio_save_device_endian,
+ .load = virtio_load_device_endian,
+},
{ .name
Il 29/05/2014 11:12, Greg Kurz ha scritto:
int virtio_load(VirtIODevice *vdev, QEMUFile *f)
{
[...]
nheads = vring_avail_idx(vdev-vq[i]) - vdev-vq[i].last_avail_idx;
^^^
/* Check it isn't doing very strange things with descriptor
numbers.
Il 14/05/2014 17:42, Greg Kurz ha scritto:
+{ .name = virtio/is_big_endian,
+ .version_id = 1,
+ .save = virtio_save_device_endian,
+ .load = virtio_load_device_endian,
+},
{ .name = NULL }
I think this is okay, but you need to add support for a needed
function
Some CPU families can dynamically change their endianness. This means we
can have little endian ppc or big endian arm guests for example. This has
an impact on legacy virtio data structures since they are target endian.
We hence introduce a new property to track the endianness of each virtio
On Mon, 19 May 2014 10:39:09 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
Some CPU families can dynamically change their endianness. This means we
can have little endian ppc or big endian arm guests for example. This has
an impact on legacy virtio data structures since they are target
Am 19.05.2014 15:06, schrieb Greg Kurz:
On Mon, 19 May 2014 10:39:09 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 7fbad29..6578854 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
[...]
@@ -839,10 +849,39 @@ typedef
On Mon, 19 May 2014 19:06:39 +0200
Andreas Färber afaer...@suse.de wrote:
Am 19.05.2014 15:06, schrieb Greg Kurz:
On Mon, 19 May 2014 10:39:09 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 7fbad29..6578854 100644
---
* Andreas F?rber (afaer...@suse.de) wrote:
Am 19.05.2014 15:06, schrieb Greg Kurz:
On Mon, 19 May 2014 10:39:09 +0200
Greg Kurz gk...@linux.vnet.ibm.com wrote:
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 7fbad29..6578854 100644
--- a/hw/virtio/virtio.c
+++
Some CPU families can dynamically change their endianness. This means we
can have little endian ppc or big endian arm guests for example. This has
an impact on legacy virtio data structures since they are target endian.
We hence introduce a new property to track the endianness of each virtio
33 matches
Mail list logo
