On 04/12/2012 15:49, Peter Maydell wrote:
On 4 December 2012 14:35, wrote:
From: KONRAD Frederic
Create the virtio-pci device. This transport device will create a
virtio-pci-bus, so one VirtIODevice can be connected.
Signed-off-by: KONRAD Frederic
---
hw/virtio-pci.c | 112 ++
On 04/12/2012 15:55, Peter Maydell wrote:
On 4 December 2012 14:35, wrote:
From: KONRAD Frederic
Create the virtio-device which is abstract. All the virtio-device can extend
this class.
Signed-off-by: KONRAD Frederic
---
hw/virtio.c | 56 ++
On 05/12/2012 17:25, Peter Maydell wrote:
On 4 December 2012 14:35, wrote:
From: KONRAD Frederic
Create virtio-blk which extends virtio-device, so it can be connected on
virtio-bus.
Signed-off-by: KONRAD Frederic
---
hw/virtio-blk.c | 170 -
On 05/12/2012 18:22, Andreas Färber wrote:
Am 05.12.2012 17:25, schrieb Peter Maydell:
On 4 December 2012 14:35, wrote:
From: KONRAD Frederic
Create virtio-blk which extends virtio-device, so it can be connected on
virtio-bus.
Signed-off-by: KONRAD Frederic
---
hw/virtio-blk.c | 170 +++
On 06/12/2012 10:18, Andreas Färber wrote:
Am 06.12.2012 10:11, schrieb KONRAD Frédéric:
On 05/12/2012 17:25, Peter Maydell wrote:
On 4 December 2012 14:35, wrote:
-static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
-{
-return (VirtIOBlock *)vdev;
-}
+/*
+ * Use the QOM cast, so we
On 06/12/2012 10:53, Andreas Färber wrote:
Am 06.12.2012 10:21, schrieb KONRAD Frédéric:
On 05/12/2012 18:22, Andreas Färber wrote:
Am 05.12.2012 17:25, schrieb Peter Maydell:
On 4 December 2012 14:35, wrote:
From: KONRAD Frederic
Create virtio-blk which extends virtio-device, so it can
On 06/12/2012 11:13, Peter Maydell wrote:
On 6 December 2012 09:53, Andreas Färber wrote:
Am 06.12.2012 10:21, schrieb KONRAD Frédéric:
I agree with that, but, there is an issue :
The refactored VirtIOBlk is a device and seems to work, but the device
which use this VirtIOBlock
(eg virtio-blk
On 06/12/2012 15:21, Peter Maydell wrote:
On 6 December 2012 13:58, KONRAD Frédéric wrote:
On 06/12/2012 11:13, Peter Maydell wrote:
It can't just be a command line alias, or we will break migration.
It has to be a simple device that composes together the virtio-pci
and virtio-blk de
On 12/12/2012 15:25, Peter Maydell wrote:
On 10 December 2012 16:45, wrote:
-static void virtio_blk_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-k->init = virtio_blk_init_pci;
-k->exit = v
On 11/12/2012 18:50, Peter Maydell wrote:
On 10 December 2012 16:45, wrote:
From: KONRAD Frederic
Here the virtio-blk-pci is modified for the new API. The device virtio-pci-blk
extends virtio-pci. It creates and connects a virtio-blk during the init.
Did you check whether this maintains bac
On 12/12/2012 18:58, Peter Maydell wrote:
On 12 December 2012 17:53, Andreas Färber wrote:
Am 12.12.2012 15:25, schrieb Peter Maydell:
How will the PCI transport's PCI vendor/device/class IDs be
set (a) when a virtio-blk backend is created and separately
plugged into a virtio-pci transport (b)
On 13/12/2012 09:24, KONRAD Frédéric wrote:
On 12/12/2012 15:25, Peter Maydell wrote:
On 10 December 2012 16:45, wrote:
-static void virtio_blk_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-k
On 17/12/2012 16:45, Michael S. Tsirkin wrote:
On Fri, Dec 07, 2012 at 02:32:29PM +0100, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
You can clone that from here :
git.greensocs.com/home/greensocs/git/qemu_virtio.git virtio_refactoring_v6
The problem with the last RFC v5 was that v
On 18/12/2012 12:01, Michael S. Tsirkin wrote:
On Tue, Dec 18, 2012 at 10:33:37AM +, Peter Maydell wrote:
On 17 December 2012 15:45, Michael S. Tsirkin wrote:
Is the point to allow virtio-mmio? Why can't virtio-mmio be just
another bus, like a pci bus, and another binding, like the virtio
On 19/12/2012 20:50, Blue Swirl wrote:
On Wed, Dec 19, 2012 at 9:53 AM, wrote:
From: KONRAD Frederic
This remove the function pointer in VirtIODevice, and use only
VirtioDeviceClass function pointer. It should be applied after all
the device have been refactored.
Signed-off-by: KONRAD Frede
On 19/12/2012 19:09, Cornelia Huck wrote:
On Wed, 19 Dec 2012 10:53:32 +0100
fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
Introduce virtio-s390-bus, which extends virtio-bus. It is used with s390
transport device.
Signed-off-by: KONRAD Frederic
---
hw/s390-virtio-bus.c | 28
On 02/01/2013 15:14, Anthony Liguori wrote:
fred.kon...@greensocs.com writes:
From: KONRAD Frederic
Create the virtio-pci device. This transport device will create a
virtio-pci-bus, so one VirtIODevice can be connected.
Signed-off-by: KONRAD Frederic
---
hw/virtio-pci.c | 130
On 02/01/2013 15:16, Andreas Färber wrote:
Am 02.01.2013 15:08, schrieb Anthony Liguori:
fred.kon...@greensocs.com writes:
From: KONRAD Frederic
Add a max_dev field to BusState to specify the maximum amount of devices allowed
on the bus ( have no effect if max_dev=0 )
Signed-off-by: KONRAD
On 02/01/2013 15:12, Anthony Liguori wrote:
fred.kon...@greensocs.com writes:
From: KONRAD Frederic
Introduce virtio-bus. Refactored transport device will create a bus which
extends virtio-bus.
Signed-off-by: KONRAD Frederic
---
hw/Makefile.objs | 1 +
hw/virtio-bus.c | 169 ++
On 02/01/2013 15:08, Anthony Liguori wrote:
fred.kon...@greensocs.com writes:
From: KONRAD Frederic
Add a max_dev field to BusState to specify the maximum amount of devices allowed
on the bus ( have no effect if max_dev=0 )
Signed-off-by: KONRAD Frederic
---
hw/qdev-core.h| 2 ++
hw
On 24/01/2013 16:43, Peter Maydell wrote:
Implement support for using the KVM in-kernel GIC for ARM.
Signed-off-by: Peter Maydell
---
hw/a15mpcore.c |8 ++-
hw/arm/Makefile.objs |1 +
hw/kvm/arm_gic.c | 169 ++
3 files chan
On 31/01/2013 14:23, Laszlo Ersek wrote:
Hi,
I'm working on propagating errors out to do_device_add(). I've come
accross qbus_find_recursive().
Re commit 1395af6f ("qdev: add a maximum device allowed field for the
bus."), could someone please explain:
(1) why the early termination due to max_i
On 31/01/2013 16:52, Peter Maydell wrote:
On 31 January 2013 15:42, Laszlo Ersek wrote:
The bus we're looking for could be in the sub-tree rooted at the node
being checked; don't skip looping over the children.
Signed-off-by: Laszlo Ersek
---
hw/qdev-monitor.c | 10 +
1 files cha
On 06/02/2013 00:47, Jesse Larrew wrote:
From: Anthony Liguori
Signed-off-by: Anthony Liguori
---
hw/s390x/s390-virtio-bus.c | 3 ++-
hw/s390x/virtio-ccw.c | 3 ++-
hw/virtio-net.c| 3 ++-
hw/virtio-pci.c| 3 ++-
hw/virtio.h| 3 ++-
5 files c
oops, sorry for that, it was not supposed to be resent. :-s
Fred.
On 11/02/2013 10:37, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
These structures must be made public to avoid two memory allocations for
refactored virtio devices.
Signed-off-by: KONRAD Frederic
---
hw/virtio-ba
On 11/02/2013 12:58, Cornelia Huck wrote:
On Mon, 11 Feb 2013 10:37:20 +0100
fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is the next part of virtio-refactoring.
I send it now to have it reviewed.
Basically it creates virtio-blk device which extends virtio-device.
Then a virt
Is this ok for everybody?
On 12/02/2013 18:00, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
These structures must be made public to avoid two memory allocations for
refactored virtio devices.
Changes V2 <- V1:
* Move the dataplane include into the header (virtio-blk).
Signed-o
On 18/02/2013 09:47, Andreas Färber wrote:
Am 12.02.2013 18:00, schrieb fred.kon...@greensocs.com:
From: KONRAD Frederic
These structures must be made public to avoid two memory allocations for
refactored virtio devices.
Changes V2 <- V1:
* Move the dataplane include into the header (vir
On 18/02/2013 09:59, Andreas Färber wrote:
Am 18.02.2013 09:53, schrieb KONRAD Frédéric:
On 18/02/2013 09:47, Andreas Färber wrote:
Am 12.02.2013 18:00, schrieb fred.kon...@greensocs.com:
From: KONRAD Frederic
These structures must be made public to avoid two memory allocations for
On 11/02/2013 10:37, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is the next part of virtio-refactoring.
I send it now to have it reviewed.
Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, v
Hi,
We actually want to add virtio models for arm, therefore these patches
are really helpful.
We will try it, start looking at the issues.
Any feedback ?
On 17/09/2012 12:00, Evgeny Voevodin wrote:
Previous RFC you can find at
http://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03665.h
Hi,
We are actually trying to use virtio devices with Virt-mmio bus.
The idea is to use theses patches I mentioned in a previous mail
(http://lists.gnu.org/archive/html/qemu-devel/2012-09/msg04913.html).
We are currently drawing the plan of how we can complete theses patches
to have it upstr
On 10/03/2013 17:28, Leonid Bloch wrote:
On Sun, Mar 10, 2013 at 4:59 PM, Peter Maydell wrote:
On 10 March 2013 14:36, Leonid Bloch wrote:
I want to cross compile QEMU itself to run on ARM, but all my searches
lead me to tutorials for cross compiling other programs for ARM and
testing them wi
On 01/03/2013 14:33, Paolo Bonzini wrote:
Done with this script:
cd hw
for i in `find . -name '*.h' | sed 's/^..//'`; do
echo '\,^#.*include.*["<]'$i'[">], s,'$i',hw/&,'
done | sed -i -f - `find . -type f`
This is so that paths remain valid as files are moved.
Instead, files in hw/dataplane
On 12/03/2013 09:19, KONRAD Frédéric wrote:
On 01/03/2013 14:33, Paolo Bonzini wrote:
Done with this script:
cd hw
for i in `find . -name '*.h' | sed 's/^..//'`; do
echo '\,^#.*include.*["<]'$i'[">], s,'$i',hw/&,'
done
On 12/03/2013 15:28, Peter Maydell wrote:
On 12 March 2013 09:22, wrote:
/* The ID for virtio_block */
@@ -130,4 +134,28 @@ typedef struct VirtIOBlock {
#define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
DEFINE_VIRTIO_COMMON_FEATURES(_state, _field)
+#ifdef CONFIG_VIRTIO_BLK_D
On 12/03/2013 15:42, Peter Maydell wrote:
On 12 March 2013 14:37, KONRAD Frédéric wrote:
On 12/03/2013 15:28, Peter Maydell wrote:
On 12 March 2013 09:22, wrote:
/* The ID for virtio_block */
@@ -130,4 +134,28 @@ typedef struct VirtIOBlock {
#define DEFINE_VIRTIO_BLK_FEATURES(_state
On 12/03/2013 16:12, Peter Maydell wrote:
On 12 March 2013 15:08, KONRAD Frédéric wrote:
On 12/03/2013 15:42, Peter Maydell wrote:
Yes, I see your problem there, but DEFINE_VIRTIO_BLK_SCSI_PROPERTY
and DEFINE_DATA_PLANE_PROPERTIES are just convenience macros, not
ones that are expected to be
On 12/03/2013 17:31, Cornelia Huck wrote:
On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric wrote:
On 12/03/2013 16:12, Peter Maydell wrote:
On 12 March 2013 15:08, KONRAD Frédéric wrote:
On 12/03/2013 15:42, Peter Maydell wrote:
Yes, I see your problem there, but
On 13/03/2013 09:24, KONRAD Frédéric wrote:
On 12/03/2013 17:31, Cornelia Huck wrote:
On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric wrote:
On 12/03/2013 16:12, Peter Maydell wrote:
On 12 March 2013 15:08, KONRAD Frédéric
wrote:
On 12/03/2013 15:42, Peter Maydell wrote:
Yes, I see
On 14/03/2013 08:25, Cornelia Huck wrote:
On Wed, 13 Mar 2013 16:32:31 +0100
KONRAD Frédéric wrote:
On 13/03/2013 09:24, KONRAD Frédéric wrote:
On 12/03/2013 17:31, Cornelia Huck wrote:
On Tue, 12 Mar 2013 16:22:22 +0100
KONRAD Frédéric wrote:
On 12/03/2013 16:12, Peter Maydell wrote
On 14/03/2013 09:42, Cornelia Huck wrote:
On Thu, 14 Mar 2013 09:37:54 +0100
KONRAD Frédéric wrote:
On 14/03/2013 08:25, Cornelia Huck wrote:
On Wed, 13 Mar 2013 16:32:31 +0100
KONRAD Frédéric wrote:
On 13/03/2013 09:24, KONRAD Frédéric wrote:
On 12/03/2013 17:31, Cornelia Huck wrote
On 15/03/2013 10:16, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is the next part of virtio-refactoring.
Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-bus.
virtio-blk-pci, virtio-blk-s390x, virtio-blk-ccw are
On 15/03/2013 13:44, Cornelia Huck wrote:
On Fri, 15 Mar 2013 10:19:50 +0100
KONRAD Frédéric wrote:
On 15/03/2013 10:16, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is the next part of virtio-refactoring.
Basically it creates virtio-blk device which extends virtio-device
On 18/03/2013 18:01, Cornelia Huck wrote:
On Mon, 18 Mar 2013 17:37:17 +0100
fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is the next part of virtio-refactoring.
Basically it creates virtio-blk device which extends virtio-device.
Then a virtio-blk can be connected on a virtio-
On 19/03/2013 09:27, Dunrong Huang wrote:
$ ~/usr/bin/qemu-system-x86_64 -enable-kvm -m 1024 -drive
if=none,id=drive0,cache=none,aio=native,format=raw,file=/root/Image/centos-6.4.raw
-device virtio-blk-pci,drive=drive0,scsi=off,x-data-plane=on,config-wce=on #
make dataplane fail to initialize
On 09/04/2013 21:13, Anthony Liguori wrote:
Paolo Bonzini writes:
Il 09/04/2013 10:22, Hans de Goede ha scritto:
Signed-off-by: Hans de Goede
Cc: Paolo Bonzini
---
hw/9pfs/virtio-9p-device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Ouch, /me installs libcap-ng-devel.
On a fre
On 09/04/2013 22:57, Anthony Liguori wrote:
KONRAD Frédéric writes:
On 09/04/2013 21:13, Anthony Liguori wrote:
Paolo Bonzini writes:
Il 09/04/2013 10:22, Hans de Goede ha scritto:
Signed-off-by: Hans de Goede
Cc: Paolo Bonzini
---
hw/9pfs/virtio-9p-device.c | 2 +-
1 file changed
On 12/04/2013 10:29, Peter Maydell wrote:
On 11 April 2013 23:38, wrote:
From: KONRAD Frederic
To keep compatibility with the old virtio-balloon-x, add the dynamic properties
to virtio-balloon-pci and virtio-balloon-ccw.
Does the approach I suggested on IRC where virtio-balloon-pci's
proper
On 12/04/2013 11:14, Peter Maydell wrote:
On 12 April 2013 09:36, KONRAD Frédéric wrote:
On 12/04/2013 10:29, Peter Maydell wrote:
Does the approach I suggested on IRC where virtio-balloon-pci's
property set/get callbacks just set/get the property on
virtio-balloon via the public inte
On 12/04/2013 11:14, Peter Maydell wrote:
On 12 April 2013 09:36, KONRAD Frédéric wrote:
On 12/04/2013 10:29, Peter Maydell wrote:
Does the approach I suggested on IRC where virtio-balloon-pci's
property set/get callbacks just set/get the property on
virtio-balloon via the public inte
On 15/04/2013 15:38, Cornelia Huck wrote:
On Sun, 14 Apr 2013 23:26:34 +0200
fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
This is a cleanup for virtio-ccw.
The init function is replaced by the device_plugged callback from
virtio-bus.
Hm, so you replaced a callback that might return
On 15/04/2013 15:34, Andreas Färber wrote:
Am 14.04.2013 15:01, schrieb fred.kon...@greensocs.com:
From: KONRAD Frederic
As the virtio-rng-pci and virtio-rng-s390 are switched to the new API,
and virtio-rng-ccw ;)
we can use QOM casts.
Signed-off-by: KONRAD Frederic
---
hw/virtio/virtio
On 18/04/2013 10:19, Amos Kong wrote:
On Wed, Apr 10, 2013 at 02:28:40PM +0200, Andreas Färber wrote:
Hi,
Am 10.04.2013 14:05, schrieb Amos Kong:
If we don't assign 'id' for nic device, device name will be $model.$idx. The
$idx are always 0 if we set nic by new style.
# qemu-upstream -device
On 18/04/2013 11:47, Amos Kong wrote:
On Thu, Apr 18, 2013 at 11:12:56AM +0200, KONRAD Frédéric wrote:
On 18/04/2013 10:19, Amos Kong wrote:
On Wed, Apr 10, 2013 at 02:28:40PM +0200, Andreas Färber wrote:
Hi,
Am 10.04.2013 14:05, schrieb Amos Kong:
If we don't assign 'id'
On 18/04/2013 10:41, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 04:30:01PM +0200, fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
As the virtio-net-pci and virtio-net-s390 are switched to the new API,
we can use QOM casts.
Signed-off-by: KONRAD Frederic
---
hw/net/virtio-net.
On 22/04/2013 15:27, Andreas Färber wrote:
Hi,
Am 22.04.2013 13:51, schrieb Libaiqing:
When I use the config below,an error occurs.Is there anything wrong?
Qemu-kvm -enable-kvm -name win7 -M pc-0.15 -m 1024 -smp 2 -boot c -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -
On 22/04/2013 16:02, Andreas Färber wrote:
Hi Fred,
Am 22.04.2013 15:54, schrieb KONRAD Frédéric:
On 22/04/2013 15:27, Andreas Färber wrote:
Am 22.04.2013 13:51, schrieb Libaiqing:
When I use the config below,an error occurs.Is there anything wrong?
Qemu-kvm -enable-kvm -name win7
On 22/04/2013 16:22, Andreas Färber wrote:
Am 22.04.2013 16:15, schrieb KONRAD Frédéric:
On 22/04/2013 16:02, Andreas Färber wrote:
Hi Fred,
Am 22.04.2013 15:54, schrieb KONRAD Frédéric:
On 22/04/2013 15:27, Andreas Färber wrote:
Am 22.04.2013 13:51, schrieb Libaiqing:
When I use the
On 25/04/2013 16:41, Michal Privoznik wrote:
I've noticed some strange behavior after the commit from $subj:
$ qemu-system-x86_64 -device
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x7 \
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.gue
On 29/04/2013 16:42, Jesse Larrew wrote:
On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:
On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:
Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets
On 29/04/2013 17:14, Jesse Larrew wrote:
On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:
On 29/04/2013 16:42, Jesse Larrew wrote:
On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:
On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:
Commit 14f9b664 (hw/virtio-net.c: set config size
On 29/04/2013 18:02, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew wrote:
On 04/29/2013 10:29 AM, KONRAD Frédéric wrote:
On 29/04/2013 17:14, Jesse Larrew wrote:
On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:
On 29/04/2013 16:42, Jesse Larrew wrote:
On 04
On 29/04/2013 17:40, Paolo Bonzini wrote:
Il 29/04/2013 17:12, fred.kon...@greensocs.com ha scritto:
From: KONRAD Frederic
This add the possibility to create a scsi-bus with a specified name.
Signed-off-by: KONRAD Frederic
---
hw/scsi/scsi-bus.c | 12 +---
include/hw/scsi/scsi
On 29/04/2013 17:44, Paolo Bonzini wrote:
Il 29/04/2013 17:12, fred.kon...@greensocs.com ha scritto:
From: KONRAD Frederic
The bus name is wrong since the refactoring.
This keep the behaviour of the command line.
Signed-off-by: KONRAD Frederic
---
hw/s390x/s390-virtio-bus.c | 9
On 29/04/2013 18:30, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 06:14:41PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 18:02, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 10:55:36AM -0500, Jesse Larrew wrote:
On
On 29/04/2013 19:01, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 06:41:08PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 18:30, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 07:21:06PM +0300, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 06:14:41PM +0200, KONRAD Frédéric wrote
On 29/04/2013 18:32, Paolo Bonzini wrote:
Il 29/04/2013 18:28, KONRAD Frédéric ha scritto:
Could this be simply a qdev property?
Yes, that can be a good idea.
What about adding a qdev property bus_name and using it in qbus_realize?
Like this:
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
On 29/04/2013 19:52, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 07:23:49PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 19:01, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 06:41:08PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 18:30, Michael S. Tsirkin wrote
On 29/04/2013 19:55, Andreas Färber wrote:
Am 29.04.2013 19:39, schrieb KONRAD Frédéric:
On 29/04/2013 18:32, Paolo Bonzini wrote:
Il 29/04/2013 18:28, KONRAD Frédéric ha scritto:
Could this be simply a qdev property?
Yes, that can be a good idea.
What about adding a qdev property bus_name
On 29/04/2013 20:15, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 08:01:52PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 19:52, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 07:23:49PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 19:01, Michael S. Tsirkin wrote:
On Mon, Apr 29
On 29/04/2013 22:09, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 08:45:50PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 20:15, Michael S. Tsirkin wrote:
On Mon, Apr 29, 2013 at 08:01:52PM +0200, KONRAD Frédéric wrote:
On 29/04/2013 19:52, Michael S. Tsirkin wrote
On 29/04/2013 17:44, Paolo Bonzini wrote:
Il 29/04/2013 17:12, fred.kon...@greensocs.com ha scritto:
From: KONRAD Frederic
The bus name is wrong since the refactoring.
This keep the behaviour of the command line.
Signed-off-by: KONRAD Frederic
---
hw/s390x/s390-virtio-bus.c | 9
On 30/04/2013 16:01, Paolo Bonzini wrote:
Il 30/04/2013 15:06, KONRAD Frédéric ha scritto:
Could this be simply a qdev property?
Well, maybe my solution is too extreme.
Maybe I can put bus_name in struct VirtIODevice instead to avoid the
set_virtio_x_bus_name code duplication?
No, I think it
On 02/05/2013 15:40, Cornelia Huck wrote:
On Tue, 30 Apr 2013 16:08:46 +0200
fred.kon...@greensocs.com wrote:
From: KONRAD Frederic
Cc: Libaiqing
Cc: Michal Privoznik
This fixes the bus name for virtio-serial-device and virtio-scsi-device.
The bus name for virtio-serial-device and virtio-
On 06/05/2013 22:51, Anthony Liguori wrote:
"Michael S. Tsirkin" writes:
mask notifiers are never called without msix,
so devices with backend masking like vhost don't work.
Call mask notifiers explicitly at
startup/cleanup to make it work.
Signed-off-by: Michael S. Tsirkin
Tested-by: Alexan
On 07/05/2013 12:20, Michael S. Tsirkin wrote:
mask notifiers are never called without msix,
so devices with backend masking like vhost don't work.
Call mask notifiers explicitly at
startup/cleanup to make it work.
Signed-off-by: Michael S. Tsirkin
Tested-by: Alexander Graf
---
Changes from v
Hi,
I think it is not a good idea, as we wanted to make VirtIODevice
hot-pluggable for virtio-mmio.
Maybe we can use a callback which is called by virtio-bus before
plugging, to ensure that this
config size is computed?
On 07/05/2013 12:22, Michael S. Tsirkin wrote:
All buses do this, and
On 07/05/2013 14:33, Michael S. Tsirkin wrote:
On Tue, May 07, 2013 at 02:29:38PM +0200, KONRAD Frédéric wrote:
Hi,
I think it is not a good idea, as we wanted to make VirtIODevice
hot-pluggable for virtio-mmio.
And then this hack will break cross version migration.
Why
On 07/05/2013 16:00, Michael S. Tsirkin wrote:
On Tue, May 07, 2013 at 02:54:38PM +0200, KONRAD Frédéric wrote:
On 07/05/2013 14:33, Michael S. Tsirkin wrote:
On Tue, May 07, 2013 at 02:29:38PM +0200, KONRAD Frédéric wrote:
Hi,
I think it is not a good idea, as we wanted to make VirtIODevice
Hi,
We are trying to find a way to do reverse execution happen with QEMU.
Actually, it is possible to debug the guest through the gdbstub, we want to
make the reverse execution possible with GDB as well.
How we are trying to make that working (basically without optimisation):
-QEMU takes regul
Hi,
We are trying to do a simple save/restore on the VM with icount enabled.
We saw that qemu_icount_bias and qemu_icount in cpus.c are not
saved/restored,
and icount_extra, icount_decr in CPUState neither, so the vm_clock is just
growing normally after restoring the VM is that normal?
We thi
On 15/05/2013 15:16, Stefan Hajnoczi wrote:
On Wed, May 15, 2013 at 02:12:49PM +0200, fred.kon...@greensocs.com wrote:
@@ -1315,8 +1338,17 @@ static int virtio_net_device_init(VirtIODevice *vdev)
memcpy(&n->mac[0], &n->nic_conf.macaddr, sizeof(n->mac));
n->status = VIRTIO_NET_S_LINK_
On 15/05/2013 14:50, Paolo Bonzini wrote:
Il 15/05/2013 11:31, KONRAD Frédéric ha scritto:
Hi,
We are trying to do a simple save/restore on the VM with icount enabled.
We saw that qemu_icount_bias and qemu_icount in cpus.c are not
saved/restored,
and icount_extra, icount_decr in CPUState
On 16/05/2013 16:21, mdroth wrote:
On Wed, May 15, 2013 at 06:53:47PM -0500, Anthony Liguori wrote:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 1.5 release. This release is meant
for testing purposes and should not be used i
On 16/05/2013 16:51, Paolo Bonzini wrote:
Il 16/05/2013 16:21, mdroth ha scritto:
commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic
Date: Thu Apr 11 16:29:58 2013 +0200
virtio-net-pci: switch to the new API.
Here the virtio-net-pci is modified for the ne
On 16/05/2013 18:07, Paolo Bonzini wrote:
Il 16/05/2013 17:54, KONRAD Frédéric ha scritto:
I think this can do the job, any better idea?
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d5257ed..e033b53 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -43,7 +43,6 @@
#endif
static void
On 16/05/2013 18:33, Anthony Liguori wrote:
KONRAD Frédéric writes:
On 16/05/2013 16:51, Paolo Bonzini wrote:
Il 16/05/2013 16:21, mdroth ha scritto:
commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic
Date: Thu Apr 11 16:29:58 2013 +0200
virtio-net-pci: switch
On 16/05/2013 18:49, mdroth wrote:
On Thu, May 16, 2013 at 06:34:09PM +0200, KONRAD Frédéric wrote:
On 16/05/2013 18:07, Paolo Bonzini wrote:
Il 16/05/2013 17:54, KONRAD Frédéric ha scritto:
I think this can do the job, any better idea?
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index d5257ed
On 09/05/2013 19:54, Blue Swirl wrote:
On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
wrote:
Hi,
We are trying to find a way to do reverse execution happen with QEMU.
Actually, it is possible to debug the guest through the gdbstub, we want to
make the reverse execution possible with GDB as
On 18/05/2013 20:52, Blue Swirl wrote:
On Fri, May 17, 2013 at 5:23 PM, KONRAD Frédéric
wrote:
On 09/05/2013 19:54, Blue Swirl wrote:
On Tue, May 7, 2013 at 6:27 PM, KONRAD Frédéric
wrote:
Hi,
We are trying to find a way to do reverse execution happen with QEMU.
Actually, it is possible
Hi,
Just to be sure that we are all understanding the same thing about the
virtio
refactoring.
The old patch-set ( git://git.greensocs.com/qemu_virtio.git virtio ) I
sent was
not good because :
* It use a custom transport property ( e.g : transport=virtio-mmio.0 ) for
selecting a transpor
On 13/11/2012 16:32, Cornelia Huck wrote:
On Tue, 13 Nov 2012 15:27:57 +0100
KONRAD Frédéric wrote:
To fix this, an idea is to use a new qbus named VirtioBus to link virtio-pci
or virtio-mmio with all the virtio backend ( VirtioDevice ). So
"virtio-pci" and
"virtio-mmio" w
Hi,
On 13/11/2012 19:09, Cornelia Huck wrote:
On Tue, 13 Nov 2012 17:31:40 +0100
KONRAD Frédéric wrote:
We'd go from
system bus
-> virtio transport bridge dev (virtio-xxx-bridge)
-> virtio transport bus (virtio-xxx-bus)
-> virtio transport dev (virtio--xxx)
On 20/11/2012 15:12, Cornelia Huck wrote:
On Mon, 19 Nov 2012 17:33:01 +
Peter Maydell wrote:
On 16 November 2012 15:35, wrote:
From: KONRAD Frederic
You forgot to CC enough people...
This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-
On 20/11/2012 17:15, Cornelia Huck wrote:
On Tue, 20 Nov 2012 15:30:35 +0100
KONRAD Frédéric wrote:
On 20/11/2012 15:12, Cornelia Huck wrote:
On Mon, 19 Nov 2012 17:33:01 +
Peter Maydell wrote:
On 16 November 2012 15:35, wrote:
From: KONRAD Frederic
You forgot to CC enough people
On 19/11/2012 18:33, Peter Maydell wrote:
On 16 November 2012 15:35, wrote:
From: KONRAD Frederic
You forgot to CC enough people...
This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-mmio,...
One VirtIODevice can be connected to this device,
On 21/11/2012 14:04, Andreas Färber wrote:
Am 16.11.2012 16:35, schrieb fred.kon...@greensocs.com:
From: KONRAD Frederic
This patch create a new VirtioBus, which can be added to Virtio transports like
virtio-pci, virtio-mmio,...
One VirtIODevice can be connected to this device, like virtio-bl
On 21/11/2012 15:13, Andreas Färber wrote:
Am 21.11.2012 15:05, schrieb KONRAD Frédéric:
On 21/11/2012 14:04, Andreas Färber wrote:
Am 16.11.2012 16:35, schrieb fred.kon...@greensocs.com:
+#define DEBUG_VIRTIO_BUS
+
+#ifdef DEBUG_VIRTIO_BUS
+
+#define DPRINTF(fmt, ...) \
+do { printf
Did you get the full patchset ? The 01 and 02 seems to be lost on
the mailing list. :s.
On 22/11/2012 16:08, Peter Maydell wrote:
On 22 November 2012 14:50, wrote:
There are still two issues with the command line :
* When I use ./qemu* -device virtio-blk -device virtio-pci
It is
1 - 100 of 135 matches
Mail list logo
