Re: [Qemu-devel] [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
Il 14/09/2012 00:27, Nicholas A. Bellinger ha scritto: *) Keep vhost-scsi as a backend to virtio-scsi-pci - Reduces duplicated code amongst multiple virtio-scsi backends. - Follows the split for what existing vhost-net code already does. So that said, two quick questions for Paolo Co.. For the standalone vhost-scsi-pci device case, can you give a brief idea as to what extent you'd like to see virtio-scsi.c code/defs duplicated and/or shared amongst a new vhost-scsi-pci device..? Not much, in the end, would be shared; it could end up being just parts of virtio_scsi_init and virtio_scsi_exit, and virtio_scsi_get_config. Almost all the other code is to implement the SCSI bus interface, which you do not need. I don't remember if and how vhost handles configuration changes. If you need any struct in virtio-scsi.c, either move it to virtio-scsi.h or add the new device in the same file. Also to help me along, can you give an example based on the current usage below how the QEMU command line arguments would change with a standalone vhost-scsi-pci device..? ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \ -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \ -vhost-scsi id=vhost-scsi0,wwpn=naa.600140579ad21088,tpgt=1 \ -device virtio-scsi-pci,vhost-scsi=vhost-scsi0,event_idx=off Two possibilities. Either simply do s/virtio-scsi-pci/vhost-scsi-pci/ or do ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \ -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \ -device virtio-scsi-pci,wwpn=naa.600140579ad21088,tpgt=1,event_idx=off
Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Il 13/09/2012 23:45, Jeff Cody ha scritto: While there are more changes this way, I think it cleans up the code a bit. The advantage is that bs-open_flags actually reflects the open flags that are currently in use. One disadvantage I see is that it seems a bit odd to have BDRV_O_CACHE_WCE cleared and BDRV_O_CACHE_WB set, until you think about them being intended for different layers. It's more weird to see BDRV_O_CACHE_WCE set and BDRV_O_CACHE_WB cleared. :) Maybe that is part of the underlying problem - there is one open_flags variable in the BDS, that has some flags intended for all layers in the block stack, and some flags specific to a layer. Yes, that's true. Paolo
Re: [Qemu-devel] [PATCH 11/25] q35: Introduce q35 pc based chipset emulator
Il 13/09/2012 22:12, Jason Baron ha scritto:
+typedef struct ICH9_LPCIrqState {
+struct ICH9_LPCState *lpc;
Please add DEFINE_PROP_PTR property for this field in gmch_pcihost_info,
so we know this ought to become a linkICH9_LPCState later.
+qemu_irq *pic;
+qemu_irq *ioapic;
+} ICH9_LPCIrqState;
+
Paolo
Re: [Qemu-devel] [PATCH 16/25] pci: Add class 0xc05 as 'SMBus'
Il 13/09/2012 22:12, Jason Baron ha scritto:
From: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Jason Baron jba...@redhat.com
---
hw/pci.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 55e4ad3..3727afa 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1203,6 +1203,7 @@ static const pci_class_desc pci_class_descriptions[] =
{ 0x0c02, SSA controller, ssa},
{ 0x0c03, USB controller, usb},
{ 0x0c04, Fibre channel controller, fibre-channel},
+{ 0x0c05, SMBus},
{ 0, NULL}
};
You could move here the corresponding hunk of patch 8/25.
Paolo
Re: [Qemu-devel] [PATCH 18/25] q35: Fix irr initialization for slots 25..31
Il 13/09/2012 22:12, Jason Baron ha scritto:
From: Isaku Yamahata yamah...@valinux.co.jp
This was totally off: The CC registers are 16 bit (stored as little
endian), their offsets run in reverse order, and D26IR as well as D25IR
have 4 bytes offset to their successors.
Reported-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
Signed-off-by: Jason Baron jba...@redhat.com
---
hw/q35.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/hw/q35.c b/hw/q35.c
index 8b6a2e5..295344e 100644
--- a/hw/q35.c
+++ b/hw/q35.c
@@ -474,7 +474,7 @@ static void ich9_lpc_reset(DeviceState *qdev);
* Although it's not pci configuration space, it's little endian as Intel.
*/
-static void ich9_cc_update_ir(uint8_t irr[PCI_NUM_PINS], uint32_t ir)
+static void ich9_cc_update_ir(uint8_t irr[PCI_NUM_PINS], uint16_t ir)
{
int intx;
for (intx = 0; intx PCI_NUM_PINS; intx++) {
@@ -485,15 +485,26 @@ static void ich9_cc_update_ir(uint8_t
irr[PCI_NUM_PINS], uint32_t ir)
static void ich9_cc_update(ICH9_LPCState *lpc)
{
int slot;
-int reg_offset;
-int intx;
+int pci_intx;
+
+const int reg_offsets[] = {
+ICH9_CC_D25IR,
+ICH9_CC_D26IR,
+ICH9_CC_D27IR,
+ICH9_CC_D28IR,
+ICH9_CC_D29IR,
+ICH9_CC_D30IR,
+ICH9_CC_D31IR,
+};
+const int *offset;
/* D{25 - 31}IR, but D30IR is read only to 0. */
-for (slot = 25, reg_offset = 0; slot 32; slot++, reg_offset++) {
-if (slot != 30) {
-ich9_cc_update_ir(lpc-irr[slot],
- lpc-chip_config[ICH9_CC_D31IR + reg_offset]);
+for (slot = 25, offset = reg_offsets; slot 32; slot++, offset++) {
+if (slot == 30) {
+continue;
}
+ich9_cc_update_ir(lpc-irr[slot],
+ pci_get_word(lpc-chip_config + *offset));
}
/*
@@ -502,8 +513,8 @@ static void ich9_cc_update(ICH9_LPCState *lpc)
* are connected to pirq lines. Our choice is PIRQ[E-H].
* INT[A-D] are connected to PIRQ[E-H]
*/
-for (intx = 0; intx PCI_NUM_PINS; intx++) {
-lpc-irr[30][intx] = intx + 4;
+for (pci_intx = 0; pci_intx PCI_NUM_PINS; pci_intx++) {
+lpc-irr[30][pci_intx] = pci_intx + 4;
}
}
I guess this patch and patch 12 could/should be squashed in patch 11
(the one that introduces q35.c)?
Paolo
Re: [Qemu-devel] [PATCH 25/25] q35: automatically load the q35 dsdt table
Il 13/09/2012 22:12, Jason Baron ha scritto:
Automatically, locate the required q35 dsdt table on load. Otherwise we error
out. This could be done in the bios, but its harder to produce a good error
message.
Signed-off-by: Jason Baron jba...@redhat.com
---
hw/pc_q35.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/hw/pc_q35.c b/hw/pc_q35.c
index b8c1196..08ae62b 100644
--- a/hw/pc_q35.c
+++ b/hw/pc_q35.c
@@ -329,6 +329,25 @@ static void pc_q35_init_late(BusState **idebus,
ISADevice *rtc_state,
8, NULL, 0);
}
+static int find_and_load_dsdt(const char *dsdt_name)
+{
+char *filename;
+char buf[256];
+
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, dsdt_name);
+if (!filename) {
+return -1;
+}
+
+snprintf(buf, 256, file=%s, filename);
+if (acpi_table_add(buf) 0) {
+fprintf(stderr, Wrong acpi table provided\n);
+return -1;
+}
+
+return 0;
+}
+
/* PC hardware initialisation */
static void pc_q35_init(ram_addr_t ram_size,
const char *boot_device,
@@ -356,6 +375,13 @@ static void pc_q35_init(ram_addr_t ram_size,
qemu_irq *i8259;
int i;
+/* let's first see if we can find the proper dsdt */
+if (find_and_load_dsdt(q35-acpi-dsdt.aml)) {
+fprintf(stderr, Couldn't find q35 dsdt table!\n
+Try updating your bios.\n);
+exit(1);
+}
+
pc_cpus_init(cpu_model);
kvmclock_create();
Should we take the PIIX4 DSDT into the QEMU tree, and do the same thing
for PIIX4?
Paolo
Re: [Qemu-devel] [PATCH 24/25] Add a fallback bios file search, if -L fails.
Il 13/09/2012 22:12, Jason Baron ha scritto: If -L dir is specified, and qemu does not find the bios file in dir, then the search fails. Add infrastructure such that the search will continue in the default paths, if not found in the -L path. Signed-off-by: Jason Baron jba...@redhat.com What is this useful for? +static char *__qemu_find_file(int type, const char *name, const char *dir) No __ names in userspace, use qemu_find_file_in_dir. Paolo
Re: [Qemu-devel] [PATCH 25/25] q35: automatically load the q35 dsdt table
On 09/14/12 09:08, Paolo Bonzini wrote:
Il 13/09/2012 22:12, Jason Baron ha scritto:
Automatically, locate the required q35 dsdt table on load. Otherwise we error
out. This could be done in the bios, but its harder to produce a good error
message.
/* PC hardware initialisation */
static void pc_q35_init(ram_addr_t ram_size,
const char *boot_device,
@@ -356,6 +375,13 @@ static void pc_q35_init(ram_addr_t ram_size,
qemu_irq *i8259;
int i;
+/* let's first see if we can find the proper dsdt */
+if (find_and_load_dsdt(q35-acpi-dsdt.aml)) {
+fprintf(stderr, Couldn't find q35 dsdt table!\n
+Try updating your bios.\n);
+exit(1);
+}
+
pc_cpus_init(cpu_model);
kvmclock_create();
Should we take the PIIX4 DSDT into the QEMU tree, and do the same thing
for PIIX4?
We should surely have both at the same place. Dunno what the best place
is, we have interactions with both seabios code and acpi tables and qemu
+ acpi tables.
I'd tend to put them into seabios.git, add a config option to select
piix/q35, then go build two bios binaries.
cheers,
Gerd
Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Am 13.09.2012 18:12, schrieb Paolo Bonzini:
Il 13/09/2012 17:49, Jeff Cody ha scritto:
Block drivers should always open the files in writeback mode (see commit
e1e9b0ac), so raw-posix/raw-win32 should not parse the BDRV_O_CACHE_WB
flag.
Signed-off-by: Jeff Cody jc...@redhat.com
---
block/raw-posix.c | 3 ---
block/raw-win32.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 7d3ac9d..4a1047c 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -202,9 +202,6 @@ static void raw_parse_flags(int bdrv_flags, int
*open_flags)
if ((bdrv_flags BDRV_O_NOCACHE)) {
*open_flags |= O_DIRECT;
}
-if (!(bdrv_flags BDRV_O_CACHE_WB)) {
-*open_flags |= O_DSYNC;
-}
}
static int raw_set_aio(void **aio_ctx, int *use_aio, int bdrv_flags)
diff --git a/block/raw-win32.c b/block/raw-win32.c
index 335c06a..78c8306 100644
--- a/block/raw-win32.c
+++ b/block/raw-win32.c
@@ -92,9 +92,6 @@ static void raw_parse_flags(int flags, int *access_flags,
DWORD *overlapped)
if (flags BDRV_O_NOCACHE) {
*overlapped |= FILE_FLAG_NO_BUFFERING;
}
-if (!(flags BDRV_O_CACHE_WB)) {
-*overlapped |= FILE_FLAG_WRITE_THROUGH;
-}
}
static int raw_open(BlockDriverState *bs, const char *filename, int flags)
Why does this matter? If raw-posix was opened directly (i.e. without
the bs-file indirection) this would cause a writethrough file to be
incorrectly opened as writeback.
--verbose, please.
I can't see how bs-file is needed here for writethrough semantics.
bdrv_open_common() sets bs-enable_write_cache to false and
bdrv_co_do_writev() checks it and flushes if necessary. Looks fine to me.
In fact, bdrv_open_common() even removes BDRV_O_CACHE_WB, so what Jeff
removes here is really dead code (checked with strace: The file isn't
opened with O_SYNC even when using -drive format=file).
Kevin
Re: [Qemu-devel] [PATCH v2] rtl8139: implement 8139cp link status
On Fri, Sep 14, 2012 at 2:34 AM, Amos Kong ak...@redhat.com wrote: On 13/09/12 20:29, Stefan Hajnoczi wrote: On Thu, Sep 13, 2012 at 9:51 AM, Amos Kong ak...@redhat.com wrote: Regarding migration: do we migrate the NetClient-link_down field? If we only migrate the status register value then the link may actually be up at the net.c level. I tried to add 'MediaStatus' to 'struct RTL8139State', and update 'VMStateDescription vmstate_rtl8139', then the value of MediaStatus will be migrated. But the idea in v2 is better. Migrating the NIC's media status is not enough. Above I asked about migrating nc-link_down, which determines whether net.c delivers packets or drops them. Your patch migrates the NIC's media status but I believe nc-link_down isn't being migrated and the guest will therefore receive packets from the host! This could lead to unexpected results since the guest thinks the link is down. It's not a bug in your patch, but a larger issue that needs to be addressed for all NICs that support migration. (Unless I missed the code that will migrate link_down.) Stefan
Re: [Qemu-devel] [PATCH v2 08/16] block: raw-posix image file reopen
Am 13.09.2012 18:57, schrieb Jeff Cody:
On 09/13/2012 12:02 PM, Paolo Bonzini wrote:
Il 13/09/2012 17:49, Jeff Cody ha scritto:
+
+/*
+ * If we didn't have BDRV_O_NOCACHE set before, we may not have
allocated
+ * aligned_buf
+ */
+ret = raw_allocate_aligned_buf(raw_s-aligned_buf,
+ raw_s-aligned_buf_size, state-flags);
Aligned_buf is unused, except for checking if it exists here:
if (s-aligned_buf) {
if (!qiov_is_aligned(bs, qiov)) {
type |= QEMU_AIO_MISALIGNED;
#ifdef CONFIG_LINUX_AIO
} else if (s-use_aio) {
return laio_submit(bs, s-aio_ctx, s-fd, sector_num, qiov,
nb_sectors, cb, opaque, type);
#endif
}
}
You can instead check BDRV_O_NOCACHE and kill aligned_buf completely.
Paolo
Hmm - yes, it looks like that is so. This patch will transform into
checking for BDRV_O_NOCACHE as you suggest, and killing aligned_buf.
Sounds good, but please make removing aligned_buf a separate patch.
Kevin
Re: [Qemu-devel] [PATCH 25/25] q35: automatically load the q35 dsdt table
Il 14/09/2012 09:25, Gerd Hoffmann ha scritto: Should we take the PIIX4 DSDT into the QEMU tree, and do the same thing for PIIX4? We should surely have both at the same place. Dunno what the best place is, we have interactions with both seabios code and acpi tables and qemu + acpi tables. I'd tend to put them into seabios.git, add a config option to select piix/q35, then go build two bios binaries. Let's discuss it in the SeaBIOS mailing list. Paolo
Re: [Qemu-devel] [PATCH v2 1/3] Refactor inet_connect_opts function
On Thu, Sep 13, 2012 at 07:52:35PM +0300, Orit Wasserman wrote:
+for (e = res; e != NULL; e = e-ai_next) {
+sock = inet_connect_addr(e, block, in_progress, errp);
+if (in_progress *in_progress) {
+return sock;
Doesn't this leak res?
Actually it doesn't after patch 3 wait_for_connect is the one freeing res.
is it OK to leave it as is ?
Orit
We can't avoid breaking bisect sometimes but let's not do this intentionally.
--
MST
Re: [Qemu-devel] [PULL 00/13] Net patches
On Mon, Sep 10, 2012 at 10:55 AM, Stefan Hajnoczi stefa...@gmail.com wrote: Fixes for hung NICs, USB network interface packet dropping, and inefficient netdev socket non-blocking I/O. The following changes since commit 0c267217ca9985e6d118ec8368bebd382db7a099: musicpal: Fix flash mapping (2012-09-08 10:17:57 +) are available in the git repository at: git://github.com/stefanha/qemu.git net for you to fetch changes up to 0eb160d10e4f55cb5430ca3b6eb049977d0ce643: net: EAGAIN handling for net/socket.c TCP (2012-09-10 08:12:34 +0100) Please disregard this thread, there has been an issue with my mail queue. I am going to resend this pull request to make sure all mails are properly delivered. Stefan
Re: [Qemu-devel] [PATCH 11/25] q35: Introduce q35 pc based chipset emulator
On 09/13/12 22:12, Jason Baron wrote:
+if (ram_size = 0xe000) {
+above_4g_mem_size = ram_size - 0xe000;
+below_4g_mem_size = 0xe000;
We should make the hole larger to get more pci i/o address space below
4G, especially as q35 needs a good chunk of it for mmconfig.
I think at least 0xc000, maybe even 0xb000. The later would
allow to place mmconfig @ 0xb000, one big 512MB pci bar @ 0xc000
(think gfx card pass-through) and all the remaining little stuff above
0xe000.
cheers,
Gerd
Re: [Qemu-devel] [PATCH 07/11] Fix copypaste typos in documentation comments
On Thu, Sep 6, 2012 at 11:00 AM, Stefan Hajnoczi stefa...@gmail.com wrote: From: BALATON Zoltan bala...@eik.bme.hu Signed-off-by: BALATON Zoltan bala...@eik.bme.hu Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- memory.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) Please disregard this thread, there has been an issue with my mail queue. I am going to resend this pull request to make sure all mails are properly delivered. Stefan
[Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
What's the difference between the two except that the latter adds some more instructions (actually whole new subsytem) to the former? Why do we need -i386, what -x86_64 does not do which does -i386? Thanks, /mjt
[Qemu-devel] [PATCH 09/13] net: fix usbnet_receive() packet drops
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The USB network interface has a single buffer which the guest reads
from. This patch prevents multiple calls to usbnet_receive() from
clobbering the input buffer. Instead we queue packets until buffer
space becomes available again.
This is inspired by virtio-net and e1000 rxbuf handling.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/usb/dev-network.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 0b5cb71..e4a4359 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1001,6 +1001,13 @@ static int rndis_keepalive_response(USBNetState *s,
return 0;
}
+/* Prepare to receive the next packet */
+static void usb_net_reset_in_buf(USBNetState *s)
+{
+s-in_ptr = s-in_len = 0;
+qemu_flush_queued_packets(s-nic-nc);
+}
+
static int rndis_parse(USBNetState *s, uint8_t *data, int length)
{
uint32_t msg_type;
@@ -1025,7 +1032,8 @@ static int rndis_parse(USBNetState *s, uint8_t *data, int
length)
case RNDIS_RESET_MSG:
rndis_clear_responsequeue(s);
-s-out_ptr = s-in_ptr = s-in_len = 0;
+s-out_ptr = 0;
+usb_net_reset_in_buf(s);
return rndis_reset_response(s, (rndis_reset_msg_type *) data);
case RNDIS_KEEPALIVE_MSG:
@@ -1135,7 +1143,7 @@ static int usb_net_handle_datain(USBNetState *s,
USBPacket *p)
int ret = USB_RET_NAK;
if (s-in_ptr s-in_len) {
-s-in_ptr = s-in_len = 0;
+usb_net_reset_in_buf(s);
ret = USB_RET_NAK;
return ret;
}
@@ -1152,7 +1160,7 @@ static int usb_net_handle_datain(USBNetState *s,
USBPacket *p)
if (s-in_ptr = s-in_len
(is_rndis(s) || (s-in_len (64 - 1)) || !ret)) {
/* no short packet necessary */
-s-in_ptr = s-in_len = 0;
+usb_net_reset_in_buf(s);
}
#ifdef TRAFFIC_DEBUG
@@ -1263,6 +1271,11 @@ static ssize_t usbnet_receive(NetClientState *nc, const
uint8_t *buf, size_t siz
return -1;
}
+/* Only accept packet if input buffer is empty */
+if (s-in_len 0) {
+return 0;
+}
+
if (is_rndis(s)) {
struct rndis_packet_msg_type *msg;
--
1.7.10.4
Re: [Qemu-devel] [PATCH] block: Don't forget to delete temporary file
On Tue, Sep 11, 2012 at 12:23:37PM +0200, Kevin Wolf wrote: Am 05.09.2012 15:26, schrieb riegama...@gmail.com: From: Dunrong Huang riegama...@gmail.com The caller would not delete temporary file after failed get_tmp_filename(). Signed-off-by: Dunrong Huang riegama...@gmail.com Thanks, applied to the block branch. For the record, using the close(2) errno after calling unlink(2) isn't a good idea. We should follow the docs and preserve errno carefully. It's the exact issue I pointed out on the original patch. Stefan
Re: [Qemu-devel] [Qemu-trivial] [PATCH] configure: fix seccomp check
On Thu, Sep 06, 2012 at 10:40:30PM +0200, Yann E. MORIN wrote: Currently, if libseccomp is missing but the user explicitly requested seccomp support using --enable-seccomp, configure silently ignores the situation and disables seccomp support. This is unlike all other tests that explicitly fail in such situation. Fix that. Signed-off-by: Yann E. MORIN yann.morin.1...@free.fr --- configure |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Thanks, applied to the trivial patches tree: https://github.com/stefanha/qemu/commits/trivial-patches Stefan
Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Il 14/09/2012 09:27, Kevin Wolf ha scritto:
I can't see how bs-file is needed here for writethrough semantics.
bdrv_open_common() sets bs-enable_write_cache to false and
bdrv_co_do_writev() checks it and flushes if necessary. Looks fine to me.
You're right.
In fact, bdrv_open_common() even removes BDRV_O_CACHE_WB, so what Jeff
removes here is really dead code (checked with strace: The file isn't
opened with O_SYNC even when using -drive format=file).
Yes, it's dead, on the other hand we still honor BDRV_O_CACHE_WB in all
the other protocols. Either we go and touch all the protocols
(effectively removing BDRV_O_CACHE_WB from the BlockDriver
specification), or treating raw-{posix,win32} specially means we leave
bugs everywhere else.
Paolo
[Qemu-devel] [PULL 00/13] Net patches
Fixes for hung NICs, USB network interface packet dropping, and inefficient netdev socket non-blocking I/O. The following changes since commit 0c267217ca9985e6d118ec8368bebd382db7a099: musicpal: Fix flash mapping (2012-09-08 10:17:57 +) are available in the git repository at: git://github.com/stefanha/qemu.git net for you to fetch changes up to 0eb160d10e4f55cb5430ca3b6eb049977d0ce643: net: EAGAIN handling for net/socket.c TCP (2012-09-10 08:12:34 +0100) Bo Yang (1): eepro100: Fix network hang when rx buffers run out Paolo Bonzini (3): net: notify iothread after flushing queue e1000: flush queue whenever can_receive can go from false to true xen: flush queue when getting an event Stefan Hajnoczi (9): net: add receive_disabled logic to iov delivery path net: do not report queued packets as sent net: add -netdev options to man page net: clean up usbnet_receive() net: fix usbnet_receive() packet drops net: broadcast hub packets if at least one port can receive net: asynchronous send/receive infrastructure for net/socket.c net: EAGAIN handling for net/socket.c UDP net: EAGAIN handling for net/socket.c TCP hw/e1000.c |4 ++ hw/eepro100.c|4 +- hw/usb/dev-network.c | 49 ++ hw/virtio-net.c |4 -- hw/xen_nic.c |1 + net.c| 22 -- net/hub.c|6 +-- net/queue.c | 40 +- net/queue.h |2 +- net/socket.c | 110 +++--- qemu-options.hx |7 11 files changed, 186 insertions(+), 63 deletions(-) -- 1.7.10.4
[Qemu-devel] [PATCH 13/13] net: EAGAIN handling for net/socket.c TCP
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Replace spinning send_all() with a proper non-blocking send. When the
socket write buffer limit is reached, we should stop trying to send and
wait for the socket to become writable again.
Non-blocking TCP sockets can return in two different ways when the write
buffer limit is reached:
1. ret = -1 and errno = EAGAIN/EWOULDBLOCK. No data has been written.
2. ret total_size. Short write, only part of the message was
transmitted.
Handle both cases and keep track of how many bytes have been written in
s-send_index. (This includes the 'length' header before the actual
payload buffer.)
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/socket.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index e5e4e8d..c3e55b8 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -32,6 +32,7 @@
#include qemu-error.h
#include qemu-option.h
#include qemu_socket.h
+#include iov.h
typedef struct NetSocketState {
NetClientState nc;
@@ -40,6 +41,7 @@ typedef struct NetSocketState {
int state; /* 0 = getting length, 1 = getting data */
unsigned int index;
unsigned int packet_len;
+unsigned int send_index; /* number of bytes sent (only SOCK_STREAM) */
uint8_t buf[4096];
struct sockaddr_in dgram_dst; /* contains inet host and port destination
iff connectionless (SOCK_DGRAM) */
IOHandler *send_fn; /* differs between SOCK_STREAM/SOCK_DGRAM */
@@ -88,15 +90,39 @@ static void net_socket_writable(void *opaque)
qemu_flush_queued_packets(s-nc);
}
-/* XXX: we consider we can send the whole packet without blocking */
static ssize_t net_socket_receive(NetClientState *nc, const uint8_t *buf,
size_t size)
{
NetSocketState *s = DO_UPCAST(NetSocketState, nc, nc);
-uint32_t len;
-len = htonl(size);
+uint32_t len = htonl(size);
+struct iovec iov[] = {
+{
+.iov_base = len,
+.iov_len = sizeof(len),
+}, {
+.iov_base = (void *)buf,
+.iov_len = size,
+},
+};
+size_t remaining;
+ssize_t ret;
+
+remaining = iov_size(iov, 2) - s-send_index;
+ret = iov_send(s-fd, iov, 2, s-send_index, remaining);
-send_all(s-fd, (const uint8_t *)len, sizeof(len));
-return send_all(s-fd, buf, size);
+if (ret == -1 errno == EAGAIN) {
+ret = 0; /* handled further down */
+}
+if (ret == -1) {
+s-send_index = 0;
+return -errno;
+}
+if (ret (ssize_t)remaining) {
+s-send_index += ret;
+net_socket_write_poll(s, true);
+return 0;
+}
+s-send_index = 0;
+return size;
}
static ssize_t net_socket_receive_dgram(NetClientState *nc, const uint8_t
*buf, size_t size)
--
1.7.10.4
Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Am 13.09.2012 23:45, schrieb Jeff Cody:
On 09/13/2012 04:29 PM, Paolo Bonzini wrote:
Il 13/09/2012 21:44, Paolo Bonzini ha scritto:
Il 13/09/2012 21:04, Jeff Cody ha scritto:
Perhaps we _should_ preserve that in bs-open_flags, while still using
the initial value of BDRV_O_CACHE_WB to initialize
bs-enable_write_cache.
That would work. Part of the problem is that BDRV_O_CACHE_WB seems
overloaded; maybe bdrv_parse_cache_flags() should set a new flag, called
BDRV_O_CACHE_WCE, which can be used in lieu of enable_write_cache
(similar to getting rid of keep_read_only in favor of
BDRV_O_ALLOW_RDWR). And then bdrv_parse_cache_flags() would just not
set BDRV_O_CACHE_WB, which can then be used exclusively by the lower
layers for their parsing (and bdrv_open_common would just set
bs-open_flags to always have BDRV_O_CACHE_WB).
Then patch 2/16 would change to having bdrv_set_enable_write_cache()
toggle BDRV_O_CACHE_WCE.
Yeah, that would work.
Alternatively, we can keep this patch and leave bdrv_open_common as is;
but then I would also prefer if raw-{posix,win32} took care of setting
BDRV_O_CACHE_WB in bs-open_flags, so that the flags are consistent.
This setting of BDRV_O_CACHE_WB can be extended later to other formats.
Hmm, no, what was I thinking...
But there is a very simple thing we can do:
- patch 2 can be left as is
- in patch 3 bdrv_reopen_queue, always add BDRV_O_CACHE_WB to
bs_entry-state.flags
- in patch 3 bdrv_reopen_commit, always leave BDRV_O_CACHE_WB aside:
reopen_state-bs-open_flags =
(bs-open_flags BDRV_O_CACHE_WB) |
(reopen_state-flags ~BDRV_O_CACHE_WB);
- this patch can be dropped completely.
Yes, I think that would work. The only thing I don't like is that
BDRV_O_CACHE_WB still remains a bit confusing when looking through the
code... bs-open_flags does not actually represent the open flags.
With what I proposed above, here are the steps needed:
- bdrv_parse_cache_flags() sets BDRV_O_CACHE_WCE instead of
BDRV_O_CACHE_WB
- BDRV_O_CACHE_WCE is used everywhere enable_write_cache was used
- bs-enable_write_cache is removed
- this patch is dropped
- bdrv_open_common() sets bs-open_flags to have BDRV_O_CACHE_WB enabled
by default.
- The only way BDRV_O_CACHE_WB would get cleared from bs-open_flags now
would be if someone explicitly cleared it during a bdrv_reopen().
This feels totally wrong. Your BDRV_O_CACHE_WCE is what BDRV_O_CACHE_WB
should be; removing bs-enable_write_cache in favour of a fix
BDRV_O_CACHE_WB makes sense, though (maybe we need to consider renaming
bs-open_flags then, it really hasn't anything to do with open and
more). All block drivers, including raw-{posix,win32}, should completely
ignore the flag in their .bdrv_open implementation, this flag is purely
for the generic block layer. Drivers always open everything writeback
and provide a flush function. They already do today, because today's
broken BDRV_O_CACHE_WB is always set.
Kevin
Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Am 14.09.2012 09:50, schrieb Paolo Bonzini:
Il 14/09/2012 09:27, Kevin Wolf ha scritto:
I can't see how bs-file is needed here for writethrough semantics.
bdrv_open_common() sets bs-enable_write_cache to false and
bdrv_co_do_writev() checks it and flushes if necessary. Looks fine to me.
You're right.
In fact, bdrv_open_common() even removes BDRV_O_CACHE_WB, so what Jeff
removes here is really dead code (checked with strace: The file isn't
opened with O_SYNC even when using -drive format=file).
Yes, it's dead, on the other hand we still honor BDRV_O_CACHE_WB in all
the other protocols. Either we go and touch all the protocols
(effectively removing BDRV_O_CACHE_WB from the BlockDriver
specification), or treating raw-{posix,win32} specially means we leave
bugs everywhere else.
Yes, touch all protocols and fix them. BDRV_O_CACHE_WB should be for
block.c only.
Kevin
Re: [Qemu-devel] [PATCH v2 06/16] block: do not parse BDRV_O_CACHE_WB in raw block drivers
Il 14/09/2012 09:55, Kevin Wolf ha scritto:
Either we go and touch all the protocols
(effectively removing BDRV_O_CACHE_WB from the BlockDriver
specification), or treating raw-{posix,win32} specially means we leave
bugs everywhere else.
Yes, touch all protocols and fix them. BDRV_O_CACHE_WB should be for
block.c only.
That's also fine, of course.
Paolo
Re: [Qemu-devel] [PULL 00/14] usb patch queue
On 13.09.2012 12:39, Gerd Hoffmann wrote: Hi, Here comes the usb patch queue, featuring life migration support for usb network redirection and the usual share of bugfixes ;) Are any of the bugfixes worth to apply to previous or new -stable series? I know usbredir configure fix is needed, anything else? Thanks, /mjt Aurelien Jarno (1): configure: usbredir fixes Gerd Hoffmann (2): usb-host: allow emulated (non-async) control requests without USBPacket ehci: switch to new-style memory ops Hans de Goede (11): ehci: Fix interrupts stopping when Interrupt Threshold Control is 8 ehci: Don't process too much frames in 1 timer tick (v2) ehci: Don't set seen to 0 when removing unseen queue-heads ehci: Walk async schedule before and after migration usb-redir: Change cancelled packet code into a generic packet-id queue usb-redir: Add an already_in_flight packet-id queue usb-redir: Store max_packet_size in endp_data usb-redir: Add support for migration usb-redir: Add chardev open / close debug logging usb-redir: Revert usb-redir part of commit 93bfef4c uhci: Don't queue up packets after one with the SPD flag set
Re: [Qemu-devel] [PULL 00/10] spice patch queue
On 13.09.2012 12:45, Gerd Hoffmann wrote: Hi, This pull brings monitor configuration support for qxl which is needed by the upcoming kms qxl driver. Also a nice speedup for qxl in vga mode and as usual some bugfixes. Again, anything worth to apply/backport to -stable? For example, qxl: dont update invalid area by Dunrong Huang or a fix by Hans de Goede maybe? Thanks, /mjt Alon Levy (3): hw/qxl: tracing fixes qxl: add trace-event for QXL_IO_LOG hw/qxl: support client monitor configuration via device Dunrong Huang (1): qxl: dont update invalid area Gerd Hoffmann (4): spice: switch to queue for vga mode updates spice: split qemu_spice_create_update spice: add screen mirror spice: send updates only for changed screen content Hans de Goede (1): qxl: Ignore set_client_capabilities pre/post migrate Uri Lublin (1): qxl: better cleanup for surface destroy
[Qemu-devel] [PATCH 11/11] arch_init.c: add missing '%' symbols before PRIu64 in debug printfs
From: Igor Mitsyanko i.mitsya...@samsung.com
'%' symbols were missing in front of PRIu64 macros in DPRINTF() messages in
arch_init.c, this caused compilation warnings when compiled with
DEBUG_ARCH_INIT defined.
Signed-off-by: Igor Mitsyanko i.mitsya...@samsung.com
Signed-off-by: Stefan Hajnoczi stefa...@gmail.com
---
arch_init.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 5a1173e..47977de 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -562,7 +562,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
if ((i 63) == 0) {
uint64_t t1 = (qemu_get_clock_ns(rt_clock) - bwidth) / 100;
if (t1 MAX_WAIT) {
-DPRINTF(big wait: PRIu64 milliseconds, %d iterations\n,
+DPRINTF(big wait: % PRIu64 milliseconds, %d iterations\n,
t1, i);
break;
}
@@ -587,7 +587,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
-DPRINTF(ram_save_live: expected( PRIu64 ) = max( PRIu64 )?\n,
+DPRINTF(ram_save_live: expected(% PRIu64 ) = max(% PRIu64 )?\n,
expected_time, migrate_max_downtime());
if (expected_time = migrate_max_downtime()) {
@@ -799,8 +799,8 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
} while (!(flags RAM_SAVE_FLAG_EOS));
done:
-DPRINTF(Completed load of VM with exit code %d seq iteration PRIu64
\n,
-ret, seq_iter);
+DPRINTF(Completed load of VM with exit code %d seq iteration
+% PRIu64 \n, ret, seq_iter);
return ret;
}
--
1.7.10.4
[Qemu-devel] [PATCH 07/11] Fix copypaste typos in documentation comments
From: BALATON Zoltan bala...@eik.bme.hu Signed-off-by: BALATON Zoltan bala...@eik.bme.hu Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- memory.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/memory.h b/memory.h index bd1bbae..f6c8e32 100644 --- a/memory.h +++ b/memory.h @@ -252,9 +252,9 @@ void memory_region_init_ram(MemoryRegion *mr, uint64_t size); /** - * memory_region_init_ram: Initialize RAM memory region from a user-provided. - * pointer. Accesses into the region will modify - * memory directly. + * memory_region_init_ram_ptr: Initialize RAM memory region from a + * user-provided pointer. Accesses into the + * region will modify memory directly. * * @mr: the #MemoryRegion to be initialized. * @name: the name of the region. @@ -581,7 +581,8 @@ void memory_region_add_subregion(MemoryRegion *mr, target_phys_addr_t offset, MemoryRegion *subregion); /** - * memory_region_add_subregion: Add a subregion to a container, with overlap. + * memory_region_add_subregion_overlap: Add a subregion to a container + * with overlap. * * Adds a subregion at @offset. The subregion may overlap with other * subregions. Conflicts are resolved by having a higher @priority hide a @@ -743,7 +744,7 @@ void memory_listener_unregister(MemoryListener *listener); void memory_global_dirty_log_start(void); /** - * memory_global_dirty_log_stop: begin dirty logging for all regions + * memory_global_dirty_log_stop: end dirty logging for all regions */ void memory_global_dirty_log_stop(void); -- 1.7.10.4
Re: [Qemu-devel] [PATCH 0/5] vhost-scsi: Add support for host virtualized target
Il 13/09/2012 22:12, Nicholas A. Bellinger ha scritto: Are you still seeing the performance degradation discussed in the thread vhost-scsi port to v1.1.0 + MSI-X performance regression So the performance regression reported here with QEMU v1.2-rc + virtio-scsi ended up being related to virtio interrupts being delivered across multiple CPUs. After explicitly setting the IRQ affinity of the virtio0-request MSI-X vector to a specific CPU, the small block (4k) mixed random I/O performance jumped back up to the expected ~100K IOPs for a single LUN. Have you tried setting rq_affinity to 2? Benchmarking this against multiqueue virtio-scsi is on my todo list. Paolo FYI, I just tried this again with the most recent QEMU v1.2.50 (v1.3-rc) code, and both cases appear to be performing as expected once again regardless of the explicit IRQ affinity setting.
Re: [Qemu-devel] [PULL 00/14] usb patch queue
Are any of the bugfixes worth to apply to previous or new -stable series? I know usbredir configure fix is needed, anything else? Gerd Hoffmann (2): usb-host: allow emulated (non-async) control requests without USBPacket This. ehci: Fix interrupts stopping when Interrupt Threshold Control is 8 This. usb-redir: Revert usb-redir part of commit 93bfef4c uhci: Don't queue up packets after one with the SPD flag set And these two. I think the other ehci bugfixes are mostly needed for usbredir migration, so I'd leave them out for stable. Hans? cheers, Gerd
Re: [Qemu-devel] [PULL 00/10] spice patch queue
On 09/14/12 10:01, Michael Tokarev wrote: On 13.09.2012 12:45, Gerd Hoffmann wrote: Hi, This pull brings monitor configuration support for qxl which is needed by the upcoming kms qxl driver. Also a nice speedup for qxl in vga mode and as usual some bugfixes. Again, anything worth to apply/backport to -stable? For example, qxl: dont update invalid area by Dunrong Huang Yes. or a fix by Hans de Goede maybe? No, the other fixes are for new (post 1.2) bugs and wouldn't apply to stable anyway. cheers, Gerd
Re: [Qemu-devel] [PATCH v3] rtl8139: implement 8139cp link status
Il 14/09/2012 04:16, Amos Kong ha scritto:
+/* The LinkDown bit of MediaStatus is inverse with link status */
+ret = 0xd0 | (s-nic-nc.link_down ? MSR_LinkDown : 0);
DPRINTF(MediaStatus read 0x%x\n, ret);
break;
@@ -3453,12 +3466,27 @@ static void pci_rtl8139_uninit(PCIDevice *dev)
qemu_del_net_client(s-nic-nc);
}
+static void rtl8139_set_link_status(NetClientState *nc)
+{
+RTL8139State *s = DO_UPCAST(NICState, nc, nc)-opaque;
+
+if (nc-link_down) {
+s-BasicModeStatus = ~0x0004;
+} else {
+s-BasicModeStatus |= 0x0004;
+}
+
+s-IntrStatus |= RxUnderrun;
+rtl8139_update_irq(s);
+}
+
Actually, this is worse than v2 because then one bit is migrated and the
other is not.
I think v2 is correct and, on top of it, you have to check in post_load
whether nc-link_down matches the loaded BMSR value. If not, you need
to either set the link status in NetClientState, or generate an
RxUnderrun interrupt.
An alternative is to add a get_link_status callback and call it after
migration for all NIC NetClientStates.
Paolo
Re: [Qemu-devel] [PATCH 19/25] ahci: add migration support
Jason Baron jba...@redhat.com wrote:
Add support for ahci migration. This patch builds upon the patches originally
posted by Andreas Färber.
These patches have been tested by migrating Windows 7 and Fedora 16 guests on
both piix with ahci attached and on q35 (which has a built-in ahci
controller).
+const VMStateDescription vmstate_ahci = {
+.name = ahci,
+.version_id = 1,
+.post_load = ahci_state_post_load,
+.fields = (VMStateField []) {
+VMSTATE_INT32_EQUAL(ports, AHCIState),
+VMSTATE_STRUCT_VARRAY_POINTER_INT32(dev, AHCIState, ports,
+ vmstate_ahci_device, AHCIDevice),
+VMSTATE_UINT32(control_regs.cap, AHCIState),
+VMSTATE_UINT32(control_regs.ghc, AHCIState),
+VMSTATE_UINT32(control_regs.irqstatus, AHCIState),
+VMSTATE_UINT32(control_regs.impl, AHCIState),
+VMSTATE_UINT32(control_regs.version, AHCIState),
+VMSTATE_UINT32(idp_index, AHCIState),
+VMSTATE_END_OF_LIST()
+},
+};
+
Only comment that I have is if we can add that bit on the vmstate
transition. That way we can detect when the number of ports between the
two instances are different.
You can change it to; (it checks that ports received is less ore equal
than original value):
+VMSTATE_INT32_LE(ports, AHCIState),
If the code will work if we transfer less ports that are active. I have
no clue which one makes more sense from the ahci point of view.
Thanks, Juan.
Re: [Qemu-devel] [libvirt] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes
On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote: Are there any other requirements that need to be taken care of to enable execution of QEMU guests under separate unprivileged user IDs (ie. DAC isolation)? At this point, this patch series (Per-guest configurable user/group for QEMU processes) is upstream, allowing libvirt to execute guests under separate unprivileged user IDs. Additionally, the QEMU bridge helper series is upstream, allowing QEMU to allocate a tap device and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html). Is there any other feature in QEMU that requires QEMU to be run as root? Well those features you mention are for two separate issues. When running libvirt privileged (qemu:///system), QEMU was already run as non-root (qemu:qemu). The per-guest user/group was just making sure that QEMU VMs were isolated from each other using user IDs. Since libvirtd is running privileged, it can either set permissions or open things on QEMU's behalf. All this side of things really works already. The TAP device bridge helper is something that's needed when running libvirtd itself unprivileged (eg the per user qemu:///session libvirtd). In this case libvirtd can't access privileged resources at all, hence the setuid TAP helper was required. So I guess this is a roundabout way of saying that I'm not really clear what you're asking about ? If you're using qemu:///system there has never been any problem with running QEMU unprivileged. When using qemu:///session you're obviously limited to whatever resources the user is allowed to access. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PULL 00/12] Trivial patches for 16 August to 14 September 2012
The following changes since commit e0a1e32dbc41e6b2aabb436a9417dfd32177a3dc: Merge branch 'usb.64' of git://git.kraxel.org/qemu (2012-09-11 18:06:56 +0200) are available in the git repository at: git://github.com/stefanha/qemu.git trivial-patches for you to fetch changes up to e84d5956cc6215d2f098e7b6090fc5ec4cba1be3: configure: fix seccomp check (2012-09-14 08:46:27 +0100) BALATON Zoltan (2): Fix copypaste typos in documentation comments console: Clean up bytes per pixel calculation Igor Mitsyanko (1): arch_init.c: add missing '%' symbols before PRIu64 in debug printfs Lei Li (1): qapi: Fix enumeration typo error Peter Maydell (1): linux-user: Remove #if 0'd cpu_get_real_ticks() definition Stefan Weil (6): srp: Don't use QEMU_PACKED for single elements of a structured type Spelling fixes in comments and documentation Fix spelling (licenced - licensed) in GPL Spelling fixes in comments and macro names (ressource - resource) ui: Fix spelling in comment (ressource - resource) kvm: Fix warning from static code analysis Yann E. MORIN (1): configure: fix seccomp check arch_init.c |8 configure |2 +- console.c |5 ++--- docs/specs/ppc-spapr-hcalls.txt |2 +- docs/usb2.txt |4 ++-- hw/imx_avic.c |4 ++-- hw/imx_timer.c |4 ++-- hw/kzm.c|2 +- hw/srp.h|8 hw/xen-host-pci-device.c|6 +++--- hw/xen_pt.h |4 ++-- hw/xen_pt_config_init.c | 14 +++--- kvm-all.c | 12 +--- linux-user/main.c | 13 - memory.h| 11 ++- qapi-schema-guest.json |2 +- qapi-schema.json|4 ++-- qemu-img.c |2 +- qemu-img.texi |2 +- ui/spice-display.c |2 +- 20 files changed, 48 insertions(+), 63 deletions(-) -- 1.7.10.4
[Qemu-devel] [PATCH 01/12] srp: Don't use QEMU_PACKED for single elements of a structured type
From: Stefan Weil s...@weilnetz.de
QEMU_PACKED results in a MinGW compiler warning when it is
used for single structure elements:
warning: 'gcc_struct' attribute ignored
Using QEMU_PACKED for the whole structure avoids the compiler warning
without changing the memory layout.
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/srp.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/srp.h b/hw/srp.h
index 3009bd5..5e0cad5 100644
--- a/hw/srp.h
+++ b/hw/srp.h
@@ -177,13 +177,13 @@ struct srp_tsk_mgmt {
uint8_treserved1[6];
uint64_t tag;
uint8_treserved2[4];
-uint64_t lun QEMU_PACKED;
+uint64_t lun;
uint8_treserved3[2];
uint8_ttsk_mgmt_func;
uint8_treserved4;
uint64_t task_tag;
uint8_treserved5[8];
-};
+} QEMU_PACKED;
/*
* We need the packed attribute because the SRP spec only aligns the
@@ -198,14 +198,14 @@ struct srp_cmd {
uint8_tdata_in_desc_cnt;
uint64_t tag;
uint8_treserved2[4];
-uint64_t lun QEMU_PACKED;
+uint64_t lun;
uint8_treserved3;
uint8_ttask_attr;
uint8_treserved4;
uint8_tadd_cdb_len;
uint8_tcdb[16];
uint8_tadd_data[0];
-};
+} QEMU_PACKED;
enum {
SRP_RSP_FLAG_RSPVALID = 1 0,
--
1.7.10.4
[Qemu-devel] [PATCH 08/13] net: clean up usbnet_receive()
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The USB network interface has two code paths depending on whether or not
RNDIS mode is enabled. Refactor usbnet_receive() so that there is a
common path throughout the function instead of duplicating everything
across if (is_rndis(s)) ... else ... code paths.
Clean up coding style and 80 character line wrap along the way.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/usb/dev-network.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index c84892c..0b5cb71 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1250,20 +1250,27 @@ static int usb_net_handle_data(USBDevice *dev,
USBPacket *p)
static ssize_t usbnet_receive(NetClientState *nc, const uint8_t *buf, size_t
size)
{
USBNetState *s = DO_UPCAST(NICState, nc, nc)-opaque;
-struct rndis_packet_msg_type *msg;
+uint8_t *in_buf = s-in_buf;
+size_t total_size = size;
if (is_rndis(s)) {
-msg = (struct rndis_packet_msg_type *) s-in_buf;
if (s-rndis_state != RNDIS_DATA_INITIALIZED) {
return -1;
}
-if (size + sizeof(struct rndis_packet_msg_type) sizeof(s-in_buf))
-return -1;
+total_size += sizeof(struct rndis_packet_msg_type);
+}
+if (total_size sizeof(s-in_buf)) {
+return -1;
+}
+if (is_rndis(s)) {
+struct rndis_packet_msg_type *msg;
+
+msg = (struct rndis_packet_msg_type *)in_buf;
memset(msg, 0, sizeof(struct rndis_packet_msg_type));
msg-MessageType = cpu_to_le32(RNDIS_PACKET_MSG);
-msg-MessageLength = cpu_to_le32(size + sizeof(struct
rndis_packet_msg_type));
-msg-DataOffset = cpu_to_le32(sizeof(struct rndis_packet_msg_type) -
8);
+msg-MessageLength = cpu_to_le32(size + sizeof(*msg));
+msg-DataOffset = cpu_to_le32(sizeof(*msg) - 8);
msg-DataLength = cpu_to_le32(size);
/* msg-OOBDataOffset;
* msg-OOBDataLength;
@@ -1273,14 +1280,11 @@ static ssize_t usbnet_receive(NetClientState *nc, const
uint8_t *buf, size_t siz
* msg-VcHandle;
* msg-Reserved;
*/
-memcpy(msg + 1, buf, size);
-s-in_len = size + sizeof(struct rndis_packet_msg_type);
-} else {
-if (size sizeof(s-in_buf))
-return -1;
-memcpy(s-in_buf, buf, size);
-s-in_len = size;
+in_buf += sizeof(*msg);
}
+
+memcpy(in_buf, buf, size);
+s-in_len = total_size;
s-in_ptr = 0;
return size;
}
--
1.7.10.4
[Qemu-devel] no won't fix for QEMU bugs in Launchpad?
I see the won't fix entry is disabled for QEMU bugs, at least for me. Is it just my permissions, or is it disabled? Paolo
Re: [Qemu-devel] [PATCH v2] rtl8139: implement 8139cp link status
On 09/14/2012 03:30 PM, Stefan Hajnoczi wrote: On Fri, Sep 14, 2012 at 2:34 AM, Amos Kongak...@redhat.com wrote: On 13/09/12 20:29, Stefan Hajnoczi wrote: On Thu, Sep 13, 2012 at 9:51 AM, Amos Kongak...@redhat.com wrote: Regarding migration: do we migrate the NetClient-link_down field? If we only migrate the status register value then the link may actually be up at the net.c level. I tried to add 'MediaStatus' to 'struct RTL8139State', and update 'VMStateDescription vmstate_rtl8139', then the value of MediaStatus will be migrated. But the idea in v2 is better. Migrating the NIC's media status is not enough. Above I asked about migrating nc-link_down, which determines whether net.c delivers packets or drops them. Your patch migrates the NIC's media status but I believe nc-link_down isn't being migrated and the guest will therefore receive packets from the host! This could lead to unexpected results since the guest thinks the link is down. It's not a bug in your patch, but a larger issue that needs to be addressed for all NICs that support migration. (Unless I missed the code that will migrate link_down.) Stefan A possible solution is to infer the nc-link_down from the media status register in the destination. It works without adding more codes net.c but need model specific callback functions.
[Qemu-devel] [PATCH 10/13] net: broadcast hub packets if at least one port can receive
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
In commit 60c07d933c66c4b30a83b7ccbc8a0cb3df1b2d0e (net: fix
qemu_can_send_packet logic) the VLAN broadcast behavior was changed
to queue packets if any net client cannot receive. It turns out that
this was not actually the right fix and just hides the real bug that
hw/usb/dev-network.c:usbnet_receive() clobbers its receive buffer when
called multiple times in a row. The commit also introduced a new bug
that VLAN packets would not be sent if one of multiple net clients was
down.
The hw/usb/dev-network.c bug has since been fixed, so this patch reverts
broadcast behavior to send packets as long as one net client can
receive. Packets simply get queued for the net clients that are
temporarily unable to receive.
Reported-by: Roy.Li rongqing...@windriver.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/hub.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/hub.c b/net/hub.c
index ac157e3..650a8b4 100644
--- a/net/hub.c
+++ b/net/hub.c
@@ -97,12 +97,12 @@ static int net_hub_port_can_receive(NetClientState *nc)
continue;
}
-if (!qemu_can_send_packet(port-nc)) {
-return 0;
+if (qemu_can_send_packet(port-nc)) {
+return 1;
}
}
-return 1;
+return 0;
}
static ssize_t net_hub_port_receive(NetClientState *nc,
--
1.7.10.4
Re: [Qemu-devel] [PATCH v3 1/3] Refactor inet_connect_opts function
Orit Wasserman owass...@redhat.com wrote: From: Michael S. Tsirkin m...@redhat.com refactor address resolution code to fix nonblocking connect remove getnameinfo call Signed-off-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Amos Kong ak...@redhat.com Signed-off-by: Orit Wasserman owass...@redhat.com Reviewed-by: Juan Quintela quint...@redhat.com -int inet_connect_opts(QemuOpts *opts, bool *in_progress, Error **errp) +#ifdef _WIN32 +#define QEMU_SOCKET_RC_INPROGRESS(rc) \ +((rc) == -EINPROGRESS || rc == -EWOULDBLOCK || rc == -WSAEALREADY) +#else +#define QEMU_SOCKET_RC_INPROGRESS(rc) \ +((rc) == -EINPROGRESS) +#endif Not specific to this series, but this is used all around in qemu. Should we put it into osdep.h and refactor?
[Qemu-devel] [Bug 427612] Re: kvm sends caps lock key up event twice
Fixed in upstream commit 4e79bcbb96d3c189e50adbdac7b1e28d834ba43e. ** Changed in: qemu Status: New = Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/427612 Title: kvm sends caps lock key up event twice Status in QEMU: Fix Released Status in “libsdl1.2” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Fix Released Status in “libsdl1.2” source package in Maverick: Invalid Status in “qemu-kvm” source package in Maverick: Fix Released Status in “libsdl1.2” package in Debian: Fix Released Bug description: Binary package hint: qemu-kvm I have set the keyboard layout to German NEO 2 [1] in the host and the client (both current karmic). The caps lock is used as modifier (similar to shift) in NEO. When I press caps lock + t, then the client prints a t instead of a -. A caps lock key up event is sent to the client before I release the caps lock key. [1] http://www.neo-layout.org/ ProblemType: Bug Architecture: amd64 Date: Fri Sep 11 01:38:58 2009 DistroRelease: Ubuntu 9.10 KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: UIDPID PPID CSZ RSS PSR STIME TTY TIME CMD Package: qemu-kvm 0.11.0~rc2-0ubuntu2 PccardctlIdent: PccardctlStatus: ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-10-generic root=UUID=37b01f5a-a578-49d6-a812-f166b103e68a ro quiet splash ProcEnviron: LANG=de_DE.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-10.31-generic SourcePackage: qemu-kvm Uname: Linux 2.6.31-10-generic x86_64 dmi.bios.date: 07/15/2009 dmi.bios.vendor: Intel Corp. dmi.bios.version: DPP3510J.86A.0572.2009.0715.2346 dmi.board.asset.tag: Base Board Asset Tag dmi.board.name: DG33TL dmi.board.vendor: Intel Corporation dmi.board.version: AAD89517-802 dmi.chassis.type: 3 dmi.modalias: dmi:bvnIntelCorp.:bvrDPP3510J.86A.0572.2009.0715.2346:bd07/15/2009:svn:pn:pvr:rvnIntelCorporation:rnDG33TL:rvrAAD89517-802:cvn:ct3:cvr: TEST CASE: Select NEO2 as keyboard layout in your guest system and press 'caps lock' + 't'. A '-' should appear. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/427612/+subscriptions
Re: [Qemu-devel] [PATCH v3 2/3] Separate inet_connect into inet_connect (blocking) and inet_nonblocking_connect
Orit Wasserman owass...@redhat.com wrote: No need to add non blocking parameters to the blocking inet_connect add block parameter for inet_connect_opts instead of using QemuOpt block. Signed-off-by: Orit Wasserman owass...@redhat.com Reviewed-by: Juan Quintela quint...@redhat.com
[Qemu-devel] [Bug 1050823] [NEW] segmentation fault when using usb-net and -netdev tap
Public bug reported:
The following command causes a Segmentation fault:
qemu-kvm -usb -device usb-net,netdev=net0 -netdev tap,id=net0
Segmentation fault
The following command does not:
qemu-kvm -usb -device usb-net,netdev=net0 -netdev user,id=net0
Program received signal SIGSEGV, Segmentation fault.
usbnet_can_receive (nc=0x5657dc20)
at /home/pbonzini/work/upstream/qemu/hw/usb/dev-network.c:1292
1292if (is_rndis(s) s-rndis_state != RNDIS_DATA_INITIALIZED) {
First reported at https://bugzilla.redhat.com/show_bug.cgi?id=843310
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1050823
Title:
segmentation fault when using usb-net and -netdev tap
Status in QEMU:
New
Bug description:
The following command causes a Segmentation fault:
qemu-kvm -usb -device usb-net,netdev=net0 -netdev tap,id=net0
Segmentation fault
The following command does not:
qemu-kvm -usb -device usb-net,netdev=net0 -netdev user,id=net0
Program received signal SIGSEGV, Segmentation fault.
usbnet_can_receive (nc=0x5657dc20)
at /home/pbonzini/work/upstream/qemu/hw/usb/dev-network.c:1292
1292 if (is_rndis(s) s-rndis_state != RNDIS_DATA_INITIALIZED) {
First reported at https://bugzilla.redhat.com/show_bug.cgi?id=843310
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1050823/+subscriptions
[Qemu-devel] [PULL 00/13] Net patches
Fixes for hung NICs, USB network interface packet dropping, and inefficient netdev socket non-blocking I/O. The following changes since commit e0a1e32dbc41e6b2aabb436a9417dfd32177a3dc: Merge branch 'usb.64' of git://git.kraxel.org/qemu (2012-09-11 18:06:56 +0200) are available in the git repository at: git://github.com/stefanha/qemu.git net for you to fetch changes up to 45a7f54a8bb3928ffa58d522e0d61acaee8277bb: net: EAGAIN handling for net/socket.c TCP (2012-09-14 08:40:33 +0100) Bo Yang (1): eepro100: Fix network hang when rx buffers run out Paolo Bonzini (3): net: notify iothread after flushing queue e1000: flush queue whenever can_receive can go from false to true xen: flush queue when getting an event Stefan Hajnoczi (9): net: add receive_disabled logic to iov delivery path net: do not report queued packets as sent net: add -netdev options to man page net: clean up usbnet_receive() net: fix usbnet_receive() packet drops net: broadcast hub packets if at least one port can receive net: asynchronous send/receive infrastructure for net/socket.c net: EAGAIN handling for net/socket.c UDP net: EAGAIN handling for net/socket.c TCP hw/e1000.c |4 ++ hw/eepro100.c|4 +- hw/usb/dev-network.c | 49 ++ hw/virtio-net.c |4 -- hw/xen_nic.c |1 + net.c| 22 -- net/hub.c|6 +-- net/queue.c | 40 +- net/queue.h |2 +- net/socket.c | 110 +++--- qemu-options.hx |7 11 files changed, 186 insertions(+), 63 deletions(-) -- 1.7.10.4
Re: [Qemu-devel] no won't fix for QEMU bugs in Launchpad?
On 14 September 2012 09:53, Paolo Bonzini pbonz...@redhat.com wrote: I see the won't fix entry is disabled for QEMU bugs, at least for me. Is it just my permissions, or is it disabled? I think that to set Won't Fix (and Triaged) you need to be in the QEMU launchpad project's list of 'bug supervisors': https://help.launchpad.net/Bugs/Statuses Looking at the right-hand-column of https://bugs.launchpad.net/qemu that means only Anthony can do this at the moment. -- PMM
Re: [Qemu-devel] [PATCH v3 3/3] Fix address handling in inet_nonblocking_connect
Orit Wasserman owass...@redhat.com wrote:
getaddrinfo can give us a list of addresses, but we only try to
connect to the first one. If that fails we never proceed to
the next one. This is common on desktop setups that often have ipv6
configured but not actually working.
To fix this make inet_connect_nonblocking retry connection with a different
address.
callers on inet_nonblocking_connect register a callback function that will
be called when connect opertion completes, in case of failure the fd will have
a negative value
Signed-off-by: Orit Wasserman owass...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Reviewed-by: Juan Quintela quint...@redhat.com
Just thinking out loud to be if I understood this correctly
+do {
+rc = getsockopt(s-fd, SOL_SOCKET, SO_ERROR, (void *) val,
valsize);
+} while (rc == -1 socket_error() == EINTR);
rc return the error code of getsockopt()
and val returns the error code of the socket if there is one.
+
+/* update rc to contain error details */
+if (!rc val) {
+rc = -val;
+}
If getsockopt() succeeds, we reuse rc error code to have the socket
error code. If you have to resent this, could we improve the comment here?
I have to go to the manual page of getsockopt() that don't likes
SO_ERROR to try to understand what this completely un-intuitive (at
least for me) two lines of code do.
+
+/* connect error */
+if (rc 0) {
+closesocket(s-fd);
+s-fd = rc;
+}
If there is any error (getsockopt or in the socket), we just close the
fd and update the error code.
Head hurts.
Thanks, Juan.
Re: [Qemu-devel] [PATCH v3] rtl8139: implement 8139cp link status
On 14/09/12 16:36, Paolo Bonzini wrote:
Il 14/09/2012 04:16, Amos Kong ha scritto:
+/* The LinkDown bit of MediaStatus is inverse with link status */
+ret = 0xd0 | (s-nic-nc.link_down ? MSR_LinkDown : 0);
DPRINTF(MediaStatus read 0x%x\n, ret);
break;
@@ -3453,12 +3466,27 @@ static void pci_rtl8139_uninit(PCIDevice *dev)
qemu_del_net_client(s-nic-nc);
}
+static void rtl8139_set_link_status(NetClientState *nc)
+{
+RTL8139State *s = DO_UPCAST(NICState, nc, nc)-opaque;
+
+if (nc-link_down) {
+s-BasicModeStatus = ~0x0004;
+} else {
+s-BasicModeStatus |= 0x0004;
+}
+
+s-IntrStatus |= RxUnderrun;
+rtl8139_update_irq(s);
+}
+
Actually, this is worse than v2 because then one bit is migrated and the
other is not.
I think v2 is correct and, on top of it, you have to check in post_load
whether nc-link_down matches the loaded BMSR value. If not, you need
to either set the link status in NetClientState, or generate an
RxUnderrun interrupt.
If correct link_down in rtl8139_post_load(), both v2 and v3 will work.
s-nic-nc.link_down = (s-BasicModeStatus 0x04) == 0;
s-BasicModeStatus is really migrated, s-nic-nc.link_down is inferred.
so I will continually work on v2.
An alternative is to add a get_link_status callback and call it after
migration for all NIC NetClientStates.
Paolo
Thanks.
--
Amos.
[Qemu-devel] [PATCH 05/13] net: add receive_disabled logic to iov delivery path
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
This patch adds the missing NetClient-receive_disabled logic in the
sendv delivery code path. It seems that commit
893379efd0e1b84ceb0c42a713293f3dbd27b1bd (net: disable receiving if
client returns zero) only added the logic to qemu_deliver_packet() and
not qemu_deliver_packet_iov().
The receive_disabled flag should be automatically set when .receive(),
.receive_raw(), or .receive_iov() return 0. No further packets will be
delivered to the NetClient until the receive_disabled flag is cleared
again by calling qemu_flush_queued_packets().
Typically the NetClient will wait until its file descriptor becomes
writable and then invoke qemu_flush_queued_packets() to resume
transmission.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/net.c b/net.c
index d9ba1e5..a187a7b 100644
--- a/net.c
+++ b/net.c
@@ -423,16 +423,27 @@ ssize_t qemu_deliver_packet_iov(NetClientState *sender,
void *opaque)
{
NetClientState *nc = opaque;
+int ret;
if (nc-link_down) {
return iov_size(iov, iovcnt);
}
+if (nc-receive_disabled) {
+return 0;
+}
+
if (nc-info-receive_iov) {
-return nc-info-receive_iov(nc, iov, iovcnt);
+ret = nc-info-receive_iov(nc, iov, iovcnt);
} else {
-return nc_sendv_compat(nc, iov, iovcnt);
+ret = nc_sendv_compat(nc, iov, iovcnt);
}
+
+if (ret == 0) {
+nc-receive_disabled = 1;
+}
+
+return ret;
}
ssize_t qemu_sendv_packet_async(NetClientState *sender,
--
1.7.10.4
[Qemu-devel] [PATCH 11/13] net: asynchronous send/receive infrastructure for net/socket.c
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The net/socket.c net client is not truly asynchronous. This patch
borrows the qemu_set_fd_handler2() code from net/tap.c as the basis for
proper asynchronous send/receive.
Only read packets from the socket when the peer is able to receive.
This avoids needless queuing.
Later patches implement asynchronous send.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/socket.c | 58 --
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 7c602e4..7bff536 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -42,9 +42,51 @@ typedef struct NetSocketState {
unsigned int packet_len;
uint8_t buf[4096];
struct sockaddr_in dgram_dst; /* contains inet host and port destination
iff connectionless (SOCK_DGRAM) */
+IOHandler *send_fn; /* differs between SOCK_STREAM/SOCK_DGRAM */
+bool read_poll; /* waiting to receive data? */
+bool write_poll; /* waiting to transmit data? */
} NetSocketState;
static void net_socket_accept(void *opaque);
+static void net_socket_writable(void *opaque);
+
+/* Only read packets from socket when peer can receive them */
+static int net_socket_can_send(void *opaque)
+{
+NetSocketState *s = opaque;
+
+return qemu_can_send_packet(s-nc);
+}
+
+static void net_socket_update_fd_handler(NetSocketState *s)
+{
+qemu_set_fd_handler2(s-fd,
+ s-read_poll ? net_socket_can_send : NULL,
+ s-read_poll ? s-send_fn : NULL,
+ s-write_poll ? net_socket_writable : NULL,
+ s);
+}
+
+static void net_socket_read_poll(NetSocketState *s, bool enable)
+{
+s-read_poll = enable;
+net_socket_update_fd_handler(s);
+}
+
+static void net_socket_write_poll(NetSocketState *s, bool enable)
+{
+s-write_poll = enable;
+net_socket_update_fd_handler(s);
+}
+
+static void net_socket_writable(void *opaque)
+{
+NetSocketState *s = opaque;
+
+net_socket_write_poll(s, false);
+
+qemu_flush_queued_packets(s-nc);
+}
/* XXX: we consider we can send the whole packet without blocking */
static ssize_t net_socket_receive(NetClientState *nc, const uint8_t *buf,
size_t size)
@@ -81,7 +123,8 @@ static void net_socket_send(void *opaque)
} else if (size == 0) {
/* end of connection */
eoc:
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+net_socket_read_poll(s, false);
+net_socket_write_poll(s, false);
if (s-listen_fd != -1) {
qemu_set_fd_handler(s-listen_fd, net_socket_accept, NULL, s);
}
@@ -152,7 +195,8 @@ static void net_socket_send_dgram(void *opaque)
return;
if (size == 0) {
/* end of connection */
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+net_socket_read_poll(s, false);
+net_socket_write_poll(s, false);
return;
}
qemu_send_packet(s-nc, s-buf, size);
@@ -243,7 +287,8 @@ static void net_socket_cleanup(NetClientState *nc)
{
NetSocketState *s = DO_UPCAST(NetSocketState, nc, nc);
if (s-fd != -1) {
-qemu_set_fd_handler(s-fd, NULL, NULL, NULL);
+net_socket_read_poll(s, false);
+net_socket_write_poll(s, false);
close(s-fd);
s-fd = -1;
}
@@ -314,8 +359,8 @@ static NetSocketState
*net_socket_fd_init_dgram(NetClientState *peer,
s-fd = fd;
s-listen_fd = -1;
-
-qemu_set_fd_handler(s-fd, net_socket_send_dgram, NULL, s);
+s-send_fn = net_socket_send_dgram;
+net_socket_read_poll(s, true);
/* mcast: save bound address as dst */
if (is_connected) {
@@ -332,7 +377,8 @@ err:
static void net_socket_connect(void *opaque)
{
NetSocketState *s = opaque;
-qemu_set_fd_handler(s-fd, net_socket_send, NULL, s);
+s-send_fn = net_socket_send;
+net_socket_read_poll(s, true);
}
static NetClientInfo net_socket_info = {
--
1.7.10.4
[Qemu-devel] [PATCH 02/13] e1000: flush queue whenever can_receive can go from false to true
From: Paolo Bonzini pbonz...@redhat.com
When the guests replenish the receive ring buffer, the network device
should flush its queue of pending packets. This is done with
qemu_flush_queued_packets.
e1000's can_receive can go from false to true when RCTL or RDT are
modified.
Reported-by: Luigi Rizzo ri...@iet.unipi.it
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Cc: Jan Kiszka jan.kis...@siemens.de
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Amos Kong ak...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/e1000.c |4
1 file changed, 4 insertions(+)
diff --git a/hw/e1000.c b/hw/e1000.c
index ae8a6c5..ec3a7c4 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -295,6 +295,7 @@ set_rx_control(E1000State *s, int index, uint32_t val)
s-rxbuf_min_shift = ((val / E1000_RCTL_RDMTS_QUAT) 3) + 1;
DBGOUT(RX, RCTL: %d, mac_reg[RCTL] = 0x%x\n, s-mac_reg[RDT],
s-mac_reg[RCTL]);
+qemu_flush_queued_packets(s-nic-nc);
}
static void
@@ -926,6 +927,9 @@ set_rdt(E1000State *s, int index, uint32_t val)
{
s-check_rxov = 0;
s-mac_reg[index] = val 0x;
+if (e1000_has_rxbufs(s, 1)) {
+qemu_flush_queued_packets(s-nic-nc);
+}
}
static void
--
1.7.10.4
[Qemu-devel] [PATCH 06/12] linux-user: Remove #if 0'd cpu_get_real_ticks() definition
From: Peter Maydell peter.mayd...@linaro.org
Remove the cpu_get_real_ticks() definition from linux-user/main.c.
This has been disabled via #if 0 and unused since commit 1dce7c3c22
in 2006; the definitions we actually use are in qemu-timer.h.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
linux-user/main.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 1a1c661..e84a18c 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -89,19 +89,6 @@ int cpu_get_pic_interrupt(CPUX86State *env)
}
#endif
-/* timers for rdtsc */
-
-#if 0
-
-static uint64_t emu_time;
-
-int64_t cpu_get_real_ticks(void)
-{
-return emu_time++;
-}
-
-#endif
-
#if defined(CONFIG_USE_NPTL)
/***/
/* Helper routines for implementing atomic operations. */
--
1.7.10.4
Re: [Qemu-devel] [PATCH 06/12] linux-user: Remove #if 0'd cpu_get_real_ticks() definition
On Fri, Sep 14, 2012 at 09:42:20AM +0100, Stefan Hajnoczi wrote:
From: Peter Maydell peter.mayd...@linaro.org
Remove the cpu_get_real_ticks() definition from linux-user/main.c.
This has been disabled via #if 0 and unused since commit 1dce7c3c22
in 2006; the definitions we actually use are in qemu-timer.h.
Signed-off-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Acked-by: Riku Voipio riku.voi...@linaro.org
---
linux-user/main.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 1a1c661..e84a18c 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -89,19 +89,6 @@ int cpu_get_pic_interrupt(CPUX86State *env)
}
#endif
-/* timers for rdtsc */
-
-#if 0
-
-static uint64_t emu_time;
-
-int64_t cpu_get_real_ticks(void)
-{
-return emu_time++;
-}
-
-#endif
-
#if defined(CONFIG_USE_NPTL)
/***/
/* Helper routines for implementing atomic operations. */
--
1.7.10.4
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On Fri, Sep 14, 2012 at 11:39:38AM +0400, Michael Tokarev wrote: What's the difference between the two except that the latter adds some more instructions (actually whole new subsytem) to the former? Why do we need -i386, what -x86_64 does not do which does -i386? AFAIK, qemu-system-x86_64 does not support KVM on a 32-bit host. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On 14.09.2012 13:33, Daniel P. Berrange wrote: On Fri, Sep 14, 2012 at 11:39:38AM +0400, Michael Tokarev wrote: What's the difference between the two except that the latter adds some more instructions (actually whole new subsytem) to the former? Why do we need -i386, what -x86_64 does not do which does -i386? AFAIK, qemu-system-x86_64 does not support KVM on a 32-bit host. Isn't it the other way around? Or, does qemu-system-i386 EVER support kvm? Thanks, /mjt
[Qemu-devel] [PATCH 08/12] console: Clean up bytes per pixel calculation
From: BALATON Zoltan bala...@eik.bme.hu
Division with round up is the correct way to compute this even if the
only case where division with round down gives incorrect result is
probably 15 bpp. This case was explicitely patched up in one of these
functions but was unhandled in the other. (I'm not sure about setting
16 bpp for the 15bpp case either but I left that there for now.)
Signed-off-by: BALATON Zoltan bala...@eik.bme.hu
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
console.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/console.c b/console.c
index c1ed5e0..a8bcc42 100644
--- a/console.c
+++ b/console.c
@@ -1612,7 +1612,7 @@ PixelFormat qemu_different_endianness_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
@@ -1661,13 +1661,12 @@ PixelFormat qemu_default_pixelformat(int bpp)
memset(pf, 0x00, sizeof(PixelFormat));
pf.bits_per_pixel = bpp;
-pf.bytes_per_pixel = bpp / 8;
+pf.bytes_per_pixel = DIV_ROUND_UP(bpp, 8);
pf.depth = bpp == 32 ? 24 : bpp;
switch (bpp) {
case 15:
pf.bits_per_pixel = 16;
-pf.bytes_per_pixel = 2;
pf.rmask = 0x7c00;
pf.gmask = 0x03E0;
pf.bmask = 0x001F;
--
1.7.10.4
[Qemu-devel] [PATCH 04/12] Spelling fixes in comments and macro names (ressource - resource)
From: Stefan Weil s...@weilnetz.de
Macro XEN_HOST_PCI_RESOURCE_BUFFER_SIZE is only used locally,
so the change should be safe.
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/xen-host-pci-device.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xen-host-pci-device.c b/hw/xen-host-pci-device.c
index e7ff680..743b37b 100644
--- a/hw/xen-host-pci-device.c
+++ b/hw/xen-host-pci-device.c
@@ -47,13 +47,13 @@ static int xen_host_pci_sysfs_path(const XenHostPCIDevice
*d,
}
-/* This size should be enough to read the first 7 lines of a ressource file */
-#define XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE 400
+/* This size should be enough to read the first 7 lines of a resource file */
+#define XEN_HOST_PCI_RESOURCE_BUFFER_SIZE 400
static int xen_host_pci_get_resource(XenHostPCIDevice *d)
{
int i, rc, fd;
char path[PATH_MAX];
-char buf[XEN_HOST_PCI_RESSOURCE_BUFFER_SIZE];
+char buf[XEN_HOST_PCI_RESOURCE_BUFFER_SIZE];
unsigned long long start, end, flags, size;
char *endptr, *s;
uint8_t type;
--
1.7.10.4
[Qemu-devel] [PATCH 11/12] arch_init.c: add missing '%' symbols before PRIu64 in debug printfs
From: Igor Mitsyanko i.mitsya...@samsung.com
'%' symbols were missing in front of PRIu64 macros in DPRINTF() messages in
arch_init.c, this caused compilation warnings when compiled with
DEBUG_ARCH_INIT defined.
Signed-off-by: Igor Mitsyanko i.mitsya...@samsung.com
Signed-off-by: Stefan Hajnoczi stefa...@gmail.com
---
arch_init.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 5a1173e..47977de 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -562,7 +562,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
if ((i 63) == 0) {
uint64_t t1 = (qemu_get_clock_ns(rt_clock) - bwidth) / 100;
if (t1 MAX_WAIT) {
-DPRINTF(big wait: PRIu64 milliseconds, %d iterations\n,
+DPRINTF(big wait: % PRIu64 milliseconds, %d iterations\n,
t1, i);
break;
}
@@ -587,7 +587,7 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
-DPRINTF(ram_save_live: expected( PRIu64 ) = max( PRIu64 )?\n,
+DPRINTF(ram_save_live: expected(% PRIu64 ) = max(% PRIu64 )?\n,
expected_time, migrate_max_downtime());
if (expected_time = migrate_max_downtime()) {
@@ -799,8 +799,8 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
} while (!(flags RAM_SAVE_FLAG_EOS));
done:
-DPRINTF(Completed load of VM with exit code %d seq iteration PRIu64
\n,
-ret, seq_iter);
+DPRINTF(Completed load of VM with exit code %d seq iteration
+% PRIu64 \n, ret, seq_iter);
return ret;
}
--
1.7.10.4
[Qemu-devel] [PATCH 12/13] net: EAGAIN handling for net/socket.c UDP
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Implement asynchronous send for UDP (or other SOCK_DGRAM) sockets. If
send fails with EAGAIN we wait for the socket to become writable again.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/socket.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 7bff536..aabf0a4 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -102,9 +102,19 @@ static ssize_t net_socket_receive(NetClientState *nc,
const uint8_t *buf, size_t
static ssize_t net_socket_receive_dgram(NetClientState *nc, const uint8_t
*buf, size_t size)
{
NetSocketState *s = DO_UPCAST(NetSocketState, nc, nc);
+ssize_t ret;
-return sendto(s-fd, (const void *)buf, size, 0,
- (struct sockaddr *)s-dgram_dst, sizeof(s-dgram_dst));
+do {
+ret = sendto(s-fd, buf, size, 0,
+ (struct sockaddr *)s-dgram_dst,
+ sizeof(s-dgram_dst));
+} while (ret == -1 errno == EINTR);
+
+if (ret == -1 errno == EAGAIN) {
+net_socket_write_poll(s, true);
+return 0;
+}
+return ret;
}
static void net_socket_send(void *opaque)
--
1.7.10.4
[Qemu-devel] [PATCH 03/13] xen: flush queue when getting an event
From: Paolo Bonzini pbonz...@redhat.com
xen does not have a register that, when written, will cause can_receive
to go from false to true. However, flushing the queue can be attempted
whenever the front-end raises its side of the Xen event channel. There
is a single event channel for tx and rx.
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Amos Kong ak...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/xen_nic.c |1 +
1 file changed, 1 insertion(+)
diff --git a/hw/xen_nic.c b/hw/xen_nic.c
index 8b79bfb..cf7d559 100644
--- a/hw/xen_nic.c
+++ b/hw/xen_nic.c
@@ -415,6 +415,7 @@ static void net_event(struct XenDevice *xendev)
{
struct XenNetDev *netdev = container_of(xendev, struct XenNetDev, xendev);
net_tx_packets(netdev);
+qemu_flush_queued_packets(netdev-nic-nc);
}
static int net_free(struct XenDevice *xendev)
--
1.7.10.4
[Qemu-devel] [PATCH 03/12] Fix spelling (licenced - licensed) in GPL
From: Stefan Weil s...@weilnetz.de The patch also fixes the case of written. Signed-off-by: Stefan Weil s...@weilnetz.de Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- hw/imx_avic.c |4 ++-- hw/imx_timer.c |4 ++-- hw/kzm.c |2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/hw/imx_avic.c b/hw/imx_avic.c index 4f010e8..b1a8fe6 100644 --- a/hw/imx_avic.c +++ b/hw/imx_avic.c @@ -6,9 +6,9 @@ * * Copyright (c) 2008 OKL * Copyright (c) 2011 NICTA Pty Ltd - * Originally Written by Hans Jiang + * Originally written by Hans Jiang * - * This code is licenced under the GPL version 2 or later. See + * This code is licensed under the GPL version 2 or later. See * the COPYING file in the top-level directory. * * TODO: implement vectors. diff --git a/hw/imx_timer.c b/hw/imx_timer.c index 16215cc..c28c537 100644 --- a/hw/imx_timer.c +++ b/hw/imx_timer.c @@ -3,10 +3,10 @@ * * Copyright (c) 2008 OK Labs * Copyright (c) 2011 NICTA Pty Ltd - * Originally Written by Hans Jiang + * Originally written by Hans Jiang * Updated by Peter Chubb * - * This code is licenced under GPL version 2 or later. See + * This code is licensed under GPL version 2 or later. See * the COPYING file in the top-level directory. * */ diff --git a/hw/kzm.c b/hw/kzm.c index 6a5e9df..68cd1b4 100644 --- a/hw/kzm.c +++ b/hw/kzm.c @@ -5,7 +5,7 @@ * Written by Hans at OK-Labs * Updated by Peter Chubb. * - * This code is licenced under the GPL, version 2 or later. + * This code is licensed under the GPL, version 2 or later. * See the file `COPYING' in the top level directory. * * It (partially) emulates a Kyoto Microcomputer -- 1.7.10.4
[Qemu-devel] [PATCH 05/12] ui: Fix spelling in comment (ressource - resource)
From: Stefan Weil s...@weilnetz.de The function is called interface_release_resource. Signed-off-by: Stefan Weil s...@weilnetz.de Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- ui/spice-display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ui/spice-display.c b/ui/spice-display.c index 99bc665..11f55c4 100644 --- a/ui/spice-display.c +++ b/ui/spice-display.c @@ -243,7 +243,7 @@ static SimpleSpiceUpdate *qemu_spice_create_update(SimpleSpiceDisplay *ssd) } /* - * Called from spice server thread context (via interface_release_ressource) + * Called from spice server thread context (via interface_release_resource) * We do *not* hold the global qemu mutex here, so extra care is needed * when calling qemu functions. QEMU interfaces used: *- g_free (underlying glibc free is re-entrant). -- 1.7.10.4
[Qemu-devel] [PATCH 06/13] net: do not report queued packets as sent
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Net send functions have a return value where 0 means the packet has not
been sent and will be queued. A non-zero value means the packet was
sent or an error caused the packet to be dropped.
This patch fixes two instances where packets are queued but we return
their size. This causes callers to believe the packets were sent. When
the caller uses the async send interface this creates a real problem
because the callback will be invoked for a packet that the caller
believed to be already sent. This bug can cause double-frees in the
caller.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/queue.c | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/net/queue.c b/net/queue.c
index 6e64091..254f280 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -83,12 +83,12 @@ void qemu_del_net_queue(NetQueue *queue)
g_free(queue);
}
-static ssize_t qemu_net_queue_append(NetQueue *queue,
- NetClientState *sender,
- unsigned flags,
- const uint8_t *buf,
- size_t size,
- NetPacketSent *sent_cb)
+static void qemu_net_queue_append(NetQueue *queue,
+ NetClientState *sender,
+ unsigned flags,
+ const uint8_t *buf,
+ size_t size,
+ NetPacketSent *sent_cb)
{
NetPacket *packet;
@@ -100,16 +100,14 @@ static ssize_t qemu_net_queue_append(NetQueue *queue,
memcpy(packet-data, buf, size);
QTAILQ_INSERT_TAIL(queue-packets, packet, entry);
-
-return size;
}
-static ssize_t qemu_net_queue_append_iov(NetQueue *queue,
- NetClientState *sender,
- unsigned flags,
- const struct iovec *iov,
- int iovcnt,
- NetPacketSent *sent_cb)
+static void qemu_net_queue_append_iov(NetQueue *queue,
+ NetClientState *sender,
+ unsigned flags,
+ const struct iovec *iov,
+ int iovcnt,
+ NetPacketSent *sent_cb)
{
NetPacket *packet;
size_t max_len = 0;
@@ -133,8 +131,6 @@ static ssize_t qemu_net_queue_append_iov(NetQueue *queue,
}
QTAILQ_INSERT_TAIL(queue-packets, packet, entry);
-
-return packet-size;
}
static ssize_t qemu_net_queue_deliver(NetQueue *queue,
@@ -177,7 +173,8 @@ ssize_t qemu_net_queue_send(NetQueue *queue,
ssize_t ret;
if (queue-delivering || !qemu_can_send_packet(sender)) {
-return qemu_net_queue_append(queue, sender, flags, data, size,
sent_cb);
+qemu_net_queue_append(queue, sender, flags, data, size, sent_cb);
+return 0;
}
ret = qemu_net_queue_deliver(queue, sender, flags, data, size);
@@ -201,8 +198,8 @@ ssize_t qemu_net_queue_send_iov(NetQueue *queue,
ssize_t ret;
if (queue-delivering || !qemu_can_send_packet(sender)) {
-return qemu_net_queue_append_iov(queue, sender, flags,
- iov, iovcnt, sent_cb);
+qemu_net_queue_append_iov(queue, sender, flags, iov, iovcnt, sent_cb);
+return 0;
}
ret = qemu_net_queue_deliver_iov(queue, sender, flags, iov, iovcnt);
--
1.7.10.4
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On 2012-09-14 11:39, Michael Tokarev wrote: On 14.09.2012 13:33, Daniel P. Berrange wrote: On Fri, Sep 14, 2012 at 11:39:38AM +0400, Michael Tokarev wrote: What's the difference between the two except that the latter adds some more instructions (actually whole new subsytem) to the former? Why do we need -i386, what -x86_64 does not do which does -i386? AFAIK, qemu-system-x86_64 does not support KVM on a 32-bit host. Isn't it the other way around? Or, does qemu-system-i386 EVER support kvm? It does support KVM on 32-bit (minus undiscovered bugs in 32-bit-only kernel code paths once in a while - none known right now, though). Don't confuse old qemu-kvm with QEMU here. The latter always supported KVM with both variants, and qemu-kvm now also does as it stopped being different. The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on the TCG side: We measured noticeable performance benefits when running 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I don't have numbers at hand, but colleagues decided to use the 32-bit version for that reason (when no KVM is available). Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 09/13] net: fix usbnet_receive() packet drops
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
The USB network interface has a single buffer which the guest reads
from. This patch prevents multiple calls to usbnet_receive() from
clobbering the input buffer. Instead we queue packets until buffer
space becomes available again.
This is inspired by virtio-net and e1000 rxbuf handling.
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/usb/dev-network.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/hw/usb/dev-network.c b/hw/usb/dev-network.c
index 0b5cb71..e4a4359 100644
--- a/hw/usb/dev-network.c
+++ b/hw/usb/dev-network.c
@@ -1001,6 +1001,13 @@ static int rndis_keepalive_response(USBNetState *s,
return 0;
}
+/* Prepare to receive the next packet */
+static void usb_net_reset_in_buf(USBNetState *s)
+{
+s-in_ptr = s-in_len = 0;
+qemu_flush_queued_packets(s-nic-nc);
+}
+
static int rndis_parse(USBNetState *s, uint8_t *data, int length)
{
uint32_t msg_type;
@@ -1025,7 +1032,8 @@ static int rndis_parse(USBNetState *s, uint8_t *data, int
length)
case RNDIS_RESET_MSG:
rndis_clear_responsequeue(s);
-s-out_ptr = s-in_ptr = s-in_len = 0;
+s-out_ptr = 0;
+usb_net_reset_in_buf(s);
return rndis_reset_response(s, (rndis_reset_msg_type *) data);
case RNDIS_KEEPALIVE_MSG:
@@ -1135,7 +1143,7 @@ static int usb_net_handle_datain(USBNetState *s,
USBPacket *p)
int ret = USB_RET_NAK;
if (s-in_ptr s-in_len) {
-s-in_ptr = s-in_len = 0;
+usb_net_reset_in_buf(s);
ret = USB_RET_NAK;
return ret;
}
@@ -1152,7 +1160,7 @@ static int usb_net_handle_datain(USBNetState *s,
USBPacket *p)
if (s-in_ptr = s-in_len
(is_rndis(s) || (s-in_len (64 - 1)) || !ret)) {
/* no short packet necessary */
-s-in_ptr = s-in_len = 0;
+usb_net_reset_in_buf(s);
}
#ifdef TRAFFIC_DEBUG
@@ -1263,6 +1271,11 @@ static ssize_t usbnet_receive(NetClientState *nc, const
uint8_t *buf, size_t siz
return -1;
}
+/* Only accept packet if input buffer is empty */
+if (s-in_len 0) {
+return 0;
+}
+
if (is_rndis(s)) {
struct rndis_packet_msg_type *msg;
--
1.7.10.4
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On 14.09.2012 14:00, Jan Kiszka wrote: [] The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on the TCG side: We measured noticeable performance benefits when running 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I don't have numbers at hand, but colleagues decided to use the 32-bit version for that reason (when no KVM is available). Interesting. Maybe someone should look at the difference on TCG side and merge interesting bits from i386 to x86_64... :) The thing is: x86_64 becomes the only x86 platform these days, or at least the MAIN platform. Thank you for the clarification -- very useful information indeed! /mjt
[Qemu-devel] [PATCH 09/12] qapi: Fix enumeration typo error
From: Lei Li li...@linux.vnet.ibm.com Signed-off-by: Lei Li li...@linux.vnet.ibm.com Reviewed-by: Luiz Capitulino lcapitul...@redhat.com Signed-off-by: Stefan Hajnoczi stefa...@gmail.com --- qapi-schema-guest.json |2 +- qapi-schema.json |4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json index d955cf1..ed0eb69 100644 --- a/qapi-schema-guest.json +++ b/qapi-schema-guest.json @@ -293,7 +293,7 @@ ## # @GuestFsFreezeStatus # -# An enumation of filesystem freeze states +# An enumeration of filesystem freeze states # # @thawed: filesystems thawed/unfrozen # diff --git a/qapi-schema.json b/qapi-schema.json index a9f465a..24f5da0 100644 --- a/qapi-schema.json +++ b/qapi-schema.json @@ -118,7 +118,7 @@ ## # @RunState # -# An enumation of VM run states. +# An enumeration of VM run states. # # @debug: QEMU is running on a debugger # @@ -785,7 +785,7 @@ ## # @SpiceQueryMouseMode # -# An enumation of Spice mouse states. +# An enumeration of Spice mouse states. # # @client: Mouse cursor position is determined by the client. # -- 1.7.10.4
[Qemu-devel] [PATCH 01/13] net: notify iothread after flushing queue
From: Paolo Bonzini pbonz...@redhat.com
virtio-net has code to flush the queue and notify the iothread
whenever new receive buffers are added by the guest. That is
fine, and indeed we need to do the same in all other drivers.
However, notifying the iothread should be work for the network
subsystem. And since we are at it we can add a little smartness:
if some of the queued packets already could not be delivered,
there is no need to notify the iothread.
Reported-by: Luigi Rizzo ri...@iet.unipi.it
Cc: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Cc: Jan Kiszka jan.kis...@siemens.de
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
Reviewed-by: Amos Kong ak...@redhat.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
hw/virtio-net.c |4
net.c |7 ++-
net/queue.c |5 +++--
net/queue.h |2 +-
4 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index b1998b2..6490743 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -447,10 +447,6 @@ static void virtio_net_handle_rx(VirtIODevice *vdev,
VirtQueue *vq)
VirtIONet *n = to_virtio_net(vdev);
qemu_flush_queued_packets(n-nic-nc);
-
-/* We now have RX buffers, signal to the IO thread to break out of the
- * select to re-poll the tap file descriptor */
-qemu_notify_event();
}
static int virtio_net_can_receive(NetClientState *nc)
diff --git a/net.c b/net.c
index e5d25d4..d9ba1e5 100644
--- a/net.c
+++ b/net.c
@@ -357,7 +357,12 @@ void qemu_flush_queued_packets(NetClientState *nc)
{
nc-receive_disabled = 0;
-qemu_net_queue_flush(nc-send_queue);
+if (qemu_net_queue_flush(nc-send_queue)) {
+/* We emptied the queue successfully, signal to the IO thread to repoll
+ * the file descriptor (for tap, for example).
+ */
+qemu_notify_event();
+}
}
static ssize_t qemu_send_packet_async_with_flags(NetClientState *sender,
diff --git a/net/queue.c b/net/queue.c
index e8030aa..6e64091 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -228,7 +228,7 @@ void qemu_net_queue_purge(NetQueue *queue, NetClientState
*from)
}
}
-void qemu_net_queue_flush(NetQueue *queue)
+bool qemu_net_queue_flush(NetQueue *queue)
{
while (!QTAILQ_EMPTY(queue-packets)) {
NetPacket *packet;
@@ -244,7 +244,7 @@ void qemu_net_queue_flush(NetQueue *queue)
packet-size);
if (ret == 0) {
QTAILQ_INSERT_HEAD(queue-packets, packet, entry);
-break;
+return false;
}
if (packet-sent_cb) {
@@ -253,4 +253,5 @@ void qemu_net_queue_flush(NetQueue *queue)
g_free(packet);
}
+return true;
}
diff --git a/net/queue.h b/net/queue.h
index 9d44a9b..fc02b33 100644
--- a/net/queue.h
+++ b/net/queue.h
@@ -53,6 +53,6 @@ ssize_t qemu_net_queue_send_iov(NetQueue *queue,
NetPacketSent *sent_cb);
void qemu_net_queue_purge(NetQueue *queue, NetClientState *from);
-void qemu_net_queue_flush(NetQueue *queue);
+bool qemu_net_queue_flush(NetQueue *queue);
#endif /* QEMU_NET_QUEUE_H */
--
1.7.10.4
[Qemu-devel] [PATCH 07/12] Fix copypaste typos in documentation comments
From: BALATON Zoltan bala...@eik.bme.hu Signed-off-by: BALATON Zoltan bala...@eik.bme.hu Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com --- memory.h | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/memory.h b/memory.h index bd1bbae..f6c8e32 100644 --- a/memory.h +++ b/memory.h @@ -252,9 +252,9 @@ void memory_region_init_ram(MemoryRegion *mr, uint64_t size); /** - * memory_region_init_ram: Initialize RAM memory region from a user-provided. - * pointer. Accesses into the region will modify - * memory directly. + * memory_region_init_ram_ptr: Initialize RAM memory region from a + * user-provided pointer. Accesses into the + * region will modify memory directly. * * @mr: the #MemoryRegion to be initialized. * @name: the name of the region. @@ -581,7 +581,8 @@ void memory_region_add_subregion(MemoryRegion *mr, target_phys_addr_t offset, MemoryRegion *subregion); /** - * memory_region_add_subregion: Add a subregion to a container, with overlap. + * memory_region_add_subregion_overlap: Add a subregion to a container + * with overlap. * * Adds a subregion at @offset. The subregion may overlap with other * subregions. Conflicts are resolved by having a higher @priority hide a @@ -743,7 +744,7 @@ void memory_listener_unregister(MemoryListener *listener); void memory_global_dirty_log_start(void); /** - * memory_global_dirty_log_stop: begin dirty logging for all regions + * memory_global_dirty_log_stop: end dirty logging for all regions */ void memory_global_dirty_log_stop(void); -- 1.7.10.4
[Qemu-devel] [PATCH 13/13] net: EAGAIN handling for net/socket.c TCP
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Replace spinning send_all() with a proper non-blocking send. When the
socket write buffer limit is reached, we should stop trying to send and
wait for the socket to become writable again.
Non-blocking TCP sockets can return in two different ways when the write
buffer limit is reached:
1. ret = -1 and errno = EAGAIN/EWOULDBLOCK. No data has been written.
2. ret total_size. Short write, only part of the message was
transmitted.
Handle both cases and keep track of how many bytes have been written in
s-send_index. (This includes the 'length' header before the actual
payload buffer.)
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
net/socket.c | 36 +++-
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index aabf0a4..5e0c92e 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -32,6 +32,7 @@
#include qemu-error.h
#include qemu-option.h
#include qemu_socket.h
+#include iov.h
typedef struct NetSocketState {
NetClientState nc;
@@ -40,6 +41,7 @@ typedef struct NetSocketState {
int state; /* 0 = getting length, 1 = getting data */
unsigned int index;
unsigned int packet_len;
+unsigned int send_index; /* number of bytes sent (only SOCK_STREAM) */
uint8_t buf[4096];
struct sockaddr_in dgram_dst; /* contains inet host and port destination
iff connectionless (SOCK_DGRAM) */
IOHandler *send_fn; /* differs between SOCK_STREAM/SOCK_DGRAM */
@@ -88,15 +90,39 @@ static void net_socket_writable(void *opaque)
qemu_flush_queued_packets(s-nc);
}
-/* XXX: we consider we can send the whole packet without blocking */
static ssize_t net_socket_receive(NetClientState *nc, const uint8_t *buf,
size_t size)
{
NetSocketState *s = DO_UPCAST(NetSocketState, nc, nc);
-uint32_t len;
-len = htonl(size);
+uint32_t len = htonl(size);
+struct iovec iov[] = {
+{
+.iov_base = len,
+.iov_len = sizeof(len),
+}, {
+.iov_base = (void *)buf,
+.iov_len = size,
+},
+};
+size_t remaining;
+ssize_t ret;
+
+remaining = iov_size(iov, 2) - s-send_index;
+ret = iov_send(s-fd, iov, 2, s-send_index, remaining);
-send_all(s-fd, (const uint8_t *)len, sizeof(len));
-return send_all(s-fd, buf, size);
+if (ret == -1 errno == EAGAIN) {
+ret = 0; /* handled further down */
+}
+if (ret == -1) {
+s-send_index = 0;
+return -errno;
+}
+if (ret (ssize_t)remaining) {
+s-send_index += ret;
+net_socket_write_poll(s, true);
+return 0;
+}
+s-send_index = 0;
+return size;
}
static ssize_t net_socket_receive_dgram(NetClientState *nc, const uint8_t
*buf, size_t size)
--
1.7.10.4
[Qemu-devel] [PATCH 12/12] configure: fix seccomp check
From: Yann E. MORIN yann.morin.1...@free.fr Currently, if libseccomp is missing but the user explicitly requested seccomp support using --enable-seccomp, configure silently ignores the situation and disables seccomp support. This is unlike all other tests that explicitly fail in such situation. Fix that. Signed-off-by: Yann E. MORIN yann.morin.1...@free.fr Reviewed-by: Andreas Färber afaer...@suse.de Signed-off-by: Stefan Hajnoczi stefa...@gmail.com --- configure |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 7656c32b..92c4076 100755 --- a/configure +++ b/configure @@ -1431,10 +1431,10 @@ if test $seccomp != no ; then LIBS=`$pkg_config --libs libseccomp` seccomp=yes else - seccomp=no if test $seccomp = yes; then feature_not_found libseccomp fi + seccomp=no fi fi ## -- 1.7.10.4
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On 2012-09-14 12:03, Michael Tokarev wrote: On 14.09.2012 14:00, Jan Kiszka wrote: [] The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on the TCG side: We measured noticeable performance benefits when running 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I don't have numbers at hand, but colleagues decided to use the 32-bit version for that reason (when no KVM is available). Interesting. Maybe someone should look at the difference on TCG side and merge interesting bits from i386 to x86_64... :) I suppose the difference - for our use cases at least - lies in the different register and address sizes. Maybe there is room for more runtime optimizations, we never looked in that details as -i386 still works fine. And, if you are on 32-bit host (see below) - but we aren't, qemu-system-x86_64 hurts even more. The thing is: x86_64 becomes the only x86 platform these days, or at least the MAIN platform. I know, and I'm telling everyone. Still, too many crazy people keep on installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will improve this. Thank you for the clarification -- very useful information indeed! /mjt You are welcome. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 04/13] eepro100: Fix network hang when rx buffers run out
From: Bo Yang boy...@suse.com
This is reported by QA. When installing os with pxe, after the initial
kernel and initrd are loaded, the procedure tries to copy files from install
server to local harddisk, the network becomes stall because of running out of
receive descriptor.
[Whitespace fixes and removed qemu_notify_event() because Paolo's
earlier net patches have moved it into qemu_flush_queued_packets().
Additional info:
I can reproduce the network hang with a tap device doing a iPXE HTTP
boot as follows:
$ qemu -enable-kvm -m 1024 \
-netdev tap,id=netdev0,script=no,downscript=no \
-device i82559er,netdev=netdev0,romfile=80861209.rom \
-drive if=virtio,cache=none,file=test.img
iPXE ifopen net0
iPXE config # set static network configuration
iPXE kernel
http://mirror.bytemark.co.uk/fedora/linux/releases/17/Fedora/x86_64/os/images/pxeboot/vmlinuz
I needed a vanilla iPXE ROM to get to the iPXE prompt. I think the boot
prompt has been disabled in the ROMs that ship with QEMU to reduce boot
time.
During the vmlinuz HTTP download there is a network hang. hw/eepro100.c
has reached the end of the rx descriptor list. When the iPXE driver
replenishes the rx descriptor list we don't kick the QEMU net subsystem
and event loop, thereby leaving the tap netdev without its file
descriptor in select(2).
Stefan Hajnoczi stefa...@gmail.com]
Signed-off-by: Bo Yang boy...@suse.com
Signed-off-by: Stefan Hajnoczi stefa...@gmail.com
---
hw/eepro100.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 50d117e..5b23116 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -1036,6 +1036,7 @@ static void eepro100_ru_command(EEPRO100State * s,
uint8_t val)
}
set_ru_state(s, ru_ready);
s-ru_offset = e100_read_reg4(s, SCBPointer);
+qemu_flush_queued_packets(s-nic-nc);
TRACE(OTHER, logout(val=0x%02x (rx start)\n, val));
break;
case RX_RESUME:
@@ -1770,7 +1771,8 @@ static ssize_t nic_receive(NetClientState *nc, const
uint8_t * buf, size_t size)
if (rfd_command COMMAND_EL) {
/* EL bit is set, so this was the last frame. */
logout(receive: Running out of frames\n);
-set_ru_state(s, ru_suspended);
+set_ru_state(s, ru_no_resources);
+eepro100_rnr_interrupt(s);
}
if (rfd_command COMMAND_S) {
/* S bit is set. */
--
1.7.10.4
[Qemu-devel] [PATCH 07/13] net: add -netdev options to man page
From: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
Document the -netdev syntax which supercedes the older -net syntax.
This patch is a first step to making -netdev prominent in the QEMU
manual.
Reported-by: Anatoly Techtonik techto...@gmail.com
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
qemu-options.hx |7 +++
1 file changed, 7 insertions(+)
diff --git a/qemu-options.hx b/qemu-options.hx
index 804a2d1..0977b3f 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1357,6 +1357,7 @@ Valid values for @var{type} are
Not all devices are supported on all targets. Use -net nic,model=?
for a list of available devices for your target.
+@item -netdev user,id=@var{id}[,@var{option}][,@var{option}][,...]
@item -net user[,@var{option}][,@var{option}][,...]
Use the user mode network stack which requires no administrator
privilege to run. Valid options are:
@@ -1365,6 +1366,7 @@ privilege to run. Valid options are:
@item vlan=@var{n}
Connect user mode stack to VLAN @var{n} (@var{n} = 0 is the default).
+@item id=@var{id}
@item name=@var{name}
Assign symbolic name for use in monitor commands.
@@ -1490,6 +1492,7 @@ processed and applied to -net user. Mixing them with the
new configuration
syntax gives undefined results. Their use for new applications is discouraged
as they will be removed from future versions.
+@item -netdev
tap,id=@var{id}[,fd=@var{h}][,ifname=@var{name}][,script=@var{file}][,downscript=@var{dfile}][,helper=@var{helper}]
@item -net
tap[,vlan=@var{n}][,name=@var{name}][,fd=@var{h}][,ifname=@var{name}][,script=@var{file}][,downscript=@var{dfile}][,helper=@var{helper}]
Connect the host TAP network interface @var{name} to VLAN @var{n}.
@@ -1529,6 +1532,7 @@ qemu-system-i386 linux.img \
-net nic -net
tap,helper=/usr/local/libexec/qemu-bridge-helper
@end example
+@item -netdev bridge,id=@var{id}[,br=@var{bridge}][,helper=@var{helper}]
@item -net
bridge[,vlan=@var{n}][,name=@var{name}][,br=@var{bridge}][,helper=@var{helper}]
Connect a host TAP network interface to a host bridge device.
@@ -1551,6 +1555,7 @@ qemu-system-i386 linux.img -net bridge -net
nic,model=virtio
qemu-system-i386 linux.img -net bridge,br=qemubr0 -net nic,model=virtio
@end example
+@item -netdev
socket,id=@var{id}[,fd=@var{h}][,listen=[@var{host}]:@var{port}][,connect=@var{host}:@var{port}]
@item -net socket[,vlan=@var{n}][,name=@var{name}][,fd=@var{h}]
[,listen=[@var{host}]:@var{port}][,connect=@var{host}:@var{port}]
Connect the VLAN @var{n} to a remote VLAN in another QEMU virtual
@@ -1573,6 +1578,7 @@ qemu-system-i386 linux.img \
-net socket,connect=127.0.0.1:1234
@end example
+@item -netdev
socket,id=@var{id}[,fd=@var{h}][,mcast=@var{maddr}:@var{port}[,localaddr=@var{addr}]]
@item -net
socket[,vlan=@var{n}][,name=@var{name}][,fd=@var{h}][,mcast=@var{maddr}:@var{port}[,localaddr=@var{addr}]]
Create a VLAN @var{n} shared with another QEMU virtual
@@ -1624,6 +1630,7 @@ qemu-system-i386 linux.img \
-net socket,mcast=239.192.168.1:1102,localaddr=1.2.3.4
@end example
+@item -netdev
vde,id=@var{id}[,sock=@var{socketpath}][,port=@var{n}][,group=@var{groupname}][,mode=@var{octalmode}]
@item -net vde[,vlan=@var{n}][,name=@var{name}][,sock=@var{socketpath}]
[,port=@var{n}][,group=@var{groupname}][,mode=@var{octalmode}]
Connect VLAN @var{n} to PORT @var{n} of a vde switch running on host and
listening for incoming connections on @var{socketpath}. Use GROUP
@var{groupname}
--
1.7.10.4
[Qemu-devel] [PATCH 02/12] Spelling fixes in comments and documentation
From: Stefan Weil s...@weilnetz.de
These wrong spellings were detected by codespell:
* successully - successfully
* alot - a lot
* wanna - want to
* infomation - information
* occured - occurred
[also is - is also and ressources - resources suggested by
Peter Maydell peter.mayd...@linaro.org]
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Stefan Hajnoczi stefa...@linux.vnet.ibm.com
---
docs/specs/ppc-spapr-hcalls.txt |2 +-
docs/usb2.txt |4 ++--
hw/xen_pt.h |4 ++--
hw/xen_pt_config_init.c | 14 +++---
qemu-img.c |2 +-
qemu-img.texi |2 +-
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/docs/specs/ppc-spapr-hcalls.txt b/docs/specs/ppc-spapr-hcalls.txt
index 52ba8d4..667b3fa 100644
--- a/docs/specs/ppc-spapr-hcalls.txt
+++ b/docs/specs/ppc-spapr-hcalls.txt
@@ -31,7 +31,7 @@ Arguments:
Returns:
- H_SUCCESS : Successully called the RTAS function (RTAS result
+ H_SUCCESS : Successfully called the RTAS function (RTAS result
will have been stored in the parameter block)
H_PARAMETER : Unknown token
diff --git a/docs/usb2.txt b/docs/usb2.txt
index d17e3c0..43dacde 100644
--- a/docs/usb2.txt
+++ b/docs/usb2.txt
@@ -58,11 +58,11 @@ try ...
xhci controller support
---
-There also is xhci host controller support available. It got alot
+There is also xhci host controller support available. It got a lot
less testing than ehci and there are a bunch of known limitations, so
ehci may work better for you. On the other hand the xhci hardware
design is much more virtualization-friendly, thus xhci emulation uses
-less ressources (especially cpu). If you wanna give xhci a try
+less resources (especially cpu). If you want to give xhci a try
use this to add the host controller ...
qemu -device nec-usb-xhci,id=xhci
diff --git a/hw/xen_pt.h b/hw/xen_pt.h
index 41904ec..112477a 100644
--- a/hw/xen_pt.h
+++ b/hw/xen_pt.h
@@ -96,7 +96,7 @@ typedef struct XenPTRegion {
* - do NOT use ALL F for init_val, otherwise the tbl will not be registered.
*/
-/* emulated register infomation */
+/* emulated register information */
struct XenPTRegInfo {
uint32_t offset;
uint32_t size;
@@ -140,7 +140,7 @@ typedef int (*xen_pt_reg_size_init_fn)
(XenPCIPassthroughState *, const XenPTRegGroupInfo *,
uint32_t base_offset, uint8_t *size);
-/* emulated register group infomation */
+/* emulated register group information */
struct XenPTRegGroupInfo {
uint8_t grp_id;
XenPTRegisterGroupType grp_type;
diff --git a/hw/xen_pt_config_init.c b/hw/xen_pt_config_init.c
index 00eb3d9..e524a40 100644
--- a/hw/xen_pt_config_init.c
+++ b/hw/xen_pt_config_init.c
@@ -562,7 +562,7 @@ static int
xen_pt_exp_rom_bar_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* Header Type0 reg static infomation table */
+/* Header Type0 reg static information table */
static XenPTRegInfo xen_pt_emu_reg_header0[] = {
/* Vendor ID reg */
{
@@ -753,7 +753,7 @@ static XenPTRegInfo xen_pt_emu_reg_header0[] = {
* Vital Product Data Capability
*/
-/* Vital Product Data Capability Structure reg static infomation table */
+/* Vital Product Data Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
{
.offset = PCI_CAP_LIST_NEXT,
@@ -775,7 +775,7 @@ static XenPTRegInfo xen_pt_emu_reg_vpd[] = {
* Vendor Specific Capability
*/
-/* Vendor Specific Capability Structure reg static infomation table */
+/* Vendor Specific Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_vendor[] = {
{
.offset = PCI_CAP_LIST_NEXT,
@@ -866,7 +866,7 @@ static int xen_pt_linkctrl2_reg_init(XenPCIPassthroughState
*s,
return 0;
}
-/* PCI Express Capability Structure reg static infomation table */
+/* PCI Express Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
/* Next Pointer reg */
{
@@ -981,7 +981,7 @@ static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* Power Management Capability reg static infomation table */
+/* Power Management Capability reg static information table */
static XenPTRegInfo xen_pt_emu_reg_pm[] = {
/* Next Pointer reg */
{
@@ -1259,7 +1259,7 @@ static int
xen_pt_msgdata_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* MSI Capability Structure reg static infomation table */
+/* MSI Capability Structure reg static information table */
static XenPTRegInfo xen_pt_emu_reg_msi[] = {
/* Next Pointer reg */
{
@@ -1396,7 +1396,7 @@ static int
xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
return 0;
}
-/* MSI-X Capability Structure reg static infomation table */
+/* MSI-X Capability Structure reg static information table */
static XenPTRegInfo
Re: [Qemu-devel] [PATCH v2 3/4] target-i386: Allow changing of Hypervisor CPUIDs.
On Thu, Sep 13, 2012 at 02:43:55PM -0400, Don Slutz wrote:
On 09/12/12 13:55, Marcelo Tosatti wrote:
The problem with integrating this is that it has little or
no assurance from documentation. The Linux kernel source is a good
source, then say accordingly to VMWare guest support code in version xyz
in the changelog.
I will work on getting a list of the documentation and sources used
to generate this.
Also extracting this information in a text file (or comment in the code)
would be better than just adding code.
I am not sure what information you are talking about here. Are you
asking about the known Hypervisor CPUIDs, or what a lot of Linux
version look at to determine the Hypervisor they are on, or
something else?
Just a summary of where you got the info from.
On Tue, Sep 11, 2012 at 10:07:46AM -0400, Don Slutz wrote:
This is primarily done so that the guest will think it is running
under vmware when hypervisor-vendor=vmware is specified as a
property of a cpu.
Signed-off-by: Don Slutz d...@cloudswitch.com
---
target-i386/cpu.c | 214
+
target-i386/cpu.h | 21 +
target-i386/kvm.c | 33 +++--
3 files changed, 262 insertions(+), 6 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 5f9866a..9f1f390 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -1135,6 +1135,36 @@ static void x86_cpuid_set_model_id(Object *obj,
const char *model_id,
}
}
+static void x86_cpuid_set_vmware_extra(Object *obj)
+{
+X86CPU *cpu = X86_CPU(obj);
+
+if ((cpu-env.tsc_khz != 0)
+(cpu-env.cpuid_hv_level == CPUID_HV_LEVEL_VMARE_4)
+(cpu-env.cpuid_hv_vendor1 == CPUID_HV_VENDOR_VMWARE_1)
+(cpu-env.cpuid_hv_vendor2 == CPUID_HV_VENDOR_VMWARE_2)
+(cpu-env.cpuid_hv_vendor3 == CPUID_HV_VENDOR_VMWARE_3)) {
+const uint32_t apic_khz = 100L;
+
+/*
+ * From article.gmane.org/gmane.comp.emulators.kvm.devel/22643
+ *
+ *Leaf 0x4010, Timing Information.
+ *
+ *VMware has defined the first generic leaf to provide timing
+ *information. This leaf returns the current TSC frequency and
+ *current Bus frequency in kHz.
+ *
+ *# EAX: (Virtual) TSC frequency in kHz.
+ *# EBX: (Virtual) Bus (local apic timer) frequency in kHz.
+ *# ECX, EDX: RESERVED (Per above, reserved fields are set to
zero).
+ */
+cpu-env.cpuid_hv_extra = 0x4010;
+cpu-env.cpuid_hv_extra_a = (uint32_t)cpu-env.tsc_khz;
+cpu-env.cpuid_hv_extra_b = apic_khz;
+}
+}
What happens in case you migrate the vmware guest to a host
with different frequency? How is that transmitted to the
vmware-guest-running-on-kvm ? Or is migration not supported?
As far as I know, it would be the same as for a non-vmware guest.
http://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg01656.html
is related to this.
I did not look to see if this has been done since then.
No it has not, but something similar will be, see:
http://www.spinics.net/lists/kvm/msg79719.html
Yeah alright.
All this change does is to allow the guest to read the
tsc-frequency instead of trying to calculate it.
I will look into the current state of migration when tsc_freq=X is
specified. The machine I have been doing most of the testing on
(Intel Xeon E3-1260L) when I add tsc_freq=2.0G or tsc_freq=2.4G, the
guest does not see any difference in accel=kvm.
Yeah i think you can ignore it.
+static void x86_cpuid_set_hv_level(Object *obj, Visitor *v, void *opaque,
+const char *name, Error **errp)
+{
+X86CPU *cpu = X86_CPU(obj);
+uint32_t value;
+
+visit_type_uint32(v, value, name, errp);
+if (error_is_set(errp)) {
+return;
+}
+
+if ((value != 0) (value 0x4000)) {
+value += 0x4000;
+}
+cpu-env.cpuid_hv_level = value;
+}
+
+static char *x86_cpuid_get_hv_vendor(Object *obj, Error **errp)
+{
+X86CPU *cpu = X86_CPU(obj);
+CPUX86State *env = cpu-env;
+char *value;
+int i;
+
+value = (char *)g_malloc(CPUID_VENDOR_SZ + 1);
+for (i = 0; i 4; i++) {
+value[i + 0] = env-cpuid_hv_vendor1 (8 * i);
+value[i + 4] = env-cpuid_hv_vendor2 (8 * i);
+value[i + 8] = env-cpuid_hv_vendor3 (8 * i);
+}
+value[CPUID_VENDOR_SZ] = '\0';
+
+/* Convert known names */
+if (!strcmp(value, CPUID_HV_VENDOR_VMWARE)) {
+if (env-cpuid_hv_level == CPUID_HV_LEVEL_VMARE_4) {
+pstrcpy(value, sizeof(value), vmware4);
+} else if (env-cpuid_hv_level == CPUID_HV_LEVEL_VMARE_3) {
+pstrcpy(value, sizeof(value), vmware3);
+}
+} else if (!strcmp(value, CPUID_HV_VENDOR_XEN)
+ env-cpuid_hv_level == CPUID_HV_LEVEL_XEN)
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On Fri, Sep 14, 2012 at 12:12:43PM +0200, Jan Kiszka wrote: On 2012-09-14 12:03, Michael Tokarev wrote: On 14.09.2012 14:00, Jan Kiszka wrote: [] The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on the TCG side: We measured noticeable performance benefits when running 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I don't have numbers at hand, but colleagues decided to use the 32-bit version for that reason (when no KVM is available). Interesting. Maybe someone should look at the difference on TCG side and merge interesting bits from i386 to x86_64... :) I suppose the difference - for our use cases at least - lies in the different register and address sizes. Maybe there is room for more runtime optimizations, we never looked in that details as -i386 still works fine. And, if you are on 32-bit host (see below) - but we aren't, qemu-system-x86_64 hurts even more. The thing is: x86_64 becomes the only x86 platform these days, or at least the MAIN platform. I know, and I'm telling everyone. Still, too many crazy people keep on installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will improve this. It is quite depressing that 32-bit still accounts for 55% of deployed Fedora installs: http://smolt.fedoraproject.org/static/stats/stats.html That said, a year ago it was even worse with 32-bit up in 70% region Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH 10/12] kvm: Fix warning from static code analysis
From: Stefan Weil s...@weilnetz.de
Report from smatch:
kvm-all.c:1373 kvm_init(135) warn:
variable dereferenced before check 's' (see line 1360)
's' cannot by NULL (it was alloced using g_malloc0), so there is no need
to check it here.
Signed-off-by: Stefan Weil s...@weilnetz.de
Reviewed-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Stefan Hajnoczi stefa...@gmail.com
---
kvm-all.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 39cff55..e5ed3df 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1409,13 +1409,11 @@ int kvm_init(void)
return 0;
err:
-if (s) {
-if (s-vmfd = 0) {
-close(s-vmfd);
-}
-if (s-fd != -1) {
-close(s-fd);
-}
+if (s-vmfd = 0) {
+close(s-vmfd);
+}
+if (s-fd != -1) {
+close(s-fd);
}
g_free(s);
--
1.7.10.4
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On 2012-09-14 12:20, Daniel P. Berrange wrote: On Fri, Sep 14, 2012 at 12:12:43PM +0200, Jan Kiszka wrote: On 2012-09-14 12:03, Michael Tokarev wrote: On 14.09.2012 14:00, Jan Kiszka wrote: [] The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on the TCG side: We measured noticeable performance benefits when running 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I don't have numbers at hand, but colleagues decided to use the 32-bit version for that reason (when no KVM is available). Interesting. Maybe someone should look at the difference on TCG side and merge interesting bits from i386 to x86_64... :) I suppose the difference - for our use cases at least - lies in the different register and address sizes. Maybe there is room for more runtime optimizations, we never looked in that details as -i386 still works fine. And, if you are on 32-bit host (see below) - but we aren't, qemu-system-x86_64 hurts even more. The thing is: x86_64 becomes the only x86 platform these days, or at least the MAIN platform. I know, and I'm telling everyone. Still, too many crazy people keep on installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will improve this. It is quite depressing that 32-bit still accounts for 55% of deployed Fedora installs: http://smolt.fedoraproject.org/static/stats/stats.html That said, a year ago it was even worse with 32-bit up in 70% region There is a nice comment by Steven that I pinned on my wall, the last paragraph text-marked: http://lkml.indiana.edu/hypermail/linux/kernel/1206.1/00445.html. These days, I prefer to just point people to that printout instead of arguing. Didn't help yet, unfortunately, to convince our corporate VPN vendor to finally support 64-bit with his proprietary clients. Maybe because they didn't visit my office yet. The problem is also that some distros default the download to 32-bit when asking for a desktop, e.g. Ubuntu or OpenSUSE. Kudos to Fedora for not doing this. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On 14 September 2012 11:12, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-09-14 12:03, Michael Tokarev wrote: The thing is: x86_64 becomes the only x86 platform these days, or at least the MAIN platform. I know, and I'm telling everyone. Still, too many crazy people keep on installing 32-bit distros or even 32-bit kernels. Maybe x64-32 will improve this. Personally I'm waiting for my distro to support seamless upgrade from 32 bit to 64 bit. With a little luck multiarch should make this possible in a reasonably clean way... -- PMM
Re: [Qemu-devel] [PATCH 24/25] Add a fallback bios file search, if -L fails.
On 13 September 2012 21:12, Jason Baron jba...@redhat.com wrote:
If -L dir is specified, and qemu does not find the bios file in dir, then
the search fails. Add infrastructure such that the search will continue in
the default paths, if not found in the -L path.
@@ -1872,12 +1873,15 @@ static int balloon_parse(const char *arg)
return -1;
}
-char *qemu_find_file(int type, const char *name)
+static char *__qemu_find_file(int type, const char *name, const char *dir)
{
int len;
const char *subdir;
char *buf;
+if (!dir)
+return NULL;
+
/* Try the name as a straight path first */
if (access(name, R_OK) == 0) {
return g_strdup(name);
This means that every try with a different directory will
check the name as a straight path again, which is a bit
pointless. The just try the name code shouldn't be in
this function (which as Paolo suggests should be named
qemu_find_file_in_dir()), it should be pulled out into
your new qemu_find_file(), which will then look like:
* try as plain pathname
* try in directory 1
* try in directory 2
-- PMM
Re: [Qemu-devel] Selective block migration (still on 0.13)
Am 13.09.2012 16:58, schrieb Christian Theune: Hi, we're currently still on 0.13, looking forward to a large update soon. :) We haven't been using live migration up until now, but are investigating it to multiple downtimes (restarting updated hosts and restarting updated guests) when doing system updates. So, we're trying to find out whether we can get this into a usable shape while still running 0.13. I saw that 0.13 does have block migration available. However, looking at the code, it's an either or situation: migrate all block devices or none. And I advise you to choose none with 0.13. While the 1.2 block migration code doesn't add new options over 0.13 and is deprecated, it's expected to kind of work. However, I'm pretty sure that we fixed some data corruptions issues after 0.13 and so I'd expect that 0.13 eats your data when using block migration. Kevin
Re: [Qemu-devel] [PATCH 11/25] q35: Introduce q35 pc based chipset emulator
On Thu, Sep 13, 2012 at 04:12:42PM -0400, Jason Baron wrote:
From: Isaku Yamahata yamah...@valinux.co.jp
pc q35 based chipset emulator to support pci express natively.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
Signed-off-by: Jason Baron jba...@redhat.com
I think it's best to smash the following patch into this one
otherwise review becomes painful. Some short notes:
---
hw/acpi_ich9.c| 315 ++
hw/acpi_ich9.h| 53 +++
hw/i386/Makefile.objs |1 +
hw/pc_q35.c | 378 +
hw/pci_ids.h | 14 +
hw/q35.c | 877
+
hw/q35.h | 272 +++
hw/q35_smbus.c| 154 +
8 files changed, 2064 insertions(+), 0 deletions(-)
create mode 100644 hw/acpi_ich9.c
create mode 100644 hw/acpi_ich9.h
create mode 100644 hw/pc_q35.c
create mode 100644 hw/q35.c
create mode 100644 hw/q35.h
create mode 100644 hw/q35_smbus.c
diff --git a/hw/acpi_ich9.c b/hw/acpi_ich9.c
new file mode 100644
index 000..59c0807
--- /dev/null
+++ b/hw/acpi_ich9.c
@@ -0,0 +1,315 @@
+/*
+ * ACPI implementation
+ *
+ * Copyright (c) 2006 Fabrice Bellard
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License version 2 as published by the Free Software Foundation.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/
+ */
+/*
+ * Copyright (c) 2009 Isaku Yamahata yamahata at valinux co jp
+ * VA Linux Systems Japan K.K.
+ *
Probably two headers should be combined.
+ * This is based on acpi.c.
This should probably go into commit log instead.
+ */
..
diff --git a/hw/acpi_ich9.h b/hw/acpi_ich9.h
new file mode 100644
index 000..f55c0e9
--- /dev/null
+++ b/hw/acpi_ich9.h
@@ -0,0 +1,53 @@
+/*
+ * QEMU GMCH/ICH9 LPC PM Emulation
+ *
+ * Copyright (c) 2009 Isaku Yamahata yamahata at valinux co jp
+ * VA Linux Systems Japan K.K.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
http://www.gnu.org/licenses/
+ */
+
+#ifndef HW_ACPI_ICH9_H
+#define HW_ACPI_ICH9_H
+
+#include acpi.h
+
+typedef struct ICH9_LPCPmRegs {
This naming scheme conflicts with qemu coding style.
Pls use Ich9LpcPmRegs or something.
Same comment applies everywhere.
--
MST
Re: [Qemu-devel] qemu-system-i386 vs qemu-system-x86_64 ?
On Fri, Sep 14, 2012 at 02:03:58PM +0400, Michael Tokarev wrote: On 14.09.2012 14:00, Jan Kiszka wrote: [] The major difference in qemu-system-i386 vs. qemu-system-x86_64 is on the TCG side: We measured noticeable performance benefits when running 32/16 bit OSes against qemu-system-i386 vs. using qemu-system-x86_64. I don't have numbers at hand, but colleagues decided to use the 32-bit version for that reason (when no KVM is available). Interesting. Maybe someone should look at the difference on TCG side and merge interesting bits from i386 to x86_64... :) Most of the code between i386 and x86_64 is basically the same. For improving TCG performances, the only interesting thing to merge from i386 to x86_64 would be the use 32-bit registers instead of 64-bit registers. Oh wait... -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
On Fri, Sep 14, 2012 at 08:45:11AM +0200, Paolo Bonzini wrote: Il 14/09/2012 00:27, Nicholas A. Bellinger ha scritto: *) Keep vhost-scsi as a backend to virtio-scsi-pci - Reduces duplicated code amongst multiple virtio-scsi backends. - Follows the split for what existing vhost-net code already does. So that said, two quick questions for Paolo Co.. For the standalone vhost-scsi-pci device case, can you give a brief idea as to what extent you'd like to see virtio-scsi.c code/defs duplicated and/or shared amongst a new vhost-scsi-pci device..? Not much, in the end, would be shared; it could end up being just parts of virtio_scsi_init and virtio_scsi_exit, and virtio_scsi_get_config. Almost all the other code is to implement the SCSI bus interface, which you do not need. I don't remember if and how vhost handles configuration changes. All configuration changes are handled in userspace. If you need any struct in virtio-scsi.c, either move it to virtio-scsi.h or add the new device in the same file. Also to help me along, can you give an example based on the current usage below how the QEMU command line arguments would change with a standalone vhost-scsi-pci device..? ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \ -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \ -vhost-scsi id=vhost-scsi0,wwpn=naa.600140579ad21088,tpgt=1 \ -device virtio-scsi-pci,vhost-scsi=vhost-scsi0,event_idx=off Two possibilities. Either simply do s/virtio-scsi-pci/vhost-scsi-pci/ or do ./x86_64-softmmu/qemu-system-x86_64 -enable-kvm -smp 4 -m 2048 \ -hda /usr/src/qemu-vhost.git/debian_squeeze_amd64_standard-old.qcow2 \ -device virtio-scsi-pci,wwpn=naa.600140579ad21088,tpgt=1,event_idx=off I think I like the second option better. -- MST
[Qemu-devel] [PATCH 04/11] block/curl: Fix wrong free statement
From: Stefan Weil s...@weilnetz.de Report from smatch: block/curl.c:546 curl_close(21) info: redundant null check on s-url calling free() The check was redundant, and free was also wrong because the memory was allocated using g_strdup. Signed-off-by: Stefan Weil s...@weilnetz.de Signed-off-by: Kevin Wolf kw...@redhat.com --- block/curl.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/block/curl.c b/block/curl.c index e7c3634..c1074cd 100644 --- a/block/curl.c +++ b/block/curl.c @@ -542,8 +542,7 @@ static void curl_close(BlockDriverState *bs) } if (s-multi) curl_multi_cleanup(s-multi); -if (s-url) -free(s-url); +g_free(s-url); } static int64_t curl_getlength(BlockDriverState *bs) -- 1.7.6.5
[Qemu-devel] [PULL 00/11] Block patches
The following changes since commit e0a1e32dbc41e6b2aabb436a9417dfd32177a3dc: Merge branch 'usb.64' of git://git.kraxel.org/qemu (2012-09-11 18:06:56 +0200) are available in the git repository at: git://repo.or.cz/qemu/kevin.git for-anthony Benoît Canet (2): qapi: Add SnapshotInfo and ImageInfo. qemu-img: Add json output option to the info command. Daniel P. Berrange (1): Don't require encryption password for 'qemu-img info' command Dunrong Huang (1): block: Don't forget to delete temporary file Jason Baron (1): ahci: properly reset PxCMD on HBA reset MORITA Kazutaka (1): sheepdog: fix savevm and loadvm Pavel Hrdina (1): block: fix block tray status Ronnie Sahlberg (1): ATAPI: STARTSTOPUNIT only eject/load media if powercondition is 0 Stefan Weil (3): ide: Fix error messages from static code analysis (no real error) block/curl: Fix wrong free statement vdi: Fix warning from clang Makefile |3 +- block.c | 10 ++- block/curl.c |3 +- block/sheepdog.c |3 +- block/vdi.c | 25 +++--- hw/ide/ahci.c|2 +- hw/ide/atapi.c |6 ++ hw/ide/core.c| 11 +-- qapi-schema.json | 64 ++ qemu-img-cmds.hx |4 +- qemu-img.c | 257 ++--- qemu-img.texi|5 +- 12 files changed, 305 insertions(+), 88 deletions(-)
[Qemu-devel] [PATCH 02/11] ATAPI: STARTSTOPUNIT only eject/load media if powercondition is 0
From: Ronnie Sahlberg ronniesahlb...@gmail.com
The START STOP UNIT command will only eject/load media if
power condition is zero.
If power condition is !0 then LOEJ and START will be ignored.
From MMC (sbc contains similar wordings too)
The Power Conditions field requests the block device to be placed
in the power condition defined in
Table 558. If this field has a value other than 0h then the Start
and LoEj bits shall be ignored.
Signed-off-by: Ronnie Sahlberg ronniesahlb...@gmail.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/ide/atapi.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/ide/atapi.c b/hw/ide/atapi.c
index f7f714c..685cbaa 100644
--- a/hw/ide/atapi.c
+++ b/hw/ide/atapi.c
@@ -875,6 +875,12 @@ static void cmd_start_stop_unit(IDEState *s, uint8_t* buf)
int sense;
bool start = buf[4] 1;
bool loej = buf[4] 2; /* load on start, eject on !start */
+int pwrcnd = buf[4] 0xf0;
+
+if (pwrcnd) {
+/* eject/load only happens for power condition == 0 */
+return;
+}
if (loej) {
if (!start !s-tray_open s-tray_locked) {
--
1.7.6.5
[Qemu-devel] [PATCH 03/11] ide: Fix error messages from static code analysis (no real error)
From: Stefan Weil s...@weilnetz.de
Report from smatch:
hw/ide/core.c:1472 ide_exec_cmd(423) error: buffer overflow 'smart_attributes'
8 = 29
hw/ide/core.c:1474 ide_exec_cmd(425) error: buffer overflow 'smart_attributes'
8 = 29
hw/ide/core.c:1475 ide_exec_cmd(426) error: buffer overflow 'smart_attributes'
8 = 29
...
The upper limit of 30 was never reached because both for loops terminated
when 'smart_attributes' reached end of list, so there was no real buffer
overflow.
Nevertheless, changing the code not only fixes the error report, but also
reduces the size of smart_attributes and simplifies the for loops.
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/ide/core.c | 11 ++-
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index d65ef3d..d6fb69c 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -53,8 +53,6 @@ static const int smart_attributes[][12] = {
{ 0x0c, 0x03, 0x00, 0x64, 0x64, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00},
/* airflow-temperature-celsius */
{ 190, 0x03, 0x00, 0x45, 0x45, 0x1f, 0x00, 0x1f, 0x1f, 0x00, 0x00, 0x32},
-/* end of list */
-{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}
};
static int ide_handle_rw_error(IDEState *s, int error, int op);
@@ -1468,9 +1466,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
case SMART_READ_THRESH:
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
- for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0)
- break;
+ for (n = 0; n ARRAY_SIZE(smart_attributes); n++) {
s-io_buffer[2+0+(n*12)] = smart_attributes[n][0];
s-io_buffer[2+1+(n*12)] = smart_attributes[n][11];
}
@@ -1484,10 +1480,7 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
case SMART_READ_DATA:
memset(s-io_buffer, 0, 0x200);
s-io_buffer[0] = 0x01; /* smart struct version */
- for (n=0; n30; n++) {
- if (smart_attributes[n][0] == 0) {
- break;
- }
+ for (n = 0; n ARRAY_SIZE(smart_attributes); n++) {
int i;
for(i = 0; i 11; i++) {
s-io_buffer[2+i+(n*12)] = smart_attributes[n][i];
--
1.7.6.5
[Qemu-devel] [PATCH 06/11] block: fix block tray status
From: Pavel Hrdina phrd...@redhat.com
The tray status should change also if you eject empty block device.
Signed-off-by: Pavel Hrdina phrd...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block.c b/block.c
index 470bdcc..c754353 100644
--- a/block.c
+++ b/block.c
@@ -897,10 +897,10 @@ void bdrv_close(BlockDriverState *bs)
bdrv_delete(bs-file);
bs-file = NULL;
}
-
-bdrv_dev_change_media_cb(bs, false);
}
+bdrv_dev_change_media_cb(bs, false);
+
/*throttling disk I/O limits*/
if (bs-io_limits_enabled) {
bdrv_io_limits_disable(bs);
--
1.7.6.5
[Qemu-devel] [PATCH 11/11] block: Don't forget to delete temporary file
From: Dunrong Huang riegama...@gmail.com
The caller would not delete temporary file after failed get_tmp_filename().
Signed-off-by: Dunrong Huang riegama...@gmail.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/block.c b/block.c
index c754353..e78039b 100644
--- a/block.c
+++ b/block.c
@@ -433,7 +433,11 @@ int get_tmp_filename(char *filename, int size)
return -EOVERFLOW;
}
fd = mkstemp(filename);
-if (fd 0 || close(fd)) {
+if (fd 0) {
+return -errno;
+}
+if (close(fd) != 0) {
+unlink(filename);
return -errno;
}
return 0;
--
1.7.6.5
Re: [Qemu-devel] [PATCH 4/5] virtio-scsi: Add start/stop functionality for vhost-scsi
On Tue, Sep 11, 2012 at 08:46:34AM -0500, Anthony Liguori wrote: On 09/10/2012 01:24 AM, Michael S. Tsirkin wrote: On Mon, Sep 10, 2012 at 08:16:54AM +0200, Paolo Bonzini wrote: Il 09/09/2012 00:40, Michael S. Tsirkin ha scritto: On Fri, Sep 07, 2012 at 06:00:50PM +0200, Paolo Bonzini wrote: Il 07/09/2012 08:48, Nicholas A. Bellinger ha scritto: Cc: Stefan Hajnoczistefa...@linux.vnet.ibm.com Cc: Zhi Yong Wuwu...@linux.vnet.ibm.com Cc: Michael S. Tsirkinm...@redhat.com Cc: Paolo Bonzinipbonz...@redhat.com Signed-off-by: Nicholas Bellingern...@linux-iscsi.org --- hw/virtio-pci.c |2 ++ hw/virtio-scsi.c | 49 + hw/virtio-scsi.h |1 + 3 files changed, 52 insertions(+), 0 deletions(-) Please create a completely separate device vhost-scsi-pci instead (or virtio-scsi-tcm-pci, or something like that). It is used completely differently from virtio-scsi-pci, it does not make sense to conflate the two. Ideally the name would say how it is different, not what backend it uses. Any good suggestions? I chose the backend name because, ideally, there would be no other difference. QEMU _could_ implement all the goodies in vhost-scsi (such as reservations or ALUA), it just doesn't do that yet. Paolo Then why do you say It is used completely differently from virtio-scsi-pci? Isn't it just a different backend? If yes then it should be a backend option, like it is for virtio-net. I don't mean to bike shed here so don't take this as a nack on making it a backend option, but in retrospect, the way we did vhost-net was a mistake even though I strongly advocated for it to be a backend option. The code to do it is really, really ugly. I think it would have made a lot more sense to just make it a device and then have it not use a netdev backend or any other kind of backend split. For instance: qemu -device vhost-net-pci,tapfd=X We'd have to duplicate all tap options such as upscript then, and educate users that vhost-net-pci is in fact same as virtio-net-pci just faster. They have enough trouble guessing -net-pci in virtio-net-pci. IMHO a simple -device virtio-net-pci,vhost=on would have been the right thing to do in retrospect. since vhost-net absolutely requires a tap fd, I think it's better in the long run to not abuse the netdev backend to prevent user confusion. In practice adding an option (even if it was in the wrong place) did not result in user confusion. Also in practice, renaming virtio to virtio-net-pci etc did create confusion. Having a dedicated backend type that only has one possible option and can only be used by one device is a bit silly too. By now we can just enable it by default. This was always the idea. So I would be in favor of dropping/squashing 3/5 and radically simplifying how this was exposed to the user. Let's just make sure we don't have implementation tail wagging the user interface dog :) I would just take qemu_vhost_scsi_opts and make them device properties. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] configure: fix --target-list=target, target, ... option
On 12 September 2012 14:20, Laurent Desnogues laurent.desnog...@gmail.com wrote: Sorry, I had missed this patch... On Tue, Sep 11, 2012 at 9:02 PM, Eduardo Habkost ehabk...@redhat.com wrote: commit 66d5499b3754b83c09487259c08fe2ce73188a59 broke the support for comma-separated target lists on the --target-list option. e.g.: $ ./configure --target-list=x86_64-linux-user,x86_64-softmmu [...] ERROR: Target 'x86_64-linux-user,x86_64-softmmu' not recognised $ This patch restores that ability. Signed-off-by: Eduardo Habkost ehabk...@redhat.com Cc: Daniel P. Berrange berra...@redhat.com Cc: Anthony Liguori anth...@codemonkey.ws --- configure | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 7656c32..9ee7038 100755 --- a/configure +++ b/configure @@ -1323,7 +1323,9 @@ if ! $python -c 'import sys; sys.exit(sys.version_info (2,4) or sys.version_ fi if test $target_list = DEFAULT ; then -target_list=`echo $default_target_list | sed -e 's/,/ /g'` +target_list=$default_target_list +else +target_list=`echo $target_list | sed -e 's/,/ /g'` fi This works for me too. But I still can't get what the original patch posted by Daniel Berrange intended to do: $ ./configure --target-list= $ make V=1 cat | grep =y | sort -u config-all-devices.mak And it of course hangs there. Hmm. Perhaps we should just revert 66d5499b3 and then recommit a working implementation later? -- PMM
[Qemu-devel] [PATCH 05/11] vdi: Fix warning from clang
From: Stefan Weil s...@weilnetz.de
ccc-analyzer reports these warnings:
block/vdi.c:704:13: warning: Dereference of null pointer
bmap[i] = VDI_UNALLOCATED;
^
block/vdi.c:702:13: warning: Dereference of null pointer
bmap[i] = i;
^
Moving some code into the if block fixes this.
It also avoids calling function write with 0 bytes of data.
Signed-off-by: Stefan Weil s...@weilnetz.de
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vdi.c | 25 -
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/block/vdi.c b/block/vdi.c
index c4f1529..550cf58 100644
--- a/block/vdi.c
+++ b/block/vdi.c
@@ -628,7 +628,6 @@ static int vdi_create(const char *filename,
QEMUOptionParameter *options)
VdiHeader header;
size_t i;
size_t bmap_size;
-uint32_t *bmap;
logout(\n);
@@ -693,21 +692,21 @@ static int vdi_create(const char *filename,
QEMUOptionParameter *options)
result = -errno;
}
-bmap = NULL;
if (bmap_size 0) {
-bmap = (uint32_t *)g_malloc0(bmap_size);
-}
-for (i = 0; i blocks; i++) {
-if (image_type == VDI_TYPE_STATIC) {
-bmap[i] = i;
-} else {
-bmap[i] = VDI_UNALLOCATED;
+uint32_t *bmap = g_malloc0(bmap_size);
+for (i = 0; i blocks; i++) {
+if (image_type == VDI_TYPE_STATIC) {
+bmap[i] = i;
+} else {
+bmap[i] = VDI_UNALLOCATED;
+}
}
+if (write(fd, bmap, bmap_size) 0) {
+result = -errno;
+}
+g_free(bmap);
}
-if (write(fd, bmap, bmap_size) 0) {
-result = -errno;
-}
-g_free(bmap);
+
if (image_type == VDI_TYPE_STATIC) {
if (ftruncate(fd, sizeof(header) + bmap_size + blocks * block_size)) {
result = -errno;
--
1.7.6.5
Re: [Qemu-devel] no won't fix for QEMU bugs in Launchpad?
Paolo Bonzini pbonz...@redhat.com writes: I see the won't fix entry is disabled for QEMU bugs, at least for me. Is it just my permissions, or is it disabled? Anyone who would like greater access to Launchpad, please send me a private email with your LP username. I would be more than grateful to anyone that wants to help update bug status. Regards, Anthony Liguori Paolo
[Qemu-devel] [PATCH 08/11] qapi: Add SnapshotInfo and ImageInfo.
From: Benoît Canet ben...@irqsave.net
Signed-off-by: Benoit Canet ben...@irqsave.net
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qapi-schema.json | 64 ++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index a9f465a..1c168c5 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -156,6 +156,70 @@
'running', 'save-vm', 'shutdown', 'suspended', 'watchdog' ] }
##
+# @SnapshotInfo
+#
+# @id: unique snapshot id
+#
+# @name: user chosen name
+#
+# @vm-state-size: size of the VM state
+#
+# @date-sec: UTC date of the snapshot in seconds
+#
+# @date-nsec: fractional part in nano seconds to be used with date-sec
+#
+# @vm-clock-sec: VM clock relative to boot in seconds
+#
+# @vm-clock-nsec: fractional part in nano seconds to be used with vm-clock-sec
+#
+# Since: 1.3
+#
+##
+
+{ 'type': 'SnapshotInfo',
+ 'data': { 'id': 'str', 'name': 'str', 'vm-state-size': 'int',
+'date-sec': 'int', 'date-nsec': 'int',
+'vm-clock-sec': 'int', 'vm-clock-nsec': 'int' } }
+
+##
+# @ImageInfo:
+#
+# Information about a QEMU image file
+#
+# @filename: name of the image file
+#
+# @format: format of the image file
+#
+# @virtual-size: maximum capacity in bytes of the image
+#
+# @actual-size: #optional actual size on disk in bytes of the image
+#
+# @dirty-flag: #optional true if image is not cleanly closed
+#
+# @cluster-size: #optional size of a cluster in bytes
+#
+# @encrypted: #optional true if the image is encrypted
+#
+# @backing-filename: #optional name of the backing file
+#
+# @full-backing-filename: #optional full path of the backing file
+#
+# @backing-filename-format: #optional the format of the backing file
+#
+# @snapshots: #optional list of VM snapshots
+#
+# Since: 1.3
+#
+##
+
+{ 'type': 'ImageInfo',
+ 'data': {'filename': 'str', 'format': 'str', '*dirty-flag': 'bool',
+ '*actual-size': 'int', 'virtual-size': 'int',
+ '*cluster-size': 'int', '*encrypted': 'bool',
+ '*backing-filename': 'str', '*full-backing-filename': 'str',
+ '*backing-filename-format': 'str', '*snapshots': ['SnapshotInfo'] }
}
+
+##
# @StatusInfo:
#
# Information about VCPU run state
--
1.7.6.5
[Qemu-devel] directory hierarchy
Hi all, here is a proposal for moving around 150 C files currently in the toplevel directory to separate, well-delimited subdirectories. Header files would be moved for now in include/, preparing for subsequent reorganization of headers. Usually the files would keep their names, but I loathe names starting with qemu-* so I took the occasion to rename those. This does not touch the hw/ directory, which is its own mess and worth a separate discussion. Cleaning it up may require introducing more CONFIG_* symbols and moving stuff to libhw whenever possible (for example if we want all NICs in hw/net, all RTCs in hw/rtc, etc. perhaps with some exceptions for USB). Opinions, flames, stop this guys are welcome as usual. Paolo block: aes.c aio.c async.c block.c blockjob.c (with plans to move it in sysemu/block) nbd.c qemu-progress.c block/progress.c block/coroutine: coroutine-gthread.c block/coroutine/gthread.c coroutine-sigaltstack.c block/coroutine/sigaltstack.c coroutine-ucontext.cblock/coroutine/ucontext.c coroutine-win32.c block/coroutine/win32.c qemu-coroutine-io.c block/coroutine/io.c qemu-coroutine-lock.c block/coroutine/lock.c qemu-coroutine-sleep.c block/coroutine/sleep.c qemu-coroutine.cblock/coroutine/coroutine.c block/drivers: block/blkdebug.c block/blkverify.c block/bochs.c block/cloop.c block/cow.c block/curl.c block/dmg.c block/iscsi.c block/mirror.c block/nbd.c block/parallels.c block/qcow.c block/qcow2-cache.c block/qcow2-cluster.c block/qcow2-refcount.c block/qcow2-snapshot.c block/qcow2.c block/qed-check.c block/qed-cluster.c block/qed-gencb.c block/qed-l2-cache.c block/qed-table.c block/qed.c block/raw-posix.c block/raw-win32.c block/raw.c block/rbd.c block/sheepdog.c block/vdi.c block/vmdk.c block/vpc.c block/vvfat.c linux-aio.c posix-aio-compat.c exec: cpu-exec.c disas.c exec.c gdbstub.c tci.c (note: TCI can't go in tcg/ for licensing reasons) translate-all.c hw: hw/dma.chw/i8257.c dma-helpers.c hw/dma.c libdis: alpha-dis.c libdis/alpha.c arm-dis.c libdis/arm.c cris-dis.c libdis/cris.c hppa-dis.c libdis/hppa.c i386-dis.c libdis/i386.c ia64-dis.c libdis/ia64.c lm32-dis.c libdis/lm32.c m68k-dis.c libdis/m68k.c microblaze-dis.clibdis/microblaze.c mips-dis.c libdis/mips.c ppc-dis.c libdis/ppc.c s390-dis.c libdis/s390.c sh4-dis.c libdis/sh4.c sparc-dis.c libdis/sparc.c tci-dis.c libdis/tci.c net: net.c qapi: error.c qga: qemu-ga.c qga/main.c qobject: json-lexer.c json-parser.c json-streamer.c qbool.c qdict.c qerror.c qfloat.c qint.c qjson.c qlist.c qstring.c sysemu: arch_init.c balloon.c cpus.c cputlb.c cursor.c device_tree.c dump-stub.c dump.c ioport.c kvm-all.c kvm-stub.c memory.c memory_mapping-stub.c memory_mapping.c os-posix.c os-win32.c pflib.c qemu-error.csysemu/error.c qemu-seccomp.c sysemu/seccomp.c qtest.c vl.c xen-all.c xen-mapcache.c xen-stub.c qemu-options.hx sysemu/block: block/stream.c blockdev.c sysemu/bt: bt-host.c sysemu/bt/host.c bt-vhci.c sysemu/bt/vhci.c sysemu/char: qemu-char.c sysemu/char/chardev.c qemu-sockets.c sysemu/char/sockets.c spice-qemu-char.c sysemu/char/spice.c sysemu/migration: block-migration.c migration/block.c buffered_file.c migration-exec.c migration-fd.c migration-tcp.c migration-unix.c migration.c page_cache.c savevm.c sysemu/monitor: hmp.c monitor.c qmp.c readline.c hmp-commands.hx qmp-commands.hx tcg: tcg-runtime.c tcg/runtime.c tools: cmd.c qemu-bridge-helper.c qemu-img.c qemu-img-cmds.hx qemu-io.c qemu-nbd.c qemu-tool.c tools/stub.c ui: console.c input.c user: qemu-user.c user/stub.c thunk.c user-exec.c user/cpu-exec.c util: acl.c bitmap.c bitops.c cache-utils.c compatfd.c cutils.c envlist.c event_notifier.c host-utils.c iohandler.c iov.c main-loop.c module.c notify.c osdep.c oslib-posix.c oslib-win32.c path.c qemu-config.c util/config.c qemu-log.c util/log.c qemu-option.c util/option.c qemu-thread-posix.c util/thread-posix.c qemu-thread-win32.c util/thread-win32.c qemu-timer-common.c util/clock.c qemu-timer.cutil/timer.c
[Qemu-devel] [PATCH 07/11] ahci: properly reset PxCMD on HBA reset
From: Jason Baron jba...@redhat.com While testing q35, I found that windows 7 (specifically, windows 7 ultimate with sp1 x64), wouldn't install because it can't find the cdrom or disk drive. The failure message is: 'A required cd/dvd device driver is missing. If you have a driver floppy disk, CD, DVD, or USB flash drive, please insert it now.' This can also be reproduced on piix by adding an ahci controller, and observing that windows 7 does not see any devices behind it. The problem is that when windows issues a HBA reset, qemu does not reset the individual ports' PxCMD register. Windows 7 then reads back the PxCMD register and presumably assumes that the ahci controller has already been initialized. Windows then never sets up the PxIE register to enable interrupts, and thus it never gets irqs back when it sends ata device inquiry commands. This change brings qemu into ahci 1.3 specification compliance. Section 10.4.3 HBA Reset: When GHC.HR is set to '1', GHC.AE, GHC.IE, the IS register, and all port register fields (except PxFB/PxFBU/PxCLB/PxCLBU) that are not HwInit in the HBA's register memory space are reset. I've also re-tested Fedora 16 and 17 to verify that they continue to work with this change. Signed-off-by: Jason Baron jba...@redhat.com Acked-by: Alexander Graf ag...@suse.de Signed-off-by: Kevin Wolf kw...@redhat.com --- hw/ide/ahci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c index 5ea3cad..68671bc 100644 --- a/hw/ide/ahci.c +++ b/hw/ide/ahci.c @@ -1175,7 +1175,6 @@ void ahci_init(AHCIState *s, DeviceState *qdev, DMAContext *dma, int ports) ad-port_no = i; ad-port.dma = ad-dma; ad-port.dma-ops = ahci_dma_ops; -ad-port_regs.cmd = PORT_CMD_SPIN_UP | PORT_CMD_POWER_ON; } } @@ -1199,6 +1198,7 @@ void ahci_reset(AHCIState *s) pr-irq_stat = 0; pr-irq_mask = 0; pr-scr_ctl = 0; +pr-cmd = PORT_CMD_SPIN_UP | PORT_CMD_POWER_ON; ahci_reset_port(s, i); } } -- 1.7.6.5
