Re: [Qemu-devel] CODING_STYLE and if blocks
On Fri, Oct 23, 2009 at 01:47:04AM +0200, Alexander Graf wrote: On 23.10.2009, at 00:42, Anthony Liguori wrote: Aurelien Jarno wrote: Hi all, I am currently reviewing the S390 patches which extensively use of code like: if (a == 5) printf(a was 5.\n); else if (a == 6) printf(a was 6.\n); else printf(a was something else entirely.\n); It is something currently allowed by the CODING_STYLE document (there is no indented statement), but I am not fully comfortable with it. Should we accept such code? Should we fix CODING_STYLE? I'd vote for fixing CODING_STYLE as that syntax makes my eyes hurt. While CODING_STYLE is there as a guideline, good taste should still always prevail :-) I think Uli only wrote the code as is because CODING_STYLE told him to always use braces around one-liner statements. I don't see how if (a == 5) printf(a was 5.\n); else if (a == 6) printf(a was 6.\n); else printf(a was something else entirely.\n); would be not readable. In fact I tend to use that code style myself a lot in places where it makes sense like: if (r 0) return r; It would really hurt my eyes to have braces on these simple ifs every single time. It has been debated already a few times already, the argument against this it that it make patches more difficulty readable. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH] target-arm: use clz32() instead of a for loop
Stuart Brady a écrit :
On Thu, Oct 15, 2009 at 11:14:52PM +0200, Aurelien Jarno wrote:
@@ -394,10 +395,7 @@ uint32_t HELPER(uxtb16)(uint32_t x)
uint32_t HELPER(clz)(uint32_t x)
{
-int count;
-for (count = 32; x; count--)
-x = 1;
-return count;
+return clz32(x);
}
int32_t HELPER(sdiv)(int32_t num, int32_t den)
Just a quick note that the implementation of clz, ctz and popcnt is
still listed in the TCG TODO list. The last time I looked, I noticed
that quite a few architectures have clz/ctz instructions:
http://lkml.indiana.edu/hypermail/linux/kernel/0601.3/1683.html
OTOH, a dump shows that those instruction are not used than often, so I
am not sure it worth implementing it.
For those that don't, I think a combination the following two hacks at
http://graphics.stanford.edu/~seander/bithacks.html could be used:
The best is probably to use an helper in that case, calling clz32(x).
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
Am 23.10.2009 01:55, schrieb Juan Quintela: Anthony Liguori anth...@codemonkey.ws wrote: Luiz Capitulino wrote: On Thu, 22 Oct 2009 10:40:54 -0500 Anthony Liguori anth...@codemonkey.ws wrote: Luiz Capitulino wrote: Yeah, I agree. When testing migration, for example, I have to type 'migrate -d tcp:0:' several times... Maybe there's a smarter way to do this, but the monitor macros idea seems interesting to me. When we have QMP, we can create a QMP socket at a well known location based on the -name parameter. We could also introduce a qm command that allowed one to execute monitor commands from the shell. That allows people to write whatever crazy shell scripts they want. Yes. What about the macros idea? Are you against it? I'm concerned that it's a snowball of complexity waiting to happen for very little benefit. I think we're trying to solve a non-existent problem. I fully agree. If we have a had to issue commands to the monitor, we can use whatever shell/interpreter/... that we like. But I can't bind a keyboard shortcut to such a script which is exactly what this thread is about... What I want to have in the end is my VM stop shortcut, dynamically binding keys to monitor commands is just a way to achieve this. I really hate this You don't need this, I know it better attitude. If it were only for the technical arguments, okay - I can understand that you don't want to add another magic key, and yes, doing it dynamically comes with some complexity. But all this talking about non-existent problems makes me think that you don't... really care about what users want if they are the wrong users (yes, I admit, this one is useful more likely for developers and plain qemu users than for those running their servers in KVM - but they are still users, right?) Kevin
[Qemu-devel] [PATCH 0/5] use qdev for -usbdevice
Hi, This patch series changes the way the -usbdevice switch (and the usb_add monitor command) is handled. Instead of hard-coding stuff in vl.c it is integrated with qdev by adding new fields to USBDeviceInfo. First patch adds the infrastructure. Follwing patches switch over the usb drivers to the new way of handling things. Not converted (yet) are: * bt: bluetooth is not qdev-ified at all, needs investigation. * host: big project, especially the auto-add-by-id stuff. * net: too many net patches in flight right now. cheers, Gerd
[Qemu-devel] [PATCH 1/5] usb core: use qdev for -usbdevice
This patchs adds infrastructure to handle -usbdevice via qdev callbacks.
USBDeviceInfo gets a name field (for the -usbdevice driver name) and a
callback for -usbdevice parameter parsing.
The new usbdevice_create() function walks the qdev driver list and looks
for a usb driver with a matching name. When a parameter parsing
callback is present it is called, otherwise the device is created via
usb_create_simple().
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/qdev.c|2 +-
hw/qdev.h|1 +
hw/usb-bus.c | 47 +++
hw/usb.h |5 +
vl.c |5 +
5 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/hw/qdev.c b/hw/qdev.c
index 20f931c..b0d92d2 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -35,7 +35,7 @@ static int qdev_hotplug = 0;
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
static BusState *main_system_bus;
-static DeviceInfo *device_info_list;
+DeviceInfo *device_info_list;
static BusState *qbus_find_recursive(BusState *bus, const char *name,
const BusInfo *info);
diff --git a/hw/qdev.h b/hw/qdev.h
index b79f3e3..738470b 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -140,6 +140,7 @@ struct DeviceInfo {
BusInfo *bus_info;
struct DeviceInfo *next;
};
+extern DeviceInfo *device_info_list;
void qdev_register(DeviceInfo *info);
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 98987a1..28b517f 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -252,3 +252,50 @@ void usb_info(Monitor *mon)
}
}
+/* handle legacy -usbdevice cmd line option */
+USBDevice *usbdevice_create(const char *cmdline)
+{
+USBBus *bus = usb_bus_find(-1 /* any */);
+DeviceInfo *info;
+USBDeviceInfo *usb;
+char driver[32], *params;
+int len;
+
+params = strchr(cmdline,':');
+if (params) {
+params++;
+len = params - cmdline;
+if (len sizeof(driver))
+len = sizeof(driver);
+pstrcpy(driver, len, cmdline);
+} else {
+pstrcpy(driver, sizeof(driver), cmdline);
+}
+
+for (info = device_info_list; info != NULL; info = info-next) {
+if (info-bus_info != usb_bus_info)
+continue;
+usb = DO_UPCAST(USBDeviceInfo, qdev, info);
+if (usb-usbdevice_name == NULL)
+continue;
+if (strcmp(usb-usbdevice_name, driver) != 0)
+continue;
+break;
+}
+if (info == NULL) {
+#if 0
+/* no error because some drivers are not converted (yet) */
+qemu_error(usbdevice %s not found\n, driver);
+#endif
+return NULL;
+}
+
+if (!usb-usbdevice_init) {
+if (params) {
+qemu_error(usbdevice %s accepts no params\n, driver);
+return NULL;
+}
+return usb_create_simple(bus, usb-qdev.name);
+}
+return usb-usbdevice_init(params);
+}
diff --git a/hw/usb.h b/hw/usb.h
index be4fcf6..62362a7 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -183,6 +183,10 @@ struct USBDeviceInfo {
* Returns length or one of the USB_RET_ codes.
*/
int (*handle_data)(USBDevice *dev, USBPacket *p);
+
+/* handle legacy -usbdevice command line options */
+const char *usbdevice_name;
+USBDevice *(*usbdevice_init)(const char *params);
};
typedef void (*usb_attachfn)(USBPort *port, USBDevice *dev);
@@ -309,6 +313,7 @@ void usb_qdev_register(USBDeviceInfo *info);
void usb_qdev_register_many(USBDeviceInfo *info);
USBDevice *usb_create(USBBus *bus, const char *name);
USBDevice *usb_create_simple(USBBus *bus, const char *name);
+USBDevice *usbdevice_create(const char *cmdline);
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
usb_attachfn attach);
void usb_unregister_port(USBBus *bus, USBPort *port);
diff --git a/vl.c b/vl.c
index eb2744e..30b5306 100644
--- a/vl.c
+++ b/vl.c
@@ -2562,6 +2562,11 @@ static int usb_device_add(const char *devname, int
is_hotplug)
if (!usb_enabled)
return -1;
+/* drivers with .usbdevice_name entry in USBDeviceInfo */
+dev = usbdevice_create(devname);
+if (dev)
+goto done;
+
/* simple devices which don't need extra care */
for (i = 0; i ARRAY_SIZE(usbdevs); i++) {
if (strcmp(devname, usbdevs[i].name) != 0)
--
1.6.2.5
[Qemu-devel] [PATCH 3/5] usb-serial and braille: use qdev for -usbdevice
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/baum.c |6
hw/baum.h |3 --
hw/usb-serial.c | 85 ++-
hw/usb.h|3 --
vl.c|6
5 files changed, 65 insertions(+), 38 deletions(-)
diff --git a/hw/baum.c b/hw/baum.c
index c66e737..8a12985 100644
--- a/hw/baum.c
+++ b/hw/baum.c
@@ -627,9 +627,3 @@ fail_handle:
free(baum);
return NULL;
}
-
-USBDevice *usb_baum_init(void)
-{
-/* USB Product ID of Super Vario 40 */
-return usb_serial_init(productid=FE72:braille);
-}
diff --git a/hw/baum.h b/hw/baum.h
index 39ca4b1..8af710f 100644
--- a/hw/baum.h
+++ b/hw/baum.h
@@ -22,8 +22,5 @@
* THE SOFTWARE.
*/
-/* usb device */
-USBDevice *usb_baum_init(void);
-
/* char device */
CharDriverState *chr_baum_init(QemuOpts *opts);
diff --git a/hw/usb-serial.c b/hw/usb-serial.c
index d02f6b2..223d4c3 100644
--- a/hw/usb-serial.c
+++ b/hw/usb-serial.c
@@ -90,8 +90,8 @@ do { printf(usb-serial: fmt , ## __VA_ARGS__); } while (0)
typedef struct {
USBDevice dev;
-uint16_t vendorid;
-uint16_t productid;
+uint32_t vendorid;
+uint32_t productid;
uint8_t recv_buf[RECV_BUF];
uint16_t recv_ptr;
uint16_t recv_used;
@@ -527,15 +527,18 @@ static int usb_serial_initfn(USBDevice *dev)
{
USBSerialState *s = DO_UPCAST(USBSerialState, dev, dev);
s-dev.speed = USB_SPEED_FULL;
+
+qemu_chr_add_handlers(s-cs, usb_serial_can_read, usb_serial_read,
+ usb_serial_event, s);
+usb_serial_handle_reset(dev);
return 0;
}
-USBDevice *usb_serial_init(const char *filename)
+static USBDevice *usb_serial_init(const char *filename)
{
USBDevice *dev;
-USBSerialState *s;
CharDriverState *cdrv;
-unsigned short vendorid = 0x0403, productid = 0x6001;
+uint32_t vendorid = 0, productid = 0;
char label[32];
static int index;
@@ -545,26 +548,26 @@ USBDevice *usb_serial_init(const char *filename)
if (strstart(filename, vendorid=, p)) {
vendorid = strtol(p, e, 16);
if (e == p || (*e *e != ',' *e != ':')) {
-printf(bogus vendor ID %s\n, p);
+qemu_error(bogus vendor ID %s\n, p);
return NULL;
}
filename = e;
} else if (strstart(filename, productid=, p)) {
productid = strtol(p, e, 16);
if (e == p || (*e *e != ',' *e != ':')) {
-printf(bogus product ID %s\n, p);
+qemu_error(bogus product ID %s\n, p);
return NULL;
}
filename = e;
} else {
-printf(unrecognized serial USB option %s\n, filename);
+qemu_error(unrecognized serial USB option %s\n, filename);
return NULL;
}
while(*filename == ',')
filename++;
}
if (!*filename) {
-printf(character device specification needed\n);
+qemu_error(character device specification needed\n);
return NULL;
}
filename++;
@@ -574,23 +577,56 @@ USBDevice *usb_serial_init(const char *filename)
if (!cdrv)
return NULL;
-dev = usb_create_simple(NULL /* FIXME */, QEMU USB Serial);
-s = DO_UPCAST(USBSerialState, dev, dev);
-s-cs = cdrv;
-s-vendorid = vendorid;
-s-productid = productid;
-snprintf(s-dev.devname, sizeof(s-dev.devname), QEMU USB Serial(%.16s),
- filename);
+dev = usb_create(NULL /* FIXME */, QEMU USB Serial);
+qdev_prop_set_chr(dev-qdev, chardev, cdrv);
+if (vendorid)
+qdev_prop_set_uint16(dev-qdev, vendorid, vendorid);
+if (productid)
+qdev_prop_set_uint16(dev-qdev, productid, productid);
+qdev_init(dev-qdev);
-qemu_chr_add_handlers(cdrv, usb_serial_can_read, usb_serial_read,
- usb_serial_event, s);
+return dev;
+}
+
+static USBDevice *usb_braille_init(const char *unused)
+{
+USBDevice *dev;
+CharDriverState *cdrv;
+
+cdrv = qemu_chr_open(braille, braille, NULL);
+if (!cdrv)
+return NULL;
-usb_serial_handle_reset((USBDevice *)s);
-return (USBDevice *)s;
+dev = usb_create(NULL /* FIXME */, QEMU USB Braille);
+qdev_prop_set_chr(dev-qdev, chardev, cdrv);
+qdev_init(dev-qdev);
+
+return dev;
}
static struct USBDeviceInfo serial_info = {
.qdev.name = QEMU USB Serial,
+.qdev.alias = usb-serial,
+.qdev.size = sizeof(USBSerialState),
+.init = usb_serial_initfn,
+.handle_packet = usb_generic_handle_packet,
+.handle_reset = usb_serial_handle_reset,
+.handle_control = usb_serial_handle_control,
+.handle_data= usb_serial_handle_data,
+.handle_destroy = usb_serial_handle_destroy,
+.usbdevice_name = serial,
+.usbdevice_init = usb_serial_init,
+.qdev.props = (Property[]) {
+
[Qemu-devel] [PATCH 4/5] usb: make attach optional.
Add a auto_attach field to USBDevice, which is enabled by default.
USB drivers can clear this field in case they do *not* want the device
being attached (i.e. plugged into a usb port) automatically after
successfull init().
Use cases:
* attaching encrypted mass storage devices (see next patch).
* maybe also -usbdevice host:$vendorid:$productid
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb-bus.c |7 +--
hw/usb.h |1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 28b517f..4d0c10d 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -46,7 +46,7 @@ static int usb_qdev_init(DeviceState *qdev, DeviceInfo *base)
pstrcpy(dev-devname, sizeof(dev-devname), qdev-info-name);
dev-info = info;
rc = dev-info-init(dev);
-if (rc == 0)
+if (rc == 0 dev-auto_attach)
usb_device_attach(dev);
return rc;
}
@@ -82,6 +82,7 @@ void usb_qdev_register_many(USBDeviceInfo *info)
USBDevice *usb_create(USBBus *bus, const char *name)
{
DeviceState *dev;
+USBDevice *usb;
#if 1
/* temporary stopgap until all usb is properly qdev-ified */
@@ -95,7 +96,9 @@ USBDevice *usb_create(USBBus *bus, const char *name)
#endif
dev = qdev_create(bus-qbus, name);
-return DO_UPCAST(USBDevice, qdev, dev);
+usb = DO_UPCAST(USBDevice, qdev, dev);
+usb-auto_attach = 1;
+return usb;
}
USBDevice *usb_create_simple(USBBus *bus, const char *name)
diff --git a/hw/usb.h b/hw/usb.h
index a875d5b..a01f334 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -133,6 +133,7 @@ struct USBDevice {
int speed;
uint8_t addr;
char devname[32];
+int auto_attach;
int attached;
int state;
--
1.6.2.5
[Qemu-devel] [PATCH 5/5] usb-storage: use qdev for -usbdevice
Hook up usb_msd_init.
Also rework handling of encrypted block devices,
move the code out vl.c.
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
hw/usb-msd.c | 33 +
hw/usb.h |4
vl.c | 25 -
3 files changed, 25 insertions(+), 37 deletions(-)
diff --git a/hw/usb-msd.c b/hw/usb-msd.c
index dd3010e..8dc494f 100644
--- a/hw/usb-msd.c
+++ b/hw/usb-msd.c
@@ -14,6 +14,7 @@
#include block.h
#include scsi-disk.h
#include console.h
+#include monitor.h
//#define DEBUG_MSD
@@ -508,6 +509,16 @@ static int usb_msd_handle_data(USBDevice *dev, USBPacket
*p)
return ret;
}
+static void usb_msd_password_cb(void *opaque, int err)
+{
+MSDState *s = opaque;
+
+if (!err)
+usb_device_attach(s-dev);
+else
+qdev_unplug(s-dev.qdev);
+}
+
static int usb_msd_initfn(USBDevice *dev)
{
MSDState *s = DO_UPCAST(MSDState, dev, dev);
@@ -522,10 +533,21 @@ static int usb_msd_initfn(USBDevice *dev)
s-scsi_dev = scsi_bus_legacy_add_drive(s-bus, s-dinfo, 0);
s-bus.qbus.allow_hotplug = 0;
usb_msd_handle_reset(dev);
+
+if (bdrv_key_required(s-dinfo-bdrv)) {
+if (s-dev.qdev.hotplugged) {
+monitor_read_bdrv_key_start(cur_mon, s-dinfo-bdrv,
+usb_msd_password_cb, s);
+s-dev.auto_attach = 0;
+} else {
+autostart = 0;
+}
+}
+
return 0;
}
-USBDevice *usb_msd_init(const char *filename)
+static USBDevice *usb_msd_init(const char *filename)
{
static int nr=0;
char id[8];
@@ -577,13 +599,6 @@ USBDevice *usb_msd_init(const char *filename)
return dev;
}
-BlockDriverState *usb_msd_get_bdrv(USBDevice *dev)
-{
-MSDState *s = (MSDState *)dev;
-
-return s-dinfo-bdrv;
-}
-
static struct USBDeviceInfo msd_info = {
.qdev.name = QEMU USB MSD,
.qdev.alias = usb-storage,
@@ -593,6 +608,8 @@ static struct USBDeviceInfo msd_info = {
.handle_reset = usb_msd_handle_reset,
.handle_control = usb_msd_handle_control,
.handle_data= usb_msd_handle_data,
+.usbdevice_name = disk,
+.usbdevice_init = usb_msd_init,
.qdev.props = (Property[]) {
DEFINE_PROP_DRIVE(drive, MSDState, dinfo),
DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/usb.h b/hw/usb.h
index a01f334..351c466 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -256,10 +256,6 @@ void usb_host_info(Monitor *mon);
/* usb-hid.c */
void usb_hid_datain_cb(USBDevice *dev, void *opaque, void (*datain)(void *));
-/* usb-msd.c */
-USBDevice *usb_msd_init(const char *filename);
-BlockDriverState *usb_msd_get_bdrv(USBDevice *dev);
-
/* usb-net.c */
USBDevice *usb_net_init(NICInfo *nd);
diff --git a/vl.c b/vl.c
index 64761cf..994065c 100644
--- a/vl.c
+++ b/vl.c
@@ -2523,16 +2523,6 @@ static void smp_parse(const char *optarg)
/***/
/* USB devices */
-static void usb_msd_password_cb(void *opaque, int err)
-{
-USBDevice *dev = opaque;
-
-if (!err)
-usb_device_attach(dev);
-else
-dev-info-handle_destroy(dev);
-}
-
static int usb_device_add(const char *devname, int is_hotplug)
{
const char *p;
@@ -2549,21 +2539,6 @@ static int usb_device_add(const char *devname, int
is_hotplug)
/* the other ones */
if (strstart(devname, host:, p)) {
dev = usb_host_device_open(p);
-} else if (strstart(devname, disk:, p)) {
-BlockDriverState *bs;
-
-dev = usb_msd_init(p);
-if (!dev)
-return -1;
-bs = usb_msd_get_bdrv(dev);
-if (bdrv_key_required(bs)) {
-autostart = 0;
-if (is_hotplug) {
-monitor_read_bdrv_key_start(cur_mon, bs, usb_msd_password_cb,
-dev);
-return 0;
-}
-}
} else if (strstart(devname, net:, p)) {
QemuOpts *opts;
int idx;
--
1.6.2.5
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Hello, Does the following patch work for you? diff --git a/sheep/work.c b/sheep/work.c index 4df8dc0..45f362d 100644 --- a/sheep/work.c +++ b/sheep/work.c @@ -28,6 +28,7 @@ #include syscall.h #include sys/types.h #include linux/types.h +#define _LINUX_FCNTL_H #include linux/signalfd.h #include list.h On Wed, Oct 21, 2009 at 5:45 PM, Nikolai K. Bochev n.boc...@grandstarco.com wrote: Hello, I am getting the following error trying to compile sheepdog on Ubuntu 9.10 ( 2.6.31-14 x64 ) : cd shepherd; make make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/shepherd' cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE shepherd.c -o shepherd.o shepherd.c: In function ‘main’: shepherd.c:300: warning: dereferencing pointer ‘hdr.55’ does break strict-aliasing rules shepherd.c:300: note: initialized from here cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE treeview.c -o treeview.o cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE ../lib/event.c -o ../lib/event.o cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE ../lib/net.c -o ../lib/net.o ../lib/net.c: In function ‘write_object’: ../lib/net.c:358: warning: ‘vosts’ may be used uninitialized in this function cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE ../lib/logger.c -o ../lib/logger.o cc shepherd.o treeview.o ../lib/event.o ../lib/net.o ../lib/logger.o -o shepherd -lncurses -lcrypto make[1]: Leaving directory `/home/shiny/Packages/sheepdog-2009102101/shepherd' cd sheep; make make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/sheep' cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE sheep.c -o sheep.o cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE store.c -o store.o cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE net.c -o net.o cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE work.c -o work.o In file included from /usr/include/asm/fcntl.h:1, from /usr/include/linux/fcntl.h:4, from /usr/include/linux/signalfd.h:13, from work.c:31: /usr/include/asm-generic/fcntl.h:117: error: redefinition of ‘struct flock’ /usr/include/asm-generic/fcntl.h:140: error: redefinition of ‘struct flock64’ make[1]: *** [work.o] Error 1 make[1]: Leaving directory `/home/shiny/Packages/sheepdog-2009102101/sheep' make: *** [all] Error 2 I have all the required libs installed. Patching and compiling qemu-kvm went flawless. - Original Message - From: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp To: k...@vger.kernel.org, qemu-devel@nongnu.org, linux-fsde...@vger.kernel.org Sent: Wednesday, October 21, 2009 8:13:47 AM Subject: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM Hi everyone, Sheepdog is a distributed storage system for KVM/QEMU. It provides highly available block level storage volumes to VMs like Amazon EBS. Sheepdog supports advanced volume management features such as snapshot, cloning, and thin provisioning. Sheepdog runs on several tens or hundreds of nodes, and the architecture is fully symmetric; there is no central node such as a meta-data server. The following list describes the features of Sheepdog. * Linear scalability in performance and capacity * No single point of failure * Redundant architecture (data is written to multiple nodes) - Tolerance against network failure * Zero configuration (newly added machines will join the cluster automatically) - Autonomous load balancing * Snapshot - Online snapshot from qemu-monitor * Clone from a snapshot volume * Thin provisioning - Amazon EBS API support (to use from a Eucalyptus instance) (* = current features, - = on our todo list) More details and download links are here: http://www.osrg.net/sheepdog/ Note that the code is still in an early stage. There are some critical TODO items: - VM image deletion support - Support architectures other than X86_64 - Data recoverys - Free space management - Guarantee reliability and availability under heavy load - Performance improvement - Reclaim unused blocks - More documentation We hope finding people interested in working together. Enjoy! Here are examples: - create images $ kvm-img create -f sheepdog Alice's Disk 256G $ kvm-img create -f sheepdog Bob's Disk 256G - list images $ shepherd info -t vdi 4 : Alice's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 16:17:18, tag: 0, current 8 : Bob's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 16:29:20, tag: 0, current - start up a virtual machine $ kvm --drive format=sheepdog,file=Alice's Disk - create a snapshot $ kvm-img snapshot -c name sheepdog:Alice's Disk - clone from a snapshot $ kvm-img create -b sheepdog:Alice's
Re: [Qemu-devel] [PATCH 00/15] Some networking code re-organization
On Thu, 2009-10-22 at 15:34 -0500, Anthony Liguori wrote: Mark McLoughlin wrote: Hey, We've been meaning to split net.c up for quite a while now, so here goes with a first cut at. There shouldn't be anything too controversial here, apart from CONFIG_LINUX maybe. I've build tested this on F11, F12 and mingw and also done some basic runtime testing. Building on e.g. *BSD, Solaris and AIX hasn't been tested. I wouldn't be surprised if I've broken the build there despite all my efforts but, if I have, it should be trivial to fix back up. This isn't the end of the cleanups; obviously the other backends could be split out too, we could use module construtors, etc. This series doesn't build for me. I get dependency errors even after a full rebuild. I'm building from a separate directory fwiw. Don't see it here, I'm afraid - any more details? Btw, it's all pushed to http://repo.or.cz/w/qemu/markmc.git if that helps Cheers, Mark.
[Qemu-devel] Re: [PATCH 00/15] Some networking code re-organization
On Thu, 2009-10-22 at 20:53 +0200, Juan Quintela wrote: Mark McLoughlin mar...@redhat.com wrote: Hey, We've been meaning to split net.c up for quite a while now, so here goes with a first cut at. If you have to respin this series, please use git mv foo.c net/foo.c I did, looks like I needed to use 'git format-patch -M' Cheers, Mark.
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
We use JGroups (Java library) for reliable multicast communication in our cluster manager daemon. We don't worry about the performance much since the cluster manager daemon is not involved in the I/O path. We might think about moving to corosync if it is more stable than JGroups. On Wed, Oct 21, 2009 at 6:08 PM, Dietmar Maurer diet...@proxmox.com wrote: Quite interesting. But would it be possible to use corosync for the cluster communication? The point is that we need corosync anyways for pacemaker, it is written in C (high performance) and seem to implement the feature you need? -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of MORITA Kazutaka Sent: Mittwoch, 21. Oktober 2009 07:14 To: k...@vger.kernel.org; qemu-devel@nongnu.org; linux- fsde...@vger.kernel.org Subject: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM Hi everyone, Sheepdog is a distributed storage system for KVM/QEMU. It provides highly available block level storage volumes to VMs like Amazon EBS. Sheepdog supports advanced volume management features such as snapshot, cloning, and thin provisioning. Sheepdog runs on several tens or hundreds of nodes, and the architecture is fully symmetric; there is no central node such as a meta-data server. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- MORITA, Kazutaka NTT Cyber Space Labs OSS Computing Project Kernel Group E-mail: morita.kazut...@lab.ntt.co.jp
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
MORITA Kazutaka morita.kazut...@lab.ntt.co.jp writes: We use JGroups (Java library) for reliable multicast communication in our cluster manager daemon. We don't worry about the performance much since the cluster manager daemon is not involved in the I/O path. We might think about moving to corosync if it is more stable than JGroups. I'd love to see this running on top of corosync too. Corosync is a well tested, stable cluster manager, and doesn't have the JVM dependency of jgroups so feels more suitable for building 'thin virtualisation fabrics'. Cheers, Chris.
[Qemu-devel] Support for new target emulator
Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. Besides looking at sources for other targets in qemu tar ball, I have gone through docs for information on how to start adding support for a new target. I will appreciate if someone can give additional pointers on this. Also, kindly let me know the rough estimate of adding basic support to a new target like AVR32. There are some threads in Qemu user forums regarding the same. However, link for Qemu user forums is currently reporting a lost connection to mysql server (for the past 4 days?). I did a basic search on Qemu developer mailing list archives and I could not find a relevant thread yet. Thanks Anitha
Re: [Qemu-devel] Support for new target emulator
On 23.10.2009, at 12:50, Boyapati, Anitha wrote: Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. I would suggest you try and do this on Linux first. You'll see why below. Besides looking at sources for other targets in qemu tar ball, I have gone through docs for information on how to start adding support for a new target. I will appreciate if someone can give additional pointers on this. Also, kindly let me know the rough estimate of adding basic support to a new target like AVR32. Luckily Uli just added support for s390x, so you can take a look at his patchset and see what needs to be done. There are some threads in Qemu user forums regarding the same. However, link for Qemu user forums is currently reporting a lost connection to mysql server (for the past 4 days?). I did a basic search on Qemu developer mailing list archives and I could not find a relevant thread yet. I don't know about the user forum, but you should really take a look at his patchset. The reason you should try to do things on Linux is that it's a lot easier to implement a user-mode target than a system emulation target. So if I were you, I'd start off by implementing an AVR32 Linux userspace target. Apart from the syscall translation that should be almost completely a subset of the system emulation. Once you have found your user mode emulation to work, you can start implementing the softmmu and privileged opcodes. Also, you'll need some sort of machine you're running on then. So if I were you again, I'd implement a typical AVR32 developer board emulation. It's great to see someone from Atmel actually taking on the challenge! I'd love to see AVR32 support in Qemu. It's FWIW the only completely missing major target. Alex
Re: [Qemu-devel] Support for new target emulator
Boyapati, Anitha kirjoitti: Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. Besides looking at sources for other targets in qemu tar ball, I have gone through docs for information on how to start adding support for a new target. I will appreciate if someone can give additional pointers on this. Also, kindly let me know the rough estimate of adding basic support to a new target like AVR32. There are some threads in Qemu user forums regarding the same. However, link for Qemu user forums is currently reporting a lost connection to mysql server (for the past 4 days?). I did a basic search on Qemu developer mailing list archives and I could not find a relevant thread yet. The forums are up. (for some reason the database didn't come up automatically after reboot) Pablo
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On 23.10.2009, at 12:41, MORITA Kazutaka wrote: On Fri, Oct 23, 2009 at 12:30 AM, Avi Kivity a...@redhat.com wrote: How is load balancing implemented? Can you move an image transparently while a guest is running? Will an image be moved closer to its guest? Sheepdog uses consistent hashing to decide where objects store; I/O load is balanced across the nodes. When a new node is added or the existing node is removed, the hash table changes and the data automatically and transparently are moved over nodes. We plan to implement a mechanism to distribute the data not randomly but intelligently; we could use machine load, the locations of VMs, etc. What exactly does balanced mean? Can it cope with individual nodes having more disk space than others? Do you support multiple guests accessing the same image? A VM image can be attached to any VMs but one VM at a time; multiple running VMs cannot access to the same VM image. What about read-only access? Imagine you'd have 5 kvm instances each accessing it using -snapshot. Great project btw! Alex
[Qemu-devel] RE: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
We use JGroups (Java library) for reliable multicast communication in our cluster manager daemon. I doubt that there is something like 'reliable multicast' - you will run into many problems when you try to handle errors. We don't worry about the performance much since the cluster manager daemon is not involved in the I/O path. We might think about moving to corosync if it is more stable than JGroups. corosync is already quite stable. And it support virtual synchrony http://en.wikipedia.org/wiki/Virtual_synchrony Anyways, I do not know JGroups - maybe that 'reliable multicast' solves all network problems somehow - Is there any documentation about how they do it? - Dietmar
Re: [Qemu-devel] Support for new target emulator
On Friday 23 October 2009 13:03:54 Alexander Graf wrote: On 23.10.2009, at 12:50, Boyapati, Anitha wrote: Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. I would suggest you try and do this on Linux first. Why is wrong with *BSD or OpenSolaris in your eyes ? Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632
Re: [Qemu-devel] Support for new target emulator
On 23.10.2009, at 13:18, Christoph Egger wrote: On Friday 23 October 2009 13:03:54 Alexander Graf wrote: On 23.10.2009, at 12:50, Boyapati, Anitha wrote: Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. I would suggest you try and do this on Linux first. Why is wrong with *BSD or OpenSolaris in your eyes ? Nothing is wrong there, the Linux user mode target is simply the best tested one. Alex
[Qemu-devel] RE: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Another suggestion: use LVM instead of btrfs (to get better performance)
[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
On Fri, Oct 23, 2009 at 2:40 PM, Kevin Wolf kw...@redhat.com wrote: I really hate this You don't need this, I know it better attitude. If it were only for the technical arguments, okay - I can understand that you don't want to add another magic key, and yes, doing it dynamically comes with some complexity. But all this talking about non-existent problems makes me think that you don't... really care about what users want if they are the wrong users (yes, I admit, this one is useful more likely for developers and plain qemu users than for those running their servers in KVM - but they are still users, right?) OK, everybody, please calm down please remember that this thread started from my simple patch that wants to implement something that I personally feel useful. So, from both pros and cons side, I try to read and study your arguments. Meanwhile, I have another idea. I admit I never redirect Qemu monitor to certain char device. perhaps, if I could simply write a HOWTO on how to use this feature to implement simple monitor shortcuts, then it will be acceptable solution. I imagine the steps would be: 1. redirect monitor to a certain char device 2. make a script that send commands to this device 3. bind new KDE or GNOME shortcuts to call this script. Critics? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
Re: [Qemu-devel] Support for new target emulator
On Fri, Oct 23, 2009 at 1:18 PM, Christoph Egger christoph.eg...@amd.com wrote: On Friday 23 October 2009 13:03:54 Alexander Graf wrote: On 23.10.2009, at 12:50, Boyapati, Anitha wrote: Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. I would suggest you try and do this on Linux first. Why is wrong with *BSD or OpenSolaris in your eyes ? Their lack of AVR32 port? Laurent
[Qemu-devel] RE: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Anyways, I do not know JGroups - maybe that 'reliable multicast' solves all network problems somehow - Is there any documentation about how they do it? OK, found the papers on their web site - quite interesting too.
[Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
Am 23.10.2009 13:23, schrieb Mulyadi Santosa: On Fri, Oct 23, 2009 at 2:40 PM, Kevin Wolf kw...@redhat.com wrote: I really hate this You don't need this, I know it better attitude. If it were only for the technical arguments, okay - I can understand that you don't want to add another magic key, and yes, doing it dynamically comes with some complexity. But all this talking about non-existent problems makes me think that you don't... really care about what users want if they are the wrong users (yes, I admit, this one is useful more likely for developers and plain qemu users than for those running their servers in KVM - but they are still users, right?) OK, everybody, please calm down please remember that this thread started from my simple patch that wants to implement something that I personally feel useful. So, from both pros and cons side, I try to read and study your arguments. Meanwhile, I have another idea. I admit I never redirect Qemu monitor to certain char device. perhaps, if I could simply write a HOWTO on how to use this feature to implement simple monitor shortcuts, then it will be acceptable solution. I imagine the steps would be: 1. redirect monitor to a certain char device 2. make a script that send commands to this device 3. bind new KDE or GNOME shortcuts to call this script. Well, the whole point of a keyboard shortcut was for me to make things easier. Having to pass -monitor with the right magic file, writing a script and assigning a global (!) shortcut isn't exactly what I would call easier. I can keep using the monitor manually on TCP then. Kevin
[Qemu-devel] [PATCH v3] TCG x86: implement lzcnt emulation
lzcnt is a AMD Phenom/Barcelona added instruction returning the
number of leading zero bits in a word.
As this is similar to the bsr instruction, reuse the existing
code. There need to be some more changes, though, as lzcnt always
returns a valid value (in opposite to bsr, which has a special
case when the operand is 0).
lzcnt is guarded by the ABM CPUID bit (Fn8000_0001:ECX_5).
Signed-off-by: Andre Przywara andre.przyw...@amd.com
---
target-i386/helper.h|1 +
target-i386/op_helper.c | 14 --
target-i386/translate.c | 37 +
3 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/target-i386/helper.h b/target-i386/helper.h
index ca953f4..6b518ad 100644
--- a/target-i386/helper.h
+++ b/target-i386/helper.h
@@ -193,6 +193,7 @@ DEF_HELPER_2(fxsave, void, tl, int)
DEF_HELPER_2(fxrstor, void, tl, int)
DEF_HELPER_1(bsf, tl, tl)
DEF_HELPER_1(bsr, tl, tl)
+DEF_HELPER_2(lzcnt, tl, tl, int)
/* MMX/SSE */
diff --git a/target-i386/op_helper.c b/target-i386/op_helper.c
index 26fe612..5eea322 100644
--- a/target-i386/op_helper.c
+++ b/target-i386/op_helper.c
@@ -5479,11 +5479,14 @@ target_ulong helper_bsf(target_ulong t0)
return count;
}
-target_ulong helper_bsr(target_ulong t0)
+target_ulong helper_lzcnt(target_ulong t0, int wordsize)
{
int count;
target_ulong res, mask;
-
+
+if (wordsize 0 t0 == 0) {
+return wordsize;
+}
res = t0;
count = TARGET_LONG_BITS - 1;
mask = (target_ulong)1 (TARGET_LONG_BITS - 1);
@@ -5491,9 +5494,16 @@ target_ulong helper_bsr(target_ulong t0)
count--;
res = 1;
}
+if (wordsize 0) {
+return wordsize - 1 - count;
+}
return count;
}
+target_ulong helper_bsr(target_ulong t0)
+{
+ return helper_lzcnt(t0, 0);
+}
static int compute_all_eflags(void)
{
diff --git a/target-i386/translate.c b/target-i386/translate.c
index 2511943..64bc0a3 100644
--- a/target-i386/translate.c
+++ b/target-i386/translate.c
@@ -6573,23 +6573,36 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
ot = dflag + OT_WORD;
modrm = ldub_code(s-pc++);
reg = ((modrm 3) 7) | rex_r;
-gen_ldst_modrm(s, modrm, ot, OR_TMP0, 0);
+gen_ldst_modrm(s,modrm, ot, OR_TMP0, 0);
gen_extu(ot, cpu_T[0]);
-label1 = gen_new_label();
-tcg_gen_movi_tl(cpu_cc_dst, 0);
t0 = tcg_temp_local_new();
tcg_gen_mov_tl(t0, cpu_T[0]);
-tcg_gen_brcondi_tl(TCG_COND_EQ, t0, 0, label1);
-if (b 1) {
-gen_helper_bsr(cpu_T[0], t0);
+if ((b 1) (prefixes PREFIX_REPZ)
+(s-cpuid_ext3_features CPUID_EXT3_ABM)) {
+switch(ot) {
+case OT_WORD: gen_helper_lzcnt(cpu_T[0], t0,
+tcg_const_i32(16)); break;
+case OT_LONG: gen_helper_lzcnt(cpu_T[0], t0,
+tcg_const_i32(32)); break;
+case OT_QUAD: gen_helper_lzcnt(cpu_T[0], t0,
+tcg_const_i32(64)); break;
+}
+gen_op_mov_reg_T0(ot, reg);
} else {
-gen_helper_bsf(cpu_T[0], t0);
+label1 = gen_new_label();
+tcg_gen_movi_tl(cpu_cc_dst, 0);
+tcg_gen_brcondi_tl(TCG_COND_EQ, t0, 0, label1);
+if (b 1) {
+gen_helper_bsr(cpu_T[0], t0);
+} else {
+gen_helper_bsf(cpu_T[0], t0);
+}
+gen_op_mov_reg_T0(ot, reg);
+tcg_gen_movi_tl(cpu_cc_dst, 1);
+gen_set_label(label1);
+tcg_gen_discard_tl(cpu_cc_src);
+s-cc_op = CC_OP_LOGICB + ot;
}
-gen_op_mov_reg_T0(ot, reg);
-tcg_gen_movi_tl(cpu_cc_dst, 1);
-gen_set_label(label1);
-tcg_gen_discard_tl(cpu_cc_src);
-s-cc_op = CC_OP_LOGICB + ot;
tcg_temp_free(t0);
}
break;
--
1.6.4
Re: [Qemu-devel] Support for new target emulator
On 23.10.2009, at 13:44, Laurent Desnogues wrote: On Fri, Oct 23, 2009 at 1:18 PM, Christoph Egger christoph.eg...@amd.com wrote: On Friday 23 October 2009 13:03:54 Alexander Graf wrote: On 23.10.2009, at 12:50, Boyapati, Anitha wrote: Hello, We have a proposal to add support for AVR32 target emulation in Qemu. So far, we are able to build qemu from sources on windows using Mingw. I would suggest you try and do this on Linux first. Why is wrong with *BSD or OpenSolaris in your eyes ? Their lack of AVR32 port? Hey, at least someone tried: http://mail-index.netbsd.org/port-avr32/ :-) Alex
RE: [Qemu-devel] Support for new target emulator
On 23.10.2009, at 12:50, Boyapati, Anitha wrote: Luckily Uli just added support for s390x, so you can take a look at his patchset and see what needs to be done. Yes. Recent S390x support should give us a good idea. The reason you should try to do things on Linux is that it's a lot easier to implement a user-mode target than a system emulation target. So if I were you, I'd start off by implementing an AVR32 Linux userspace target. Apart from the syscall translation that should be almost completely a subset of the system emulation. Once you have found your user mode emulation to work, you can start implementing the softmmu and privileged opcodes. Also, you'll need some sort of machine you're running on then. So if I were you again, I'd implement a typical AVR32 developer board emulation. This definitely sounds logical. Thanks for the immediate response. It's great to see someone from Atmel actually taking on the challenge! I'd love to see AVR32 support in Qemu. It's FWIW the only completely missing major target. It was in queue for sometime now. As there is very little support for AVR32 emulation, it has become increasingly important to have a full-fledged AVR32 emulator. Hence QEMU. Regards Anitha
Re: [Qemu-devel] Support for new target emulator
On 23.10.2009, at 14:20, Boyapati, Anitha wrote: It's great to see someone from Atmel actually taking on the challenge! I'd love to see AVR32 support in Qemu. It's FWIW the only completely missing major target. It was in queue for sometime now. As there is very little support for AVR32 emulation, it has become increasingly important to have a full-fledged AVR32 emulator. Hence QEMU. Great choice :-). Btw now that I have someone from Atmel who apparently knows the architecture: Would virtualization work on AVR32? I mean, is there anything that would keep you from running kernel code in user mode and just trap everything? I really know very little about AVR32, probably due to the fact that it's still a missing target in Qemu :-). Alex
[Qemu-devel] Re: [PATCH 00/20] Port audio to vmstate
malc av1...@comtv.ru wrote:
On Thu, 22 Oct 2009, Juan Quintela wrote:
Hi
- es1370: the best working with migration.
- adlib: I am not able to get sound out of it on any recent Fedora :(
It's an FM chip, trying to play PCM with it just not gonna fly.
That could expain it :)
I disabled dma_running before loading state. malc can you take a look
here?
Can you please elaborate on what is exactly the problem.
What we have here:
On save_state, we save a state field:
val = s-dma_running; qemu_put_be32s (f, val);
Now on load state, we read it to one local variable:
qemu_get_be32s (f, dma_running);
My understanding of the code here is that you should never assign
directly s-dma_running, that you should set/clean it through
cs_reset_voices()
(setting this value has _side-effects_
So far so good.
Now, the whole point of vmstate is:
- state is described declaratively
- and load/save are kind of inverse functions. One save
the value of one field to the state, and the other takes the value
from the state and put it back in the field.
- Later (post_load), we do any side-effect that we need to do with the
new loaded state.
Here we can't do this. How would I do it in any other driver, i.e. (no
audio). Easy, you just declare dma_running_vmstate in the state, and
in post_load(), you just call cs_reset_voices depending on that value.
You already ruled out that solution on ac97. Didn't even try here.
No problem, I just read it on s-dma_running(), and on post_load I do:
if (s-dma_running (s-dregs[Interface_Configuration] PEN)) {
s-dma_running = 0;
cs_reset_voices (s, s-dregs[FS_And_Playback_Data_Format]);
}
And call it a day :).
But then I thought of what happens if you call loadvm from the monitor
while s-dma_running = 1.
And decided that the proper thing to do is to do:
in pre_load()
- we set dma_running to 0 if if it 1, but do it like in
cs_reset_voices()
if (s-dma_running) {
DMA_release_DREQ (s-dma);
AUD_set_active_out (s-voice, 0);
}
s-dma_running = 0;
And now, in post_load, we know that s-dma_runing is what was comes from
migration, and we can set it to this value. Do you think that my
explanation is clear?
Discussing this with Anthony on irc, he thinks that dma_running is the
same that (s-dregs[Interface_Configuration] PEN), and that we could
remove it from the state, but I am not sure, nad decided not to go that
route (because I am not sure, not because it is not the same. I don't know).
- ac97: from Anthony sugestion, remove the use of active array, it can be
recalculated. All my testing (muted, not muted, ..., shows that
transmited array is the same one than the recalculated one).
Good.
ac97 don't work always with migration.
How did I test:
- start a linux guest
- inside there play a song (ogg123 foo.ogg)
- in the middle of the song do savevm foo
- later restart qemu with -loadvm foo option
What did I expect?:
- I expected after ending the loadvm to hear the contination of the song.
Actual results:
- es1370: the one working better
- sb16: lots of underruns, very low sound quality.
- ac97: mixed results. The 1st 5-10 seconds always sound perfect
Then, between 10 and 30 seconds, sometimes it lots syncs and start
playing at
full speed, basiaclly no sound ouput. No sound after this is ever
generated.
If it is able to generate sound for 30-40 seconds, then sound works
correctly.
I tried to debug this, enabled all the audio DEBUG*, but I didn't find
what is
happening.
Notice that this happens when I launch from the same savevm image. Some
times
it works well, some times it stops working at 5 seconds, sometimes it stops
working at 10 seconds, and so on.
My theory is that we are not saving all the state that we need, but I have
been
unable to found anything obviosu here. malc, do you have any suggestion?
a. See how it behaves when you use OSS on the guest instead
(might need clocking=48000 module parameter)
b. http://mpxplay.sourceforge.net/ is the DOS player which knows about
i810 audio, see how it fares there
This took a lot because the ac97 testing, I thouguht the ac97
problems were due to my changes. It just happened that the 1st time
that I loaded without my changes it just worked :( Problem can be
reproduced as easily without any of my changes. More work needs to
be done to be sure that ac97 migrates correctly, but that is
independent of this patch :)
I don't like vmstate, but if you are dead bent on adding it to audio,
knock yourself out, IO_READ/WRITE_PROTO will stay. Can't help with
migration, GUS/Adlib are better tested with DOS and as for cs4231a i
don't quite understand what you are asking.
ok, will integrate the vmstate changes, and leave the
IO_READ/WRITE_PROTO until there are consensous about that :)
Later, Juan.
[Qemu-devel] Re: [PATCH 00/20] Port audio to vmstate
On Fri, 23 Oct 2009, Juan Quintela wrote:
malc av1...@comtv.ru wrote:
On Thu, 22 Oct 2009, Juan Quintela wrote:
Hi
- es1370: the best working with migration.
- adlib: I am not able to get sound out of it on any recent Fedora :(
It's an FM chip, trying to play PCM with it just not gonna fly.
That could expain it :)
I disabled dma_running before loading state. malc can you take a look
here?
Can you please elaborate on what is exactly the problem.
What we have here:
On save_state, we save a state field:
val = s-dma_running; qemu_put_be32s (f, val);
Now on load state, we read it to one local variable:
qemu_get_be32s (f, dma_running);
My understanding of the code here is that you should never assign
directly s-dma_running, that you should set/clean it through
cs_reset_voices()
(setting this value has _side-effects_
Okay, i've looked at the code dma_running is basically a flag which is
sortof redundant but for the lack of better interface tells us whether
we have DREQ asserted, nothing more nothing less.
So far so good.
Now, the whole point of vmstate is:
- state is described declaratively
- and load/save are kind of inverse functions. One save
the value of one field to the state, and the other takes the value
from the state and put it back in the field.
- Later (post_load), we do any side-effect that we need to do with the
new loaded state.
Here we can't do this. How would I do it in any other driver, i.e. (no
audio). Easy, you just declare dma_running_vmstate in the state, and
in post_load(), you just call cs_reset_voices depending on that value.
You already ruled out that solution on ac97. Didn't even try here.
No problem, I just read it on s-dma_running(), and on post_load I do:
if (s-dma_running (s-dregs[Interface_Configuration] PEN)) {
s-dma_running = 0;
cs_reset_voices (s, s-dregs[FS_And_Playback_Data_Format]);
}
And call it a day :).
But then I thought of what happens if you call loadvm from the monitor
while s-dma_running = 1.
And decided that the proper thing to do is to do:
in pre_load()
- we set dma_running to 0 if if it 1, but do it like in
cs_reset_voices()
if (s-dma_running) {
DMA_release_DREQ (s-dma);
AUD_set_active_out (s-voice, 0);
}
s-dma_running = 0;
And now, in post_load, we know that s-dma_runing is what was comes from
migration, and we can set it to this value. Do you think that my
explanation is clear?
Sorry, i haven't slept in quite a while, so nothing makes any sense
currently, i'll try to do a mental exercise of running it solely
inside my brain sometime later.
Discussing this with Anthony on irc, he thinks that dma_running is the
same that (s-dregs[Interface_Configuration] PEN), and that we could
remove it from the state, but I am not sure, nad decided not to go that
route (because I am not sure, not because it is not the same. I don't know).
It's not quite the same as Iconf PEN (see for instance PPIO
handling, or lack thereof)
[..snip..]
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH] target-arm: use clz32() instead of a for loop
On Fri, Oct 23, 2009 at 09:04:53AM +0200, Aurelien Jarno wrote: Stuart Brady a écrit : Just a quick note that the implementation of clz, ctz and popcnt is still listed in the TCG TODO list. The last time I looked, I noticed that quite a few architectures have clz/ctz instructions: http://lkml.indiana.edu/hypermail/linux/kernel/0601.3/1683.html OTOH, a dump shows that those instruction are not used than often, so I am not sure it worth implementing it. Really? I'm surprised, as I gather that optimised ffs/fls/hweight functions in the kernel do give a modest gain... I suppose I'll have to try it on several different targets and see! :-) For those that don't, I think a combination the following two hacks at http://graphics.stanford.edu/~seander/bithacks.html could be used: The best is probably to use an helper in that case, calling clz32(x). Yes, you're right. There are several other places that should also call clz32()/ctz32(). The ones that I can see are helper_neon_cls_s32() for ARM, helper_bsf() and helper_bsr() for X86, helper_ff1() for M68K. (I'm not sure about 'do_clz8' and 'do_clz16', though.) At some point, possibly next weekend, I'll submit patches to add clz and ctz helpers to tcg-runtime.c, and to convert Alpha, ARM, CRIS, M68K, MIPS, PowerPC and x86 (any others I've missed?) to use those helpers. Cheers, -- Stuart Brady
[Qemu-devel] audio segfault in qemu-kvm-0.11.0
Hi, Any ideas on this segfault a Fedora 12 user (Gene, cc-ed) is seeing? Thread 1 (Thread 2849): #0 0x7f25fcd10f70 in memset () from /lib64/libc.so.6 No symbol table info available. #1 0x004babc6 in audio_capture_mix_and_clear (samples=-1099358712, rpos=value optimized out, hw=value optimized out) at audio/audio.c:1290 n = -1099358712 #2 audio_run_out (samples=-1099358712, rpos=value optimized out, hw=value optimized out) at audio/audio.c:1354 live = value optimized out free = value optimized out nb_live = 1 ---Type return to continue, or q return to quit--- cleanup_required = value optimized out played = value optimized out hw = value optimized out sw = value optimized out #3 audio_timer (samples=-1099358712, rpos=value optimized out, hw=value optimized out) at audio/audio.c:1482 s = 0xbb6a20 #4 0x0040a82a in qemu_run_timers (current_time=value optimized out, ptimer_head=0x8322b8) at /usr/src/debug/qemu-kvm-0.11.0/vl.c:1036 ts = value optimized out Full details here: https://bugzilla.redhat.com/528754 and backtrace here: https://bugzilla.redhat.com/attachment.cgi?id=365541 Thanks, Mark.
[Qemu-devel] Re: audio segfault in qemu-kvm-0.11.0
On Fri, 23 Oct 2009, Mark McLoughlin wrote: Hi, Any ideas on this segfault a Fedora 12 user (Gene, cc-ed) is seeing? Thread 1 (Thread 2849): #0 0x7f25fcd10f70 in memset () from /lib64/libc.so.6 No symbol table info available. #1 0x004babc6 in audio_capture_mix_and_clear (samples=-1099358712, rpos=value optimized out, hw=value optimized out) at audio/audio.c:1290 n = -1099358712 #2 audio_run_out (samples=-1099358712, rpos=value optimized out, hw=value optimized out) at audio/audio.c:1354 I don't even know what this is, there's no audio_run_out at 1354 furthermore signature is completely different.. In any case, this backtrace is useless, everything is optimized out. live = value optimized out free = value optimized out nb_live = 1 ---Type return to continue, or q return to quit--- cleanup_required = value optimized out played = value optimized out hw = value optimized out sw = value optimized out #3 audio_timer (samples=-1099358712, rpos=value optimized out, hw=value optimized out) at audio/audio.c:1482 s = 0xbb6a20 #4 0x0040a82a in qemu_run_timers (current_time=value optimized out, ptimer_head=0x8322b8) at /usr/src/debug/qemu-kvm-0.11.0/vl.c:1036 ts = value optimized out Full details here: https://bugzilla.redhat.com/528754 and backtrace here: https://bugzilla.redhat.com/attachment.cgi?id=365541 Summary: No idea. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Re: audio segfault in qemu-kvm-0.11.0
On Fri, 23 Oct 2009, malc wrote: On Fri, 23 Oct 2009, Mark McLoughlin wrote: Hi, Any ideas on this segfault a Fedora 12 user (Gene, cc-ed) is seeing? [..snip..] Summary: No idea. FWIW, there's no information whatosever about what audio hardware was built and enabled, what sound system was used on the host/guest the report is devoid of any useful information (given the state of the backtrace) -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 00/15] Some networking code re-organization
Mark McLoughlin wrote: On Thu, 2009-10-22 at 15:34 -0500, Anthony Liguori wrote: This series doesn't build for me. I get dependency errors even after a full rebuild. I'm building from a separate directory fwiw. Don't see it here, I'm afraid - any more details? Btw, it's all pushed to http://repo.or.cz/w/qemu/markmc.git if that helps Building master of that tree. Source code is in /home/anthony/git/qemu. Build dir is /home/anthony/obj/qemu-tmp. Configure line is ~/git/qemu/configure --kerneldir=/home/anthony/git/kvm-userspace/kernel. Attached the make V=1 output and configure output. Regards, Anthony Liguori Install prefix/usr/local BIOS directory/usr/local/share/qemu binary directory /usr/local/bin Manual directory /usr/local/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /home/anthony/git/qemu C compilergcc Host C compiler gcc CFLAGS-O2 -g QEMU_CFLAGS -Werror -Wold-style-definition -Wold-style-declaration -I. -I$(SRC_PATH) -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -m64 LDFLAGS -Wl,--warn-common -g -m64 make make install install host CPU x86_64 host big endian no target list i386-softmmu x86_64-softmmu arm-softmmu cris-softmmu m68k-softmmu microblaze-softmmu mips-softmmu mipsel-softmmu mips64-softmmu mips64el-softmmu ppc-softmmu ppcemb-softmmu ppc64-softmmu sh4-softmmu sh4eb-softmmu sparc-softmmu sparc64-softmmu i386-linux-user x86_64-linux-user alpha-linux-user arm-linux-user armeb-linux-user cris-linux-user m68k-linux-user microblaze-linux-user mips-linux-user mipsel-linux-user ppc-linux-user ppc64-linux-user ppc64abi32-linux-user sh4-linux-user sh4eb-linux-user sparc-linux-user sparc64-linux-user sparc32plus-linux-user tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no -Werror enabled yes SDL support yes curses supportyes curl support yes check support no mingw32 support no Audio drivers oss Extra audio cards ac97 es1370 sb16 Mixer emulation no VNC TLS support yes VNC SASL support yes xen support no brlapi supportyes bluez supportno Documentation yes NPTL support yes GUEST_BASEyes PIE user targets no vde support yes IO thread no Linux AIO support yes Install blobs yes KVM support yes fdt support no preadv supportno fdatasync yes uuid support yes cat i386-softmmu/config-devices.mak x86_64-softmmu/config-devices.mak arm-softmmu/config-devices.mak cris-softmmu/config-devices.mak m68k-softmmu/config-devices.mak microblaze-softmmu/config-devices.mak mips-softmmu/config-devices.mak mipsel-softmmu/config-devices.mak mips64-softmmu/config-devices.mak mips64el-softmmu/config-devices.mak ppc-softmmu/config-devices.mak ppcemb-softmmu/config-devices.mak ppc64-softmmu/config-devices.mak sh4-softmmu/config-devices.mak sh4eb-softmmu/config-devices.mak sparc-softmmu/config-devices.mak sparc64-softmmu/config-devices.mak i386-linux-user/config-devices.mak x86_64-linux-user/config-devices.mak alpha-linux-user/config-devices.mak arm-linux-user/config-devices.mak armeb-linux-user/config-devices.mak cris-linux-user/config-devices.mak m68k-linux-user/config-devices.mak microblaze-linux-user/config-devices.mak mips-linux-user/config-devices.mak mipsel-linux-user/config-devices.mak ppc-linux-user/config-devices.mak ppc64-linux-user/config-devices.mak ppc64abi32-linux-user/config-devices.mak sh4-linux-user/config-devices.mak sh4eb-linux-user/config-devices.mak sparc-linux-user/config-devices.mak sparc64-linux-user/config-devices.mak sparc32plus-linux-user/config-devices.mak | grep =y$ | sort -u config-all-devices.mak /home/anthony/git/qemu/create_config config-host.mak config-host.h-timestamp /home/anthony/git/qemu/create_config config-all-devices.mak config-all-devices.h-timestamp make qemu-nbd qemu-io qemu-img qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 recurse-all make[1]: Entering directory `/home/anthony/obj/qemu-tmp' gcc -I/home/anthony/git/qemu/slirp -Werror -Wold-style-definition -Wold-style-declaration -I. -I/home/anthony/git/qemu -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -m64 -MMD -MP -MT qemu-nbd.o -O2 -g -c -o qemu-nbd.o /home/anthony/git/qemu/qemu-nbd.c gcc -I/home/anthony/git/qemu/slirp -Werror -Wold-style-definition -Wold-style-declaration -I. -I/home/anthony/git/qemu -U_FORTIFY_SOURCE -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall
Re: [Qemu-devel] Re: audio segfault in qemu-kvm-0.11.0
On Fri, 2009-10-23 at 17:41 +0400, malc wrote:
On Fri, 23 Oct 2009, malc wrote:
On Fri, 23 Oct 2009, Mark McLoughlin wrote:
Hi,
Any ideas on this segfault a Fedora 12 user (Gene, cc-ed) is seeing?
[..snip..]
Summary: No idea.
FWIW, there's no information whatosever about what audio hardware was
built and enabled, what sound system was used on the host/guest the
report is devoid of any useful information (given the state of the
backtrace)
That's fine, we'd only be delighted to provide some more info.
Our tree is at http://repo.or.cz/w/qemu-kvm/fedora.git
It's based off the stable-0.11 branch
Code is:
if (played) {
hw-ts_helper += played;
audio_capture_mix_and_clear (hw, prev_rpos, played);
}
If it would help you, I could ask Gene to reproduce with a -O0 build
Built with --audio-drv-list=pa,sdl,alsa,oss
Command line was:
QEMU_AUDIO_DRV=none qemu-kvm ... -soundhw es1370
Not a lot of info on exactly what the guest is doing with sound, only
that they are Fedora 11 or Fedora 12 guests
Thanks,
Mark.
Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
Kevin Wolf wrote: Well, the whole point of a keyboard shortcut was for me to make things easier. This is something of a classic debate between providing power users every possible knob and function verses overwhelming non-power users with so many features/options that they cannot even get started. My big problem with keyboard shortcuts is that they are a really awful user interface for anything because they are not discoverable (without consulting documentation) and they provide no obvious feedback as to what state they are in. For instance, imagine creating a shortcut based on a monitor macro of 'migrate exec:dd of=snapshot.img' and you tie it to ctrl-alt-e. What feedback do you get that the command has completed? What happens if you try to run the command again while another is running? Does it get queued, does it get dropped? I can imagine a user sitting there hitting ctrl-alt-e repeatedly not realizing anything is happening. I know I find myself doing this sometimes with ctrl-a when using -nographic. Your answer may be, this is for a developer and they'll be aware of all the short comings/gotchas but this ends up being a rather user-hostile interface. People are never as aware of short comings/gotchas as we'd like them to be. If there was no other way for a developer to do this, I'd be more inclined to find a way to support this but it's just a matter of writing a script or if you really need a short cut, you can do it with standard gnome short cuts or write a very simple vnc client based on gvncviewer (we're talking a dozen lines of added code) to do this for you. Regards, Anthony Liguori
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On Fri, Oct 23, 2009 at 5:41 AM, MORITA Kazutaka morita.kazut...@lab.ntt.co.jp wrote: On Fri, Oct 23, 2009 at 12:30 AM, Avi Kivity a...@redhat.com wrote: If so, is it reasonable to compare this to a cluster file system setup (like GFS) with images as files on this filesystem? The difference would be that clustering is implemented in userspace in sheepdog, but in the kernel for a clustering filesystem. I think that the major difference between sheepdog and cluster file systems such as Google File system, pNFS, etc is the interface between clients and a storage system. note that GFS is Global File System (written by Sistina (the same folks from LVM) and bought by RedHat). Google Filesystem is a different thing, and ironically the client/storage interface is a little more like sheepdog and unlike a regular cluster filesystem. How is load balancing implemented? Can you move an image transparently while a guest is running? Will an image be moved closer to its guest? Sheepdog uses consistent hashing to decide where objects store; I/O load is balanced across the nodes. When a new node is added or the existing node is removed, the hash table changes and the data automatically and transparently are moved over nodes. We plan to implement a mechanism to distribute the data not randomly but intelligently; we could use machine load, the locations of VMs, etc. i don't have much hands-on experience on consistent hashing; but it sounds reasonable to make each node's ring segment proportional to its storage capacity. dynamic load balancing seems a tougher nut to crack, especially while keeping all clients mapping consistent. Do you support multiple guests accessing the same image? A VM image can be attached to any VMs but one VM at a time; multiple running VMs cannot access to the same VM image. this is a must-have safety measure; but a 'manual override' is quite useful for those that know how to manage a cluster-aware filesystem inside a VM image, maybe like Xen's w! flag does. justs be sure to avoid distributed caching for a shared image! in all, great project, and with such a clean patch into KVM/Qemu, high hopes of making into regular use. i'd just want to add my '+1 votes' on both getting rid of JVM dependency and using block devices (usually LVM) instead of ext3/btrfs -- Javier
Re: [Qemu-devel] Re: audio segfault in qemu-kvm-0.11.0
On Fri, 23 Oct 2009, Mark McLoughlin wrote:
On Fri, 2009-10-23 at 17:41 +0400, malc wrote:
On Fri, 23 Oct 2009, malc wrote:
On Fri, 23 Oct 2009, Mark McLoughlin wrote:
Hi,
Any ideas on this segfault a Fedora 12 user (Gene, cc-ed) is seeing?
[..snip..]
Summary: No idea.
FWIW, there's no information whatosever about what audio hardware was
built and enabled, what sound system was used on the host/guest the
report is devoid of any useful information (given the state of the
backtrace)
That's fine, we'd only be delighted to provide some more info.
Our tree is at http://repo.or.cz/w/qemu-kvm/fedora.git
It's based off the stable-0.11 branch
Code is:
if (played) {
hw-ts_helper += played;
audio_capture_mix_and_clear (hw, prev_rpos, played);
}
If it would help you, I could ask Gene to reproduce with a -O0 build
Yes, that'd be nice.
Built with --audio-drv-list=pa,sdl,alsa,oss
Command line was:
QEMU_AUDIO_DRV=none qemu-kvm ... -soundhw es1370
Not a lot of info on exactly what the guest is doing with sound, only
that they are Fedora 11 or Fedora 12 guests
Can Gene try to reproduce it with plain QEMU?
--
mailto:av1...@comtv.ru
Re: [Qemu-devel] Re: [PATCH] new SDL keyboard shortcuts to start and stop VM
Am 23.10.2009 15:59, schrieb Anthony Liguori: Kevin Wolf wrote: Well, the whole point of a keyboard shortcut was for me to make things easier. This is something of a classic debate between providing power users every possible knob and function verses overwhelming non-power users with so many features/options that they cannot even get started. You mean the additional monitor commands would overwhelm the non-power users who can cope with the existing commands? This is a subjective thing, so I can't contradict, but I'm not sure if I come to the same conclusion. Do non-power users even use the monitor? My big problem with keyboard shortcuts is that they are a really awful user interface for anything because they are not discoverable (without consulting documentation) and they provide no obvious feedback as to what state they are in. Right, with our interface they are not discoverable. I didn't know about Ctrl-Alt-U, for example. But if I can list them in the monitor and even more if I'm defining the shortcuts myself I'm pretty confident that I can remember them. For instance, imagine creating a shortcut based on a monitor macro of 'migrate exec:dd of=snapshot.img' and you tie it to ctrl-alt-e. What feedback do you get that the command has completed? What happens if you try to run the command again while another is running? Does it get queued, does it get dropped? I can imagine a user sitting there hitting ctrl-alt-e repeatedly not realizing anything is happening. I know I find myself doing this sometimes with ctrl-a when using -nographic. The user has created that ctrl-alt-e mapping himself, so he should know how to use the monitor. He even knows the syntax of migrate, so chances are that he also knows what it's doing. Your answer may be, this is for a developer and they'll be aware of all the short comings/gotchas but this ends up being a rather user-hostile interface. People are never as aware of short comings/gotchas as we'd like them to be. If there was no other way for a developer to do this, I'd be more inclined to find a way to support this but it's just a matter of writing a script or if you really need a short cut, you can do it with standard gnome short cuts or write a very simple vnc client based on gvncviewer (we're talking a dozen lines of added code) to do this for you. No, sorry, before I start writing a VNC viewer I'd rather keep a local patch around. ;-) But I really don't feel like continuing this discussion as I don't see anyone who could be convinced to change his opinion. I have one opinion, you have a different one, maintainer wins. Let's move on to more productive things. Kevin
Re: [Qemu-devel] [PATCH] target-arm: use clz32() instead of a for loop
Stuart Brady a écrit : On Fri, Oct 23, 2009 at 09:04:53AM +0200, Aurelien Jarno wrote: Stuart Brady a écrit : Just a quick note that the implementation of clz, ctz and popcnt is still listed in the TCG TODO list. The last time I looked, I noticed that quite a few architectures have clz/ctz instructions: http://lkml.indiana.edu/hypermail/linux/kernel/0601.3/1683.html OTOH, a dump shows that those instruction are not used than often, so I am not sure it worth implementing it. Really? I'm surprised, as I gather that optimised ffs/fls/hweight functions in the kernel do give a modest gain... I suppose I'll have to try it on several different targets and see! :-) I gave a quick look at MIPS, and at least here, it is used often. For those that don't, I think a combination the following two hacks at http://graphics.stanford.edu/~seander/bithacks.html could be used: The best is probably to use an helper in that case, calling clz32(x). Yes, you're right. There are several other places that should also call clz32()/ctz32(). The ones that I can see are helper_neon_cls_s32() for ARM, helper_bsf() and helper_bsr() for X86, helper_ff1() for M68K. (I'm not sure about 'do_clz8' and 'do_clz16', though.) At some point, possibly next weekend, I'll submit patches to add clz and ctz helpers to tcg-runtime.c, and to convert Alpha, ARM, CRIS, M68K, MIPS, PowerPC and x86 (any others I've missed?) to use those helpers. The main problem I see for a TCG implementation is the definition of clz/ctz. Some targets define that clz(0) or ctz(0) returns 32, some other define it as being undefined. If we go for the common denominator for the TCG op, that is clz(0) = undefined, it means that a test with brcond has to be added in the targets using clz(0) = 32, and this is likely to give more slow down than speed gain. If we go for clz(0) = 32, it means the test has to be implemented in TCG, which might be complicated for some hosts. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
This looks very interesting - how does this compare with Exanodes/Seanodes? Thanks, Avishay
Re: [Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Javier Guerra jav...@guerrag.com writes: i'd just want to add my '+1 votes' on both getting rid of JVM dependency and using block devices (usually LVM) instead of ext3/btrfs If the chunks into which the virtual drives are split are quite small (say the 64MB used by Hadoop), LVM may be a less appropriate choice. It doesn't support very large numbers of very small logical volumes very well. Best wishes, Chris.
Re: [Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On Fri, Oct 23, 2009 at 9:58 AM, Chris Webb ch...@arachsys.com wrote: If the chunks into which the virtual drives are split are quite small (say the 64MB used by Hadoop), LVM may be a less appropriate choice. It doesn't support very large numbers of very small logical volumes very well. absolutely. the 'nicest' way to do it would be to use a single block device per sheep process, and do the splitting there. it's an extra layer of code, and once you add non-naïve behavior for deleting and fragmentation, you quickly approach filesystem-like complexity. unless you can do some very clever mapping that reuses the consistent hash algorithms to find not only which server(s) you want, but also which chunk to hit the kind of things i'd love to code, but never found the use for it. i'll definitely dig deeper in the code. -- Javier
Re: [Qemu-devel] [PATCH 1/5] linux-user: remove hardcoded value of _NSIG in signal.c
Stefan Weil a écrit :
Aurelien Jarno schrieb:
From: Arnaud Patard arnaud.pat...@rtp-net.org
In a bunch of places, 64 is used as value of _NSIG but it's wrong
at least on MIPS were _NSIG is 128.
Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
---
linux-user/signal.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 2df17aa..6620ce3 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -44,7 +44,7 @@ static struct target_sigaction sigact_table[TARGET_NSIG];
static void host_signal_handler(int host_signum, siginfo_t *info,
void *puc);
-static uint8_t host_to_target_signal_table[65] = {
+static uint8_t host_to_target_signal_table[_NSIG+1] = {
[SIGHUP] = TARGET_SIGHUP,
[SIGINT] = TARGET_SIGINT,
[SIGQUIT] = TARGET_SIGQUIT,
@@ -87,7 +87,7 @@ static uint8_t host_to_target_signal_table[65] = {
[__SIGRTMIN] = __SIGRTMAX,
[__SIGRTMAX] = __SIGRTMIN,
};
-static uint8_t target_to_host_signal_table[65];
+static uint8_t target_to_host_signal_table[_NSIG+1];
static inline int on_sig_stack(unsigned long sp)
{
@@ -103,14 +103,14 @@ static inline int sas_ss_flags(unsigned long sp)
int host_to_target_signal(int sig)
{
-if (sig 64)
+if (sig _NSIG)
return sig;
return host_to_target_signal_table[sig];
}
int target_to_host_signal(int sig)
{
-if (sig 64)
+if (sig _NSIG)
return sig;
return target_to_host_signal_table[sig];
}
@@ -311,11 +311,11 @@ void signal_init(void)
int host_sig;
/* generate signal conversion tables */
-for(i = 1; i = 64; i++) {
+for(i = 1; i = _NSIG; i++) {
if (host_to_target_signal_table[i] == 0)
host_to_target_signal_table[i] = i;
}
-for(i = 1; i = 64; i++) {
+for(i = 1; i = _NSIG; i++) {
j = host_to_target_signal_table[i];
target_to_host_signal_table[j] = i;
}
At least in my linux installation, _NSIG is 65 (x86) or 128 (mips),
so the patch above should replace 64 by (_NSIG - 1) and 65 by _NSIG.
But perhaps it does no harm if the code allocates an unused signal
at the end.
For my tests with mips host and tci, I used
static uint8_t target_to_host_signal_table[_NSIG]
From /usr/include/bits/signum.h:
#define _NSIG 65 /* Biggest signal number + 1
I confirm that all use of _NSIG of them should be decremented by one.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 10/12] target-arm: replace tcg_gen_rori_i32 by tcg_gen_rotri_i32
On Wed, Oct 21, 2009 at 12:18:08PM +0200, juha.riihim...@nokia.com wrote:
Use native rotation if possible instead of a simulated one.
I have another patch in my local tree that handle more cases:
commit 04df13497befdb79c778d82d0901d290d164d250
Author: Aurelien Jarno aurel...@aurel32.net
Date: Thu Oct 15 16:45:14 2009 +0200
target-arm: use native tcg-ops for ror/bic/vorn
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
diff --git a/target-arm/helpers.h b/target-arm/helpers.h
index f298eff..4d07e0c 100644
--- a/target-arm/helpers.h
+++ b/target-arm/helpers.h
@@ -151,7 +151,6 @@ DEF_HELPER_2(sbc_cc, i32, i32, i32)
DEF_HELPER_2(shl, i32, i32, i32)
DEF_HELPER_2(shr, i32, i32, i32)
DEF_HELPER_2(sar, i32, i32, i32)
-DEF_HELPER_2(ror, i32, i32, i32)
DEF_HELPER_2(shl_cc, i32, i32, i32)
DEF_HELPER_2(shr_cc, i32, i32, i32)
DEF_HELPER_2(sar_cc, i32, i32, i32)
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index 5ac631d..9b1a014 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -379,14 +379,6 @@ uint32_t HELPER(sar)(uint32_t x, uint32_t i)
return (int32_t)x shift;
}
-uint32_t HELPER(ror)(uint32_t x, uint32_t i)
-{
-int shift = i 0xff;
-if (shift == 0)
-return x;
-return (x shift) | (x (32 - shift));
-}
-
uint32_t HELPER(shl_cc)(uint32_t x, uint32_t i)
{
int shift = i 0xff;
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 9d13d42..2721a22 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -405,34 +405,9 @@ static void gen_sub_carry(TCGv dest, TCGv t0, TCGv t1)
dead_tmp(tmp);
}
-/* T0 = ~T1. Clobbers T1. */
-/* FIXME: Implement bic natively. */
-static inline void tcg_gen_bic_i32(TCGv dest, TCGv t0, TCGv t1)
-{
-TCGv tmp = new_tmp();
-tcg_gen_not_i32(tmp, t1);
-tcg_gen_and_i32(dest, t0, tmp);
-dead_tmp(tmp);
-}
-
/* FIXME: Implement this natively. */
#define tcg_gen_abs_i32(t0, t1) gen_helper_abs(t0, t1)
-/* FIXME: Implement this natively. */
-static void tcg_gen_rori_i32(TCGv t0, TCGv t1, int i)
-{
-TCGv tmp;
-
-if (i == 0)
-return;
-
-tmp = new_tmp();
-tcg_gen_shri_i32(tmp, t1, i);
-tcg_gen_shli_i32(t1, t1, 32 - i);
-tcg_gen_or_i32(t0, t1, tmp);
-dead_tmp(tmp);
-}
-
static void shifter_out_im(TCGv var, int shift)
{
TCGv tmp = new_tmp();
@@ -484,7 +459,7 @@ static inline void gen_arm_shift_im(TCGv var, int shiftop,
int shift, int flags)
if (shift != 0) {
if (flags)
shifter_out_im(var, shift - 1);
-tcg_gen_rori_i32(var, var, shift); break;
+tcg_gen_rotri_i32(var, var, shift); break;
} else {
TCGv tmp = load_cpu_field(CF);
if (flags)
@@ -512,7 +487,8 @@ static inline void gen_arm_shift_reg(TCGv var, int shiftop,
case 0: gen_helper_shl(var, var, shift); break;
case 1: gen_helper_shr(var, var, shift); break;
case 2: gen_helper_sar(var, var, shift); break;
-case 3: gen_helper_ror(var, var, shift); break;
+case 3: tcg_gen_andi_i32(shift, shift, 0x1f);
+tcg_gen_rotr_i32(var, var, shift); break;
}
}
dead_tmp(shift);
@@ -1442,7 +1418,7 @@ static int disas_iwmmxt_insn(CPUState *env, DisasContext
*s, uint32_t insn)
case ARM_IWMMXT_wCSSF:
tmp = iwmmxt_load_creg(wrd);
tmp2 = load_reg(s, rd);
-tcg_gen_bic_i32(tmp, tmp, tmp2);
+tcg_gen_andc_i32(tmp, tmp, tmp2);
dead_tmp(tmp2);
iwmmxt_store_creg(wrd, tmp);
break;
@@ -3899,7 +3875,7 @@ static int disas_neon_ls_insn(CPUState * env,
DisasContext *s, uint32_t insn)
static void gen_neon_bsl(TCGv dest, TCGv t, TCGv f, TCGv c)
{
tcg_gen_and_i32(t, t, c);
-tcg_gen_bic_i32(f, f, c);
+tcg_gen_andc_i32(f, f, c);
tcg_gen_or_i32(dest, t, f);
}
@@ -4212,14 +4188,13 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
tcg_gen_and_i32(tmp, tmp, tmp2);
break;
case 1: /* BIC */
-tcg_gen_bic_i32(tmp, tmp, tmp2);
+tcg_gen_andc_i32(tmp, tmp, tmp2);
break;
case 2: /* VORR */
tcg_gen_or_i32(tmp, tmp, tmp2);
break;
case 3: /* VORN */
-tcg_gen_not_i32(tmp2, tmp2);
-tcg_gen_or_i32(tmp, tmp, tmp2);
+tcg_gen_orc_i32(tmp, tmp, tmp2);
break;
case 4: /* VEOR */
tcg_gen_xor_i32(tmp, tmp, tmp2);
@@ -6274,7 +6249,7 @@ static void disas_arm_insn(CPUState * env, DisasContext
*s)
}
break;
case 0x0e:
-tcg_gen_bic_i32(tmp, tmp, tmp2);
+tcg_gen_andc_i32(tmp, tmp, tmp2);
if (logic_cc) {
gen_logic_CC(tmp);
}
@@ -6605,7 +6580,7 @@ static void
Re: [Qemu-devel] [PATCH 10/12] target-arm: replace tcg_gen_rori_i32 by tcg_gen_rotri_i32
On Fri, Oct 23, 2009 at 5:25 PM, Aurelien Jarno aurel...@aurel32.net wrote:
On Wed, Oct 21, 2009 at 12:18:08PM +0200, juha.riihim...@nokia.com wrote:
Use native rotation if possible instead of a simulated one.
I have another patch in my local tree that handle more cases:
commit 04df13497befdb79c778d82d0901d290d164d250
Author: Aurelien Jarno aurel...@aurel32.net
Date: Thu Oct 15 16:45:14 2009 +0200
target-arm: use native tcg-ops for ror/bic/vorn
Signed-off-by: Aurelien Jarno aurel...@aurel32.net
Acked-by: Laurent Desnogues laurent.desnog...@gmail.com
diff --git a/target-arm/helpers.h b/target-arm/helpers.h
index f298eff..4d07e0c 100644
--- a/target-arm/helpers.h
+++ b/target-arm/helpers.h
@@ -151,7 +151,6 @@ DEF_HELPER_2(sbc_cc, i32, i32, i32)
DEF_HELPER_2(shl, i32, i32, i32)
DEF_HELPER_2(shr, i32, i32, i32)
DEF_HELPER_2(sar, i32, i32, i32)
-DEF_HELPER_2(ror, i32, i32, i32)
DEF_HELPER_2(shl_cc, i32, i32, i32)
DEF_HELPER_2(shr_cc, i32, i32, i32)
DEF_HELPER_2(sar_cc, i32, i32, i32)
diff --git a/target-arm/op_helper.c b/target-arm/op_helper.c
index 5ac631d..9b1a014 100644
--- a/target-arm/op_helper.c
+++ b/target-arm/op_helper.c
@@ -379,14 +379,6 @@ uint32_t HELPER(sar)(uint32_t x, uint32_t i)
return (int32_t)x shift;
}
-uint32_t HELPER(ror)(uint32_t x, uint32_t i)
-{
- int shift = i 0xff;
- if (shift == 0)
- return x;
- return (x shift) | (x (32 - shift));
-}
-
uint32_t HELPER(shl_cc)(uint32_t x, uint32_t i)
{
int shift = i 0xff;
diff --git a/target-arm/translate.c b/target-arm/translate.c
index 9d13d42..2721a22 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -405,34 +405,9 @@ static void gen_sub_carry(TCGv dest, TCGv t0, TCGv t1)
dead_tmp(tmp);
}
-/* T0 = ~T1. Clobbers T1. */
-/* FIXME: Implement bic natively. */
-static inline void tcg_gen_bic_i32(TCGv dest, TCGv t0, TCGv t1)
-{
- TCGv tmp = new_tmp();
- tcg_gen_not_i32(tmp, t1);
- tcg_gen_and_i32(dest, t0, tmp);
- dead_tmp(tmp);
-}
-
/* FIXME: Implement this natively. */
#define tcg_gen_abs_i32(t0, t1) gen_helper_abs(t0, t1)
-/* FIXME: Implement this natively. */
-static void tcg_gen_rori_i32(TCGv t0, TCGv t1, int i)
-{
- TCGv tmp;
-
- if (i == 0)
- return;
-
- tmp = new_tmp();
- tcg_gen_shri_i32(tmp, t1, i);
- tcg_gen_shli_i32(t1, t1, 32 - i);
- tcg_gen_or_i32(t0, t1, tmp);
- dead_tmp(tmp);
-}
-
static void shifter_out_im(TCGv var, int shift)
{
TCGv tmp = new_tmp();
@@ -484,7 +459,7 @@ static inline void gen_arm_shift_im(TCGv var, int
shiftop, int shift, int flags)
if (shift != 0) {
if (flags)
shifter_out_im(var, shift - 1);
- tcg_gen_rori_i32(var, var, shift); break;
+ tcg_gen_rotri_i32(var, var, shift); break;
} else {
TCGv tmp = load_cpu_field(CF);
if (flags)
@@ -512,7 +487,8 @@ static inline void gen_arm_shift_reg(TCGv var, int
shiftop,
case 0: gen_helper_shl(var, var, shift); break;
case 1: gen_helper_shr(var, var, shift); break;
case 2: gen_helper_sar(var, var, shift); break;
- case 3: gen_helper_ror(var, var, shift); break;
+ case 3: tcg_gen_andi_i32(shift, shift, 0x1f);
+ tcg_gen_rotr_i32(var, var, shift); break;
}
}
dead_tmp(shift);
@@ -1442,7 +1418,7 @@ static int disas_iwmmxt_insn(CPUState *env,
DisasContext *s, uint32_t insn)
case ARM_IWMMXT_wCSSF:
tmp = iwmmxt_load_creg(wrd);
tmp2 = load_reg(s, rd);
- tcg_gen_bic_i32(tmp, tmp, tmp2);
+ tcg_gen_andc_i32(tmp, tmp, tmp2);
dead_tmp(tmp2);
iwmmxt_store_creg(wrd, tmp);
break;
@@ -3899,7 +3875,7 @@ static int disas_neon_ls_insn(CPUState * env,
DisasContext *s, uint32_t insn)
static void gen_neon_bsl(TCGv dest, TCGv t, TCGv f, TCGv c)
{
tcg_gen_and_i32(t, t, c);
- tcg_gen_bic_i32(f, f, c);
+ tcg_gen_andc_i32(f, f, c);
tcg_gen_or_i32(dest, t, f);
}
@@ -4212,14 +4188,13 @@ static int disas_neon_data_insn(CPUState * env,
DisasContext *s, uint32_t insn)
tcg_gen_and_i32(tmp, tmp, tmp2);
break;
case 1: /* BIC */
- tcg_gen_bic_i32(tmp, tmp, tmp2);
+ tcg_gen_andc_i32(tmp, tmp, tmp2);
break;
case 2: /* VORR */
tcg_gen_or_i32(tmp, tmp, tmp2);
break;
case 3: /* VORN */
- tcg_gen_not_i32(tmp2, tmp2);
- tcg_gen_or_i32(tmp, tmp, tmp2);
+ tcg_gen_orc_i32(tmp, tmp, tmp2);
break;
case 4: /* VEOR */
tcg_gen_xor_i32(tmp, tmp, tmp2);
@@ -6274,7 +6249,7 @@ static void disas_arm_insn(CPUState * env, DisasContext
*s)
}
break;
Re: [Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On Fri, Oct 23, 2009 at 8:10 PM, Alexander Graf ag...@suse.de wrote: On 23.10.2009, at 12:41, MORITA Kazutaka wrote: On Fri, Oct 23, 2009 at 12:30 AM, Avi Kivity a...@redhat.com wrote: How is load balancing implemented? Can you move an image transparently while a guest is running? Will an image be moved closer to its guest? Sheepdog uses consistent hashing to decide where objects store; I/O load is balanced across the nodes. When a new node is added or the existing node is removed, the hash table changes and the data automatically and transparently are moved over nodes. We plan to implement a mechanism to distribute the data not randomly but intelligently; we could use machine load, the locations of VMs, etc. What exactly does balanced mean? Can it cope with individual nodes having more disk space than others? I mean objects are uniformly distributed over the nodes by the hash function. Distribution using free disk space information is one of TODOs. Do you support multiple guests accessing the same image? A VM image can be attached to any VMs but one VM at a time; multiple running VMs cannot access to the same VM image. What about read-only access? Imagine you'd have 5 kvm instances each accessing it using -snapshot. By creating new clone images from existing snapshot image, you can do the similar thing. Sheepdog can create cloning image instantly. -- MORITA, Kazutaka NTT Cyber Space Labs OSS Computing Project Kernel Group E-mail: morita.kazut...@lab.ntt.co.jp
[Qemu-devel] net packet storms with multiple NICs
Hello. I vaguely remember something like this has been reported and/or discussed already, but I can't find anything related. I'm also not sure if it's kvm-specific or exists in qemu too. I want some clarification wrt vlan= parameter in -net definition. What started this all is a problem report I had with kvm package. It turns out that the OP had 2 network adaptors defined for one of his guests, and right when his guest started getting an IP address over DHCP for one of them, the network saw huge packet storm consisting of DHCP and ARP packets. I immediately reproduced the problem locally. It turns out that kvm reflects packets coming from one guest NIC on another guest NIC, and since both are connected to the same bridge we're getting endless packet storm. To a level when kvm process becomes 100% busy and does not respond to anything but `kill -9'. The problem is easily solvable by specifying explicit different vlan indexes for different pairs of host/guest -net components. I've two questions: o what's the intended usage of all-vlan-equal case, when kvm (or qemu) reflects packets from one interface to another? It's what bridge in linux is for, I think. o why different -net guest -net host pairs are not getting different vlan= indexes by default, to stop the above-mentioned packet storms right away? I think it's a wise default to assign different pairs to different vlans, by counting -net host and -net guest sequences. Thanks! /mjt
Re: [Qemu-devel] net packet storms with multiple NICs
On Fri, 2009-10-23 at 20:25 +0400, Michael Tokarev wrote: I've two questions: o what's the intended usage of all-vlan-equal case, when kvm (or qemu) reflects packets from one interface to another? It's what bridge in linux is for, I think. I don't think it's necessarily an intended use-case for the vlan feature o why different -net guest -net host pairs are not getting different vlan= indexes by default, to stop the above-mentioned packet storms right away? I think it's a wise default to assign different pairs to different vlans, by counting -net host and -net guest sequences. With 0.12, we're going to be de-emphasising the vlan feature and instead have NICs directly connected to host backends. The vlan feature will be just another host backend, but optional You'll start guests with e.g.: -netdev tap,id=tap.0 -device virtio-net-pci,netdev=tap.0 Cheers, Mark.
Re: [Qemu-devel] [PATCH 00/15] Some networking code re-organization
On Fri, 2009-10-23 at 08:44 -0500, Anthony Liguori wrote: Mark McLoughlin wrote: On Thu, 2009-10-22 at 15:34 -0500, Anthony Liguori wrote: This series doesn't build for me. I get dependency errors even after a full rebuild. I'm building from a separate directory fwiw. Don't see it here, I'm afraid - any more details? Btw, it's all pushed to http://repo.or.cz/w/qemu/markmc.git if that helps Building master of that tree. Source code is in /home/anthony/git/qemu. Build dir is /home/anthony/obj/qemu-tmp. Configure line is ~/git/qemu/configure --kerneldir=/home/anthony/git/kvm-userspace/kernel. Attached the make V=1 output and configure output. Thanks, I'll add using a separate build dir to my test matrix :) Incremental patch below, will post a v2 of 01/15, also pushed to net-cleanup.v2 branch Thanks, Mark. diff --git a/Makefile b/Makefile index 44bd7ef..41107a5 100644 --- a/Makefile +++ b/Makefile @@ -229,7 +229,7 @@ clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f *.o *.d *.a $(TOOLS) TAGS cscope.* *.pod *~ */*~ - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d + rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d rm -f qemu-img-cmds.h $(MAKE) -C tests clean for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser; do \ @@ -413,4 +413,4 @@ tarbin: $(mandir)/man8/qemu-nbd.8 # Include automatically generated dependency files --include $(wildcard *.d audio/*.d slirp/*.d block/*.d) +-include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d) diff --git a/configure b/configure index 4ccdebe..b9fc32b 100755 --- a/configure +++ b/configure @@ -2533,7 +2533,7 @@ done # for target in $targets # build tree in object directory if source path is different from current one if test $source_path_used = yes ; then -DIRS=tests tests/cris slirp audio block pc-bios/optionrom +DIRS=tests tests/cris slirp audio block net pc-bios/optionrom DIRS=$DIRS roms/pcbios roms/seabios roms/vgabios FILES=Makefile tests/Makefile FILES=$FILES tests/cris/Makefile tests/cris/.gdbinit
[Qemu-devel] [PATCH 01/15 v2] net: move net-queue.[ch] under net/
[v2: handle building in a separate dir] Signed-off-by: Mark McLoughlin mar...@redhat.com --- Makefile | 10 +++--- configure |2 +- net.h |2 +- net-queue.c = net/queue.c |2 +- net-queue.h = net/queue.h |0 5 files changed, 10 insertions(+), 6 deletions(-) rename net-queue.c = net/queue.c (99%) rename net-queue.h = net/queue.h (100%) diff --git a/Makefile b/Makefile index e78a3d0..aea7756 100644 --- a/Makefile +++ b/Makefile @@ -86,6 +86,10 @@ block-nested-$(CONFIG_CURL) += curl.o block-obj-y += $(addprefix block/, $(block-nested-y)) +net-obj-y = net.o +net-nested-y = queue.o +net-obj-y += $(addprefix net/, $(net-nested-y)) + ## # libqemu_common.a: Target independent part of system emulation. The # long term path is to suppress *all* target specific code in case of @@ -93,6 +97,7 @@ block-obj-y += $(addprefix block/, $(block-nested-y)) # CPUs and machines. obj-y = $(block-obj-y) +obj-y += $(net-obj-y) obj-y += readline.o console.o obj-y += tcg-runtime.o host-utils.o @@ -121,7 +126,6 @@ obj-$(CONFIG_SD) += sd.o obj-y += bt.o bt-host.o bt-vhci.o bt-l2cap.o bt-sdp.o bt-hci.o bt-hid.o usb-bt.o obj-y += bt-hci-csr.o obj-y += buffered_file.o migration.o migration-tcp.o qemu-sockets.o -obj-y += net.o net-queue.o obj-y += qemu-char.o aio.o net-checksum.o savevm.o obj-y += msmouse.o ps2.o obj-y += qdev.o qdev-properties.o @@ -220,7 +224,7 @@ clean: # avoid old build problems by removing potentially incorrect old files rm -f config.mak op-i386.h opc-i386.h gen-op-i386.h op-arm.h opc-arm.h gen-op-arm.h rm -f *.o *.d *.a $(TOOLS) TAGS cscope.* *.pod *~ */*~ - rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d + rm -f slirp/*.o slirp/*.d audio/*.o audio/*.d block/*.o block/*.d net/*.o net/*.d rm -f qemu-img-cmds.h $(MAKE) -C tests clean for d in $(ALL_SUBDIRS) libhw32 libhw64 libuser; do \ @@ -404,4 +408,4 @@ tarbin: $(mandir)/man8/qemu-nbd.8 # Include automatically generated dependency files --include $(wildcard *.d audio/*.d slirp/*.d block/*.d) +-include $(wildcard *.d audio/*.d slirp/*.d block/*.d net/*.d) diff --git a/configure b/configure index 43d87c5..6b4faf6 100755 --- a/configure +++ b/configure @@ -2529,7 +2529,7 @@ done # for target in $targets # build tree in object directory if source path is different from current one if test $source_path_used = yes ; then -DIRS=tests tests/cris slirp audio block pc-bios/optionrom +DIRS=tests tests/cris slirp audio block net pc-bios/optionrom DIRS=$DIRS roms/pcbios roms/seabios roms/vgabios FILES=Makefile tests/Makefile FILES=$FILES tests/cris/Makefile tests/cris/.gdbinit diff --git a/net.h b/net.h index 7e6cbf4..9ebb978 100644 --- a/net.h +++ b/net.h @@ -5,7 +5,7 @@ #include qemu-common.h #include qdict.h #include qemu-option.h -#include net-queue.h +#include net/queue.h /* VLANs support */ diff --git a/net-queue.c b/net/queue.c similarity index 99% rename from net-queue.c rename to net/queue.c index f6b01e9..e91a9a5 100644 --- a/net-queue.c +++ b/net/queue.c @@ -21,7 +21,7 @@ * THE SOFTWARE. */ -#include net-queue.h +#include net/queue.h #include qemu-queue.h /* The delivery handler may only return zero if it will call diff --git a/net-queue.h b/net/queue.h similarity index 100% rename from net-queue.h rename to net/queue.h -- 1.6.2.5
[Qemu-devel] Re: net packet storms with multiple NICs
Andreas Plesner Jacobsen wrote:
On Fri, Oct 23, 2009 at 08:25:39PM +0400, Michael Tokarev wrote:
o why different -net guest -net host pairs are not getting different
vlan= indexes by default, to stop the above-mentioned packet
storms right away? I think it's a wise default to assign different
pairs to different vlans, by counting -net host and -net guest
sequences.
I think the major issue is that the definition of a pair is when the
vlan-options match. There's no requirement to define the two after each
other.
I mean something like this (rough approximation:
int host_vlan_no = 0, guest_vlan_no = 0;
while(parse_option()) {
if (option == host-side-net) {
if (!explicit_vlan) vlan = host_vlan_no;
++host_vlan_no;
}
if (option == guest-side-net) {
if (!explicit_vlan) vlan = guest_vlan_no;
++guest_vlan_no;
}
}
this way, consecutive host-side -net will receive
consecutive vlan=NN, and consecutive guest-side -net
also consecutive vlan=NN numbers.
But having in mind Marc's reply I don't think it's
necessary anymore.
Thanks!
/mjt
RE: [Qemu-devel] Support for new target emulator
Btw now that I have someone from Atmel who apparently knows the architecture: Would virtualization work on AVR32? I mean, is there anything that would keep you from running kernel code in user mode and just trap everything? Some attempts are going on with AP7 series. It is not the processor mode that poses a problem but the memory limitation. Memory footprint is the fat issue. Despite the fact that AP7 series has MMU and allows external 16-bit SRAM for additional memory, experience shows that virtualization still remains a fairly big challenge. UC3 series have no MMU at all. Except for UC3A, no other series has extended memory support either. AFAIK, it is mostly a closed alley. Anitha
Re: [Qemu-devel] Re: audio segfault in qemu-kvm-0.11.0
On Fri, 23 Oct 2009, Gene Czarcinski wrote: The real sound hardware should not be relevant since qemu-kvm current does not support sound and has it disabled even if, by default, there is an ES1370 virtual device defined. I don't know anything about qemu-kvm and mysterious ways it walks (by having audio stuff compiled in and yet somehow disabled) Nor do i quite frankly understand why -soundhw es1370 was specified on the command line. [..snip..] Can I reproduce the problem with qemu only (no kvm) ... If I could reproduce the problem at all, then maybe. I have no idea what causes the problem. All occurrences of the problem were on a previous install with qemu-kvm-0.11.0-6.fc12.x86_64. I am currently running F12-Beta with qemu-kvm-0.11.0-7.fc12.x86_64 but still have the old system just a re-boot away. At the time I was running (most likely) two guests ... an F11 and an F12 and the guest had been running for some time (the crash did not occur immediately or soon after guest start). I was certainly doing nothing with respect to sound since, as far as I was concerned, it did not work. I had five occurrences of qemu-kvm segfault (according to grep'ing /var/log/messages* between 6 October and 13 October and an addition occurrence on 19 October ... all with qemu-kvm -6. As far as I can tell, I only have abrt data from the 19 October occurrence. If this was a problem which I could cause on demand, this situation may be different ... but I don't. I have not had this problem occur on my fresh install of F12-Beta. I can bring up q qemu guest and let it sit but I am not sure what to do to cause the problem. Comments? Basically this - i've never seen this problem, nor to the best of my knowledge anyone else, the only way to understand what's going on is for you to try to reproduce it capture a backtrace, preferably with vanilla qemu, and in having optimizations disabled. -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [PATCH 04/11] Add json-qobject parser
On Sat, 17 Oct 2009 08:36:04 -0500 Anthony Liguori aligu...@us.ibm.com wrote: +QObject *qobject_from_json(const char *string, size_t *length); +QObject *qobject_from_jsonf(const char *string, size_t *length, ...) +__attribute__((__format__ (__printf__, 1, 3))); We need a wrapper for command handlers usage, they won't use 'length' and I think we can abort() on error if the only possibility of failing is a wrong syntax.
Re: [Qemu-devel] Re: [PATCH] tcg, tci: Add TCG and interpreter for bytecode (virtual machine)
TeLeMan schrieb: Tested i386-softmmu only. Now tci can run windows xp sp2 and its speed is about 6 times slower than jit. -- SUN OF A BEACH Great. Many thanks for the fixes, enhancements and for the testing, too. Is patch 4 (call handling) needed, or is it an optimization? If it is needed, the tcg disassembler has to be extended as well. And did patch 5 (inline) speed up the code? I had expected that static functions don't need inline, because the compiler can optimize them anyway. Regards, Stefan
Re: [Qemu-devel] [PATCH 02/11] Add support for qfloat
Anthony Liguori wrote: It really doesn't matter in the context of LGPL so I don't mind if we do 2.1 only. Is LGPL 2.1 compatible with LGPL 3 or GPL 3? It would be a shame if it's compatible enough to use in libvirt but can't be used in a GPL 3 project. I think the recent JSON + QObject stuff is nice enough it may be useful in other projects that have nothing to do with QEMU. -- Jamie
Re: [Qemu-devel] [PATCH 01/11] Add append method to qstring and empty constructor
Luiz Capitulino wrote:
qstring = qemu_malloc(sizeof(*qstring));
-qstring-string = qemu_strdup(str);
+
+qstring-length = strlen(str);
+qstring-capacity = qstring-length;
+
+qstring-string = qemu_malloc(qstring-capacity + 1);
+memcpy(qstring-string, str, qstring-length);
+qstring-string[qstring-length] = 0;
Couldn't this be:
qstring-string = qemu_strdup(str);
qstring-length = qstring-capacity = strlen(str);
Probably to have one call to strlen() instead of two (one inside
qemu_strdup()).
+void qstring_append(QString *qstring, const char *str)
+{
+size_t len = strlen(str);
+
+if (qstring-capacity (qstring-length + len)) {
+qstring-capacity += len;
+qstring-capacity *= 2; /* use exponential growth */
+
+qstring-string = qemu_realloc(qstring-string, qstring-capacity
+ 1);
+}
Why do we need to double it? Wouldn't be enough to only keep track
of the current string length and add 'len' to it? We could drop
'capacity' then.
You need exponential growth if large stringes are to be grown in O(n)
time where n is the number of characters, appended in small pieces.
Think about the time spent copying bytes every time qemu_realloc() is called.
If you just add 'len' each time, think about appending 1 byte 10^4
times. It will copy approximately 10^8/2 bytes, which is a lot just to
make a string 10^4 bytes long.
But += len; *= 2 is not necessary. *= 2 is enough, provided the
result is large enough.
+memcpy(qstring-string + qstring-length, str, len);
+qstring-length += len;
+qstring-string[qstring-length] = 0;
I would use strcat().
Again, that's an extra call to strlen(), traversing the string twice instead of
once.
Doesn't make much different for small strings, only large ones.
-- Jamie
Re: [Qemu-devel] [PATCH 02/11] Add support for qfloat
On Fri, Oct 23, 2009 at 08:25:49PM +0100, Jamie Lokier wrote: Anthony Liguori wrote: It really doesn't matter in the context of LGPL so I don't mind if we do 2.1 only. Is LGPL 2.1 compatible with LGPL 3 or GPL 3? It would be a shame if it's compatible enough to use in libvirt but can't be used in a GPL 3 project. LGPL 2.1 only is not suitable for libvirt actually. Our license is explicitly using LGPL v2.1 or later so that we can be compatible with apps using (L)GPL3 too. So yeah I'd really recommend using 2.1+ too Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Re: [Qemu-devel] [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Hi, Thanks for many comments. Sheepdog git trees are created. Sheepdog server git://sheepdog.git.sourceforge.net/gitroot/sheepdog/sheepdog Sheepdog client git://sheepdog.git.sourceforge.net/gitroot/sheepdog/qemu-kvm Please try! On Wed, Oct 21, 2009 at 2:13 PM, MORITA Kazutaka morita.kazut...@lab.ntt.co.jp wrote: Hi everyone, Sheepdog is a distributed storage system for KVM/QEMU. It provides highly available block level storage volumes to VMs like Amazon EBS. Sheepdog supports advanced volume management features such as snapshot, cloning, and thin provisioning. Sheepdog runs on several tens or hundreds of nodes, and the architecture is fully symmetric; there is no central node such as a meta-data server. The following list describes the features of Sheepdog. * Linear scalability in performance and capacity * No single point of failure * Redundant architecture (data is written to multiple nodes) - Tolerance against network failure * Zero configuration (newly added machines will join the cluster automatically) - Autonomous load balancing * Snapshot - Online snapshot from qemu-monitor * Clone from a snapshot volume * Thin provisioning - Amazon EBS API support (to use from a Eucalyptus instance) (* = current features, - = on our todo list) More details and download links are here: http://www.osrg.net/sheepdog/ Note that the code is still in an early stage. There are some critical TODO items: - VM image deletion support - Support architectures other than X86_64 - Data recoverys - Free space management - Guarantee reliability and availability under heavy load - Performance improvement - Reclaim unused blocks - More documentation We hope finding people interested in working together. Enjoy! Here are examples: - create images $ kvm-img create -f sheepdog Alice's Disk 256G $ kvm-img create -f sheepdog Bob's Disk 256G - list images $ shepherd info -t vdi 4 : Alice's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 16:17:18, tag: 0, current 8 : Bob's Disk 256 GB (allocated: 0 MB, shared: 0 MB), 2009-10-15 16:29:20, tag: 0, current - start up a virtual machine $ kvm --drive format=sheepdog,file=Alice's Disk - create a snapshot $ kvm-img snapshot -c name sheepdog:Alice's Disk - clone from a snapshot $ kvm-img create -b sheepdog:Alice's Disk:0 -f sheepdog Charlie's Disk Thanks. -- MORITA, Kazutaka NTT Cyber Space Labs OSS Computing Project Kernel Group E-mail: morita.kazut...@lab.ntt.co.jp -- MORITA, Kazutaka NTT Cyber Space Labs OSS Computing Project Kernel Group E-mail: morita.kazut...@lab.ntt.co.jp
Re: [Qemu-devel] [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On Fri, Oct 23, 2009 at 2:39 PM, MORITA Kazutaka morita.kazut...@lab.ntt.co.jp wrote: Thanks for many comments. Sheepdog git trees are created. great! is there any client (no matter how crude) besides the patched KVM/Qemu? it would make it far easier to hack around... -- Javier
Re: [Qemu-devel] Re: audio segfault in qemu-kvm-0.11.0
On Friday 23 October 2009 10:29:44 malc wrote:
On Fri, 23 Oct 2009, Mark McLoughlin wrote:
On Fri, 2009-10-23 at 17:41 +0400, malc wrote:
On Fri, 23 Oct 2009, malc wrote:
On Fri, 23 Oct 2009, Mark McLoughlin wrote:
Hi,
Any ideas on this segfault a Fedora 12 user (Gene, cc-ed) is
seeing?
[..snip..]
Summary: No idea.
FWIW, there's no information whatosever about what audio hardware was
built and enabled, what sound system was used on the host/guest the
report is devoid of any useful information (given the state of the
backtrace)
That's fine, we'd only be delighted to provide some more info.
Our tree is at http://repo.or.cz/w/qemu-kvm/fedora.git
It's based off the stable-0.11 branch
Code is:
if (played) {
hw-ts_helper += played;
audio_capture_mix_and_clear (hw, prev_rpos, played);
}
If it would help you, I could ask Gene to reproduce with a -O0 build
Yes, that'd be nice.
Built with --audio-drv-list=pa,sdl,alsa,oss
Command line was:
QEMU_AUDIO_DRV=none qemu-kvm ... -soundhw es1370
Not a lot of info on exactly what the guest is doing with sound, only
that they are Fedora 11 or Fedora 12 guests
Can Gene try to reproduce it with plain QEMU?
The real sound hardware should not be relevant since qemu-kvm current does not
support sound and has it disabled even if, by default, there is an ES1370
virtual device defined.
Nevertheless, the real hardware is (ASUS M4A78 PRO mobo):
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
Subsystem: ASUSTeK Computer Inc. Device 8346
Flags: bus master, slow devsel, latency 64, IRQ 16
Memory at fbbf4000 (64-bit, non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
01:05.1 Audio device: ATI Technologies Inc RS780 Azalia controller
Subsystem: ASUSTeK Computer Inc. Device 82f1
Flags: bus master, fast devsel, latency 0, IRQ 19
Memory at fbdfc000 (32-bit, non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: HDA Intel
Kernel modules: snd-hda-intel
Can I reproduce the problem with qemu only (no kvm) ... If I could reproduce
the problem at all, then maybe. I have no idea what causes the problem.
All occurrences of the problem were on a previous install with
qemu-kvm-0.11.0-6.fc12.x86_64.
I am currently running F12-Beta with qemu-kvm-0.11.0-7.fc12.x86_64 but still
have the old system just a re-boot away.
At the time I was running (most likely) two guests ... an F11 and an F12 and
the guest had been running for some time (the crash did not occur immediately
or soon after guest start). I was certainly doing nothing with respect to
sound since, as far as I was concerned, it did not work.
I had five occurrences of qemu-kvm segfault (according to grep'ing
/var/log/messages* between 6 October and 13 October and an addition occurrence
on 19 October ... all with qemu-kvm -6.
As far as I can tell, I only have abrt data from the 19 October occurrence.
If this was a problem which I could cause on demand, this situation may be
different ... but I don't. I have not had this problem occur on my fresh
install of F12-Beta.
I can bring up q qemu guest and let it sit but I am not sure what to do to
cause the problem.
Comments?
Gene
[Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On Fri, 23 Oct 2009 09:14:29 -0500 Javier Guerra jav...@guerrag.com wrote: I think that the major difference between sheepdog and cluster file systems such as Google File system, pNFS, etc is the interface between clients and a storage system. note that GFS is Global File System (written by Sistina (the same folks from LVM) and bought by RedHat). Google Filesystem is a different thing, and ironically the client/storage interface is a little more like sheepdog and unlike a regular cluster filesystem. Hmm, Avi referred to Global File System? I wasn't sure. 'GFS' is ambiguous. Anyway, Global File System is a SAN file system. It's a completely different architecture from Sheepdog. Sheepdog uses consistent hashing to decide where objects store; I/O load is balanced across the nodes. When a new node is added or the existing node is removed, the hash table changes and the data automatically and transparently are moved over nodes. We plan to implement a mechanism to distribute the data not randomly but intelligently; we could use machine load, the locations of VMs, etc. i don't have much hands-on experience on consistent hashing; but it sounds reasonable to make each node's ring segment proportional to its storage capacity. Yeah, that's one of the techniques, I think. dynamic load balancing seems a tougher nut to crack, especially while keeping all clients mapping consistent. There are some techniques to do that. We think that there are some existing techniques to distribute data intelligently. We just have not analyzed the options. i'd just want to add my '+1 votes' on both getting rid of JVM dependency and using block devices (usually LVM) instead of ext3/btrfs LVM doesn't fit for our requirement nicely. What we need is updating some objects in an atomic way. We can implement that for ourselves but we prefer to keep our code simple by using the existing mechanism.
[Qemu-devel] Re: net packet storms with multiple NICs
On Fri, Oct 23, 2009 at 08:25:39PM +0400, Michael Tokarev wrote: o why different -net guest -net host pairs are not getting different vlan= indexes by default, to stop the above-mentioned packet storms right away? I think it's a wise default to assign different pairs to different vlans, by counting -net host and -net guest sequences. I think the major issue is that the definition of a pair is when the vlan-options match. There's no requirement to define the two after each other. -- Andreas
Re: [Qemu-devel] Re: [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
Chris Webb wrote: Javier Guerra jav...@guerrag.com writes: i'd just want to add my '+1 votes' on both getting rid of JVM dependency and using block devices (usually LVM) instead of ext3/btrfs If the chunks into which the virtual drives are split are quite small (say the 64MB used by Hadoop), LVM may be a less appropriate choice. It doesn't support very large numbers of very small logical volumes very well. Also, on _loaded_ systems, I noticed creating/removing logical volumes can take really long (several minutes); where allocating a file of a given size would just take a fraction of that. Sot sure how it would matter here, but probably it would. -- Tomasz Chmielewski http://wpkg.org
Re: [Qemu-devel] [PATCH 06/12] target-arm: optimize arm load/store multiple ops
On Wed, Oct 21, 2009 at 12:17 PM, juha.riihim...@nokia.com wrote:
ARM load/store multiple instructions can be slightly optimized by
loading the register offset constant into a variable outside the
register loop and using the preloaded variable inside the loop instead
of reloading the offset value to a temporary variable on each loop
iteration. This causes less TCG ops to be generated for a ARM load/
store multiple instruction.
Signed-off-by: Juha Riihimäki juha.riihim...@nokia.com
Acked-by: Laurent Desnogues laurent.desnog...@gmail.com
---
diff --git a/target-arm/translate.c b/target-arm/translate.c
index e5a2881..bae1122 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -6852,6 +6852,7 @@ static void disas_arm_insn(CPUState * env,
DisasContext *s)
}
rn = (insn 16) 0xf;
addr = load_reg(s, rn);
+ tmp2 = tcg_const_i32(4);
/* compute total size */
loaded_base = 0;
@@ -6865,7 +6866,7 @@ static void disas_arm_insn(CPUState * env,
DisasContext *s)
if (insn (1 23)) {
if (insn (1 24)) {
/* pre increment */
- tcg_gen_addi_i32(addr, addr, 4);
+ tcg_gen_add_i32(addr, addr, tmp2);
} else {
/* post increment */
}
@@ -6918,7 +6919,7 @@ static void disas_arm_insn(CPUState * env,
DisasContext *s)
j++;
/* no need to add after the last transfer */
if (j != n)
- tcg_gen_addi_i32(addr, addr, 4);
+ tcg_gen_add_i32(addr, addr, tmp2);
}
}
if (insn (1 21)) {
@@ -6928,7 +6929,7 @@ static void disas_arm_insn(CPUState * env,
DisasContext *s)
/* pre increment */
} else {
/* post increment */
- tcg_gen_addi_i32(addr, addr, 4);
+ tcg_gen_add_i32(addr, addr, tmp2);
}
} else {
if (insn (1 24)) {
@@ -6944,6 +6945,7 @@ static void disas_arm_insn(CPUState * env,
DisasContext *s)
} else {
dead_tmp(addr);
}
+ tcg_temp_free_i32(tmp2);
if (loaded_base) {
store_reg(s, rn, loaded_var);
}
Laurent
Re: [Qemu-devel] [ANNOUNCE] Sheepdog: Distributed Storage System for KVM
On Sat, Oct 24, 2009 at 4:45 AM, Javier Guerra jav...@guerrag.com wrote: On Fri, Oct 23, 2009 at 2:39 PM, MORITA Kazutaka morita.kazut...@lab.ntt.co.jp wrote: Thanks for many comments. Sheepdog git trees are created. great! is there any client (no matter how crude) besides the patched KVM/Qemu? it would make it far easier to hack around... No, there isn't. Sorry. I think we should provide a test client as soon as possible. -- MORITA, Kazutaka NTT Cyber Space Labs OSS Computing Project Kernel Group E-mail: morita.kazut...@lab.ntt.co.jp
Re: [Qemu-devel] Re: [PATCH] tcg, tci: Add TCG and interpreter for bytecode (virtual machine)
On Sat, Oct 24, 2009 at 02:58, Stefan Weil w...@mail.berlios.de wrote: Is patch 4 (call handling) needed, or is it an optimization? If it is needed, the tcg disassembler has to be extended as well. In fact tci has no stack and robber registers and doesn't need simulate the CPU work. I am trying to remove tcg_reg_alloc() in tcg_reg_alloc_op() tcg_reg_alloc_call() and access the temporary variables directly in tci. And did patch 5 (inline) speed up the code? I had expected that static functions don't need inline, because the compiler can optimize them anyway. You are right, patch 5 is not needed.
