[Qemu-devel] Re: [PATCH][uq/master] KVM: x86: Fix eflags corruption in kvm mode
Avi Kivity wrote: On 02/19/2010 07:21 PM, Jan Kiszka wrote: This should explain a lot of the weird breakages of upstream KVM we've seen recently (actually we should have seen it much earlier): Stop translating eflags into TCG format when in kvm mode as we never translate it back and rather sync this broken state into the kernel. Applied to uq/master and uq/stable-0.12, thanks (though realistically 0.12 kvm users should stick with qemu-kvm). Actually, I would prefer if more light kvm users (no demanding performance requirements, no dependency on qemu-kvm-only features) consider upstream instead of qemu-kvm so that it gains way more testing than just by us when pushing some more bits. So we should keep on informing people about limitations and known issues. We need them on both sides. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] Re: [PATCH][uq/master] KVM: x86: Fix eflags corruption in kvm mode
On 02/22/2010 10:13 AM, Jan Kiszka wrote: Avi Kivity wrote: On 02/19/2010 07:21 PM, Jan Kiszka wrote: This should explain a lot of the weird breakages of upstream KVM we've seen recently (actually we should have seen it much earlier): Stop translating eflags into TCG format when in kvm mode as we never translate it back and rather sync this broken state into the kernel. Applied to uq/master and uq/stable-0.12, thanks (though realistically 0.12 kvm users should stick with qemu-kvm). Actually, I would prefer if more light kvm users (no demanding performance requirements, no dependency on qemu-kvm-only features) consider upstream instead of qemu-kvm so that it gains way more testing than just by us when pushing some more bits. So we should keep on informing people about limitations and known issues. We need them on both sides. Agreed. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: qemu-kvm 0.12.2 VNC segfault
On 02/21/2010 07:23 PM, Chris Webb wrote: Some sort of race where a client disconnects and is removed from the client list while the vnc_refresh() loop is iterating over it, maybe? Looks like c727a05459, and high time for 0.12.3. Anthony? -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 0/4] uq/master: iothread consume signals via sigtimedwait and cleanups
On 02/18/2010 12:14 AM, Marcelo Tosatti wrote: See individual patches for details. Applied, thanks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 11/20] eepro100: Use symbolic names for bits in EEPROM id
On Sun, Feb 21, 2010 at 10:38:02PM +0100, Stefan Weil wrote:
Michael S. Tsirkin schrieb:
On Sun, Feb 14, 2010 at 05:16:20PM +0100, Stefan Weil wrote:
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
hw/eepro100.c | 17 -
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index c647322..01bcd6d 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -272,6 +272,21 @@ typedef enum {
eeprom_smbus_addr = 0x90,
} EEPROMOffset;
+/* Bit values for EEPROM ID word. */
+typedef enum {
+ eeprom_id_mdm = BIT(0), /* Modem */
+ eeprom_id_stb = BIT(1), /* Standby Enable */
+ eeprom_id_wmr = BIT(2), /* ??? */
+ eeprom_id_wol = BIT(5), /* Wake on LAN */
+ eeprom_id_dpd = BIT(6), /* Deep Power Down */
+ eeprom_id_alt = BIT(7), /* */
+ /* BITS(10, 8) device revision */
+ eeprom_id_bd = BIT(11), /* boot disable */
+ eeprom_id_id = BIT(13), /* id bit */
+ /* BITS(15, 14) signature */
+ eeprom_id_valid = BIT(14), /* signature for valid eeprom */
+} eeprom_id_bit;
The type name is unused - don't add it?
Maybe it will be used some day?
Adding a type name now makes the code more uniform
and avoids two deltas when it is used.
There are a lot of symbolic names which are unused
today, for example most of above enum values.
This is common practice.
Can constants be upper case?
Of course they can. Is this a QEMU coding convention?
I did not see a hint in CODING_STYLE.
If it is the coding style: UPPER_CASE or CamelCase?
UPPER_CASE
Will it be required for all future modifications
of QEMU code?
+
/* Default values for MDI (PHY) registers */
static const uint16_t eepro100_mdi_default[] = {
/* MDI Registers 0 - 6, 7 */
@@ -643,7 +658,7 @@ static void nic_selective_reset(EEPRO100State * s)
uint16_t *eeprom_contents = eeprom93xx_data(s-eeprom);
//~ eeprom93xx_reset(s-eeprom);
memcpy(eeprom_contents, s-conf.macaddr.a, 6);
- eeprom_contents[eeprom_id] = 0x4000;
+ eeprom_contents[eeprom_id] = eeprom_id_valid;
if (s-device == i82557B || s-device == i82557C)
eeprom_contents[5] = 0x0100;
eeprom_contents[eeprom_phy_id] = 1;
--
1.6.6.1
Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch
On 02/21/2010 09:13 PM, Kevin O'Connor wrote: I'd like to have QEMU handle more, I picked the TSS page because we changed the location of that in the past and it was the one that triggered my patch in the first place. Now we have the infrastructure, it will be easier to add more. What parts of the memory map do you envision qemu managing? Not a lot. SeaBIOS should manage hardware devices memory requirements, as it does with PCI and HPET. That leaves non-hardware memory requirements. The kvm reserved areas fall into this category, but I don't think there are others. -- error compiling committee.c: too many arguments to function
[Qemu-devel] [PATCH] apb_pci: minor cleanup
pci_data_write ignores high 8 bit in address,
so there seems to be no need to set them
in apb_pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Blue Swirl, please consider the following (untested) patch.
Thanks!
hw/apb_pci.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index ebfcd41..f14b432 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -187,8 +187,7 @@ static void apb_pci_config_write(APBState *s,
target_phys_addr_t addr,
uint32_t val, int size)
{
APB_DPRINTF(%s: addr TARGET_FMT_lx val %x\n, __func__, addr, val);
-pci_data_write(s-host_state.bus, (addr 0x00ff) | (1u 31), val,
- size);
+pci_data_write(s-host_state.bus, addr, val, size);
}
static uint32_t apb_pci_config_read(APBState *s, target_phys_addr_t addr,
@@ -196,8 +195,7 @@ static uint32_t apb_pci_config_read(APBState *s,
target_phys_addr_t addr,
{
uint32_t ret;
-ret = pci_data_read(s-host_state.bus, (addr 0x00ff) | (1u 31),
-size);
+ret = pci_data_read(s-host_state.bus, addr, size);
APB_DPRINTF(%s: addr TARGET_FMT_lx - %x\n, __func__, addr, ret);
return ret;
}
--
1.7.0.18.g0d53a5
Re: [Qemu-devel] [PATCH] fix 'i' format handling in memory dump
Gleb Natapov g...@redhat.com writes:
It was broken by 09b9418c6d0. (!env !is_physical) != (!is_physical)
when env is true.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/monitor.c b/monitor.c
index b1a6edc..19470d1 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1297,8 +1297,6 @@ static void memory_dump(Monitor *mon, int count, int
format, int wsize,
int flags;
flags = 0;
env = mon_get_cpu();
-if (!is_physical)
-return;
#ifdef TARGET_I386
if (wsize == 2) {
flags = 1;
*Ouch*
I checked the offending commit for more such errors, but couldn't find
any.
Re: [Qemu-devel] Re: [PATCH 0/3] qcow2: Rewrite alloc_refcount_block
Kevin Wolf kw...@redhat.com writes: Am 20.02.2010 02:49, schrieb Juan Quintela: Anthony Liguori anth...@codemonkey.ws wrote: On 02/15/2010 10:19 AM, Kevin Wolf wrote: The current implementation of alloc_refcount_block and grow_refcount_table has fundamental problems regarding error handling. There are some places where an I/O error means that the image is going to be corrupted. I have found that the only way to fix this is to completely rewrite the thing. Just sending as an RFC to the list hasn't generated a lot of comments (to be precise, not a single one). This is a critical part of qcow2 and needs reviews. So let's try it another way: People in CC, please give it a review. Sooner or later some of you will need to do so anyway. Should I apply this series? I still don't see any review comments. I sent review comments on the 18th. I expect Kevin to address them. I talked with him on irc while doing the review (i.e. he knows about them). I was hoping for more comments as there were three more people in the CC list. But looks like they prefer reviewing the patches downstream. I'm going to send a v2 which addresses only your comments if I don't get any more comments soon. I don't prefer reviewing downstream at all, I just haven't been able to find the time for a review. Sorry.
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
On Sat, Feb 20, 2010, malc wrote: No, i'm against using locking GCC builtins for all the other targets (well PPC) Do you have benchmarks with/without GCC atomic builtins? -- Loïc Minier
[Qemu-devel] [PATCH] apc_pci: simplify using rwhandler
Use rwhandler to simplify apb_pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Blue Swirl, please consider the following
(compile-tested only) patch.
hw/apb_pci.c | 74 ++---
1 files changed, 13 insertions(+), 61 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index f14b432..324e74e 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -29,6 +29,7 @@
#include sysbus.h
#include pci.h
#include pci_host.h
+#include rwhandler.h
#include apb_pci.h
/* debug APB */
@@ -65,6 +66,7 @@ do { printf(APB: fmt , ## __VA_ARGS__); } while (0)
typedef struct APBState {
SysBusDevice busdev;
PCIHostState host_state;
+ReadWriteHandler pci_config_handler;
uint32_t iommu[4];
uint32_t pci_control[16];
uint32_t pci_irq_map[8];
@@ -183,80 +185,28 @@ static CPUReadMemoryFunc * const apb_config_read[] = {
apb_config_readl,
};
-static void apb_pci_config_write(APBState *s, target_phys_addr_t addr,
+static void apb_pci_config_write(ReadWriteHandler *h, pcibus_t addr,
uint32_t val, int size)
{
+APBState *s = container_of(h, APBState, pci_config_handler);
+
+val = qemu_bswap_len(val, size);
APB_DPRINTF(%s: addr TARGET_FMT_lx val %x\n, __func__, addr, val);
pci_data_write(s-host_state.bus, addr, val, size);
}
-static uint32_t apb_pci_config_read(APBState *s, target_phys_addr_t addr,
+static uint32_t apb_pci_config_read(ReadWriteHandler *h, pcibus_t addr,
int size)
{
uint32_t ret;
+APBState *s = container_of(h, APBState, pci_config_handler);
ret = pci_data_read(s-host_state.bus, addr, size);
+ret = qemu_bswap_len(ret, size);
APB_DPRINTF(%s: addr TARGET_FMT_lx - %x\n, __func__, addr, ret);
return ret;
}
-static void apb_pci_config_writel(void *opaque, target_phys_addr_t addr,
- uint32_t val)
-{
-APBState *s = opaque;
-
-apb_pci_config_write(s, addr, bswap32(val), 4);
-}
-
-static void apb_pci_config_writew(void *opaque, target_phys_addr_t addr,
- uint32_t val)
-{
-APBState *s = opaque;
-
-apb_pci_config_write(s, addr, bswap16(val), 2);
-}
-
-static void apb_pci_config_writeb(void *opaque, target_phys_addr_t addr,
- uint32_t val)
-{
-APBState *s = opaque;
-
-apb_pci_config_write(s, addr, val, 1);
-}
-
-static uint32_t apb_pci_config_readl(void *opaque, target_phys_addr_t addr)
-{
-APBState *s = opaque;
-
-return bswap32(apb_pci_config_read(s, addr, 4));
-}
-
-static uint32_t apb_pci_config_readw(void *opaque, target_phys_addr_t addr)
-{
-APBState *s = opaque;
-
-return bswap16(apb_pci_config_read(s, addr, 2));
-}
-
-static uint32_t apb_pci_config_readb(void *opaque, target_phys_addr_t addr)
-{
-APBState *s = opaque;
-
-return apb_pci_config_read(s, addr, 1);
-}
-
-static CPUWriteMemoryFunc * const apb_pci_config_writes[] = {
-apb_pci_config_writeb,
-apb_pci_config_writew,
-apb_pci_config_writel,
-};
-
-static CPUReadMemoryFunc * const apb_pci_config_reads[] = {
-apb_pci_config_readb,
-apb_pci_config_readw,
-apb_pci_config_readl,
-};
-
static void pci_apb_iowriteb (void *opaque, target_phys_addr_t addr,
uint32_t val)
{
@@ -453,8 +403,10 @@ static int pci_pbm_init_device(SysBusDevice *dev)
pci_apb_iowrite, s);
sysbus_init_mmio(dev, 0x1ULL, pci_ioport);
/* pci_config */
-pci_config = cpu_register_io_memory(apb_pci_config_reads,
-apb_pci_config_writes, s);
+s-pci_config_handler.read = apb_pci_config_read;
+s-pci_config_handler.write = apb_pci_config_write;
+pci_config = cpu_register_io_memory_simple(s-pci_config_handler);
+assert(pci_config = 0);
sysbus_init_mmio(dev, 0x100ULL, pci_config);
/* mem_data */
pci_mem_data = pci_host_data_register_mmio(s-host_state);
--
1.7.0.18.g0d53a5
Re: [Qemu-devel] [PATCH 1/2] Detect and use GCC atomic builtins for locking
On Mon, 22 Feb 2010, Lo?c Minier wrote: On Sat, Feb 20, 2010, malc wrote: No, i'm against using locking GCC builtins for all the other targets (well PPC) Do you have benchmarks with/without GCC atomic builtins? No. -- mailto:av1...@comtv.ru
[Qemu-devel] QEMU in TLM-2.0 environment
Hi, I would like to be able to do small contributions in QEMU in order to connect it to our TLM-2.0 ESL modelling platform. I am working for a commercial company; we use LGPL cut of QEMU. I planning to enhance hot plugin mode allowing to bind peripherals more easily, distinguish debug calls from regular ones and add some instrumentation for various levels of timing/power modelling. We already have some implementation of our platform based on version 0.10, and I would like to integrate the changes. I am sure that my contributions will be on benefit of the community as well. Could you, please approve my membership on QEMU/savannah.nongnu ? I've already signed FSF papers before. I am a member of BISON group. -- Best regards, Alex Rozenman (rozen...@gmail.com).
Re: [Qemu-devel] QEMU in TLM-2.0 environment
On 22.02.2010, at 12:09, Alex Rozenman wrote: Hi, I would like to be able to do small contributions in QEMU in order to connect it to our TLM-2.0 ESL modelling platform. I am working for a commercial company; we use LGPL cut of QEMU. I planning to enhance hot plugin mode allowing to bind peripherals more easily, distinguish debug calls from regular ones and add some instrumentation for various levels of timing/power modelling. We already have some implementation of our platform based on version 0.10, and I would like to integrate the changes. I am sure that my contributions will be on benefit of the community as well. Could you, please approve my membership on QEMU/savannah.nongnu ? I've already signed FSF papers before. I am a member of BISON group. The normal patch process is similar to that of the Linux kernel. You send an inlined patch to the qemu-devel mailing list with a Signed-off-by: statement and wait for someone to comment, reject or commit it. Alex
Re: [Qemu-devel] [PATCH] QMP: Spec: Private Extensions support
Anthony Liguori anth...@codemonkey.ws writes: On 02/19/2010 07:04 AM, Markus Armbruster wrote: Anthony Liguorianth...@codemonkey.ws writes: We need a bit more than just this. Here's my suggestion: I think this is much more restrictive than necessary. Unnecessarily restrictive rules are more likely to be ignored, and we don't want that. Details below. I disagree. The point of QMP is to allow third party tools to manage qemu in a robust way. Compatibility is a key part of this. Downstream QMP extension is a bad thing. It means management tools have to have a lot of special logic to deal with different downstreams. I believe we need to strongly discourage downstreams from making protocol changes while leaving them enough wiggle room to make the changes when they have no other choice. Wearing my upstream hat: Yes, downstream extensions are undesirable. Yes, it makes sense to discourage them. And yes, downstreams will be occasionally compelled to add extensions anyway. The only truly normative bit in the whole text is our promise to reserve the __ prefix for vendors. The rest is merely advice. We have no power whatsoever to make downstream take it. Upstream has to lead by argument and example. Putting advice forward in the form of arbitrary rules is a good way to ensure it's ignored. Advice needs a rationale. The stronger the recommendation, the more convincing its rationale needs to be. We already established rules for protocol evolution: we won't change existing commands, arguments, and so forth; we won't add new mandatory arguments; we may add optional arguments, new errors, ... If these rules are good enough for us, why aren't they good enough for downstream? I don't think we can expect downstream to follow rules we don't intend to follow ourselves. What follows is merely elaborating on these maxims. 6. Downstream modification of QMP --- We strongly recommend that downstream consumers of QEMU do _not_ modify the behaviour of any QMP command or introduce new QMP commands. This is important to allow management tools to support both upstream and downstream versions of QMP without special logic. However, we recognize that it is sometimes impossible for downstreams to avoid modifying QMP. If this happens, the following rules should be observed Bad line break. to attempt to preserve long term compatibility and interoperability. Better move your items 5-6) here, and make them talk about names, not just commands. Items 1-4) make much more sense with the name space issue settled. Good suggestion. 1) Only introduce new commands. If you want to change an existing command, leave the old command in place and introduce a new one with the new behaviour. Extending an existing command in a compatible way should be fine. An extension is compatible if 1. it adds only optional arguments, and 2. it behaves differently only when new optional arguments are supplied. From an implementation perspective, it's very easy to modify an existing command, call it a new name, then add a new command with the old name that passes only the compatible parameters. So I have a hard time believing this is really a burden for downstreams. Think about it from an end-to-end perspective. If I'm writing a client library, and I expose a function qmp_commit(session, disk, force=false), and the QMP protocol introduces a vendor extension to qmp_commit(), I now need to change the qmp_commit() interface in my library to support that new parameter. Except since this is a vendor parameter, now every caller has to have knowledge about dealing with different vendors. On the other handle, a qmp_rhel_commit() command happily lives in a separate namespace. In fact, in a well written client library, it could easily be a plugin. The normal library consumer never has to think about vendor functions unless they explicitly need a function that only lives in a vendor namespace. With a bit more precision: consider monitor command commit, available in QMP (not yet true, but that doesn't matter). Say we have a client library that provides function qmp_commit(), which is merely a straightforward marshalling wrapper around the QMP command. Observations: 1. The client library and its users continues to work unchanged even when the server (QEMU) adds vendor-specific optional arguments. 2. The client library may elect to expose vendor-specific arguments in qmp_commit() to its users. 3. The client library may elect to provide a vendor-specific wrapper qmp_vendor_commit() around QMP command commit that exposes vendor-specific arguments. In fact, that could easily be a plugin. 4. Regardless of whether the client library does 2., 3. or neither, its unmodified users continue to work unchanged. I don't think we have convincing rationale for a rule here. 2)
[Qemu-devel] Address translation - virt-phys-ram
Hi folks,
I've been updating some old patches which make use of a function to
translate guest virtual addresses into pointers into the guest RAM.
As I understand it qemu has guest virtual and physical addresses, the
latter of which map somehow to host ram addresses.
The function which the code had been using appears not to work under
kvm, which leads me to think that qemu doesnt emulate the MMU (or at
least not in the same manner) when it is using kvm as opposed to pure
emulation.
If I turn off kvm, the patch works, albeit slowly. If I enable it, the
code takes the path which looks for the magic value (below).
Is there a 'proper' way to translate guest virtual addresses into host
RAM addresses?
Here is the code:-
static /*inline*/ void *get_phys_mem_addr(CPUState *env, target_ulong addr)
{
int mmu_idx;
int index;
int i;
index = (addr TARGET_PAGE_BITS) (CPU_TLB_SIZE - 1);
mmu_idx = cpu_mmu_index(env);
if (__builtin_expect
(env-tlb_table[mmu_idx][index].addr_code !=
(addr TARGET_PAGE_MASK), 0)) {
target_ulong ret = cpu_get_phys_page_debug((CPUState *) env, addr);
if (ret == -1) {
fprintf(stderr,
not in phys mem TARGET_FMT_lx ( TARGET_FMT_lx
TARGET_FMT_lx )\n, addr,
env-tlb_table[mmu_idx][index].addr_code,
addr TARGET_PAGE_MASK);
fprintf(stderr, cpu_x86_handle_mmu_fault = %d\n,
cpu_x86_handle_mmu_fault((CPUState *) env, addr, 0,
mmu_idx, 1));
return NULL;
} else {
if (ret + TARGET_PAGE_SIZE = ram_size) {
return qemu_get_ram_ptr((ret + (((target_ulong) addr)
(TARGET_PAGE_SIZE - 1;
} else {
fprintf(stderr,
cpu_get_phys_page_debug(env, TARGET_FMT_lx )
==
TARGET_FMT_lx \n, addr, ret);
fprintf(stderr,
ram_size= TARGET_FMT_lx \n, ret,
(target_ulong) ram_size);
for(i = 0 ; i ram_size-10 ; i++) {
char *ptr = qemu_get_ram_ptr(i);
if(!strncmp(magic_string, ptr, 10)) {
fprintf(stderr, found magic_string at: %lx
%lx\n, i, ptr);
break;
}
}
return qemu_get_ram_ptr(i-128); //Evil horrible hack
}
}
} else
return (void *) addr + env-tlb_table[mmu_idx][index].addend;
}
[Qemu-devel] [patch uq/master 0/2] wake iothread on virtio kick / flush_coalesced_mmio smp_wmb
See individual patches for details.
[Qemu-devel] [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers, so wakeup the iothread to process that information immediately. Reported-by: Amit Shah amit.s...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Index: qemu/hw/virtio-pci.c === --- qemu.orig/hw/virtio-pci.c +++ qemu/hw/virtio-pci.c @@ -204,6 +204,7 @@ static void virtio_ioport_write(void *op break; case VIRTIO_PCI_QUEUE_NOTIFY: virtio_queue_notify(vdev, val); +qemu_notify_event(); break; case VIRTIO_PCI_STATUS: vdev-status = val 0xFF;
[Qemu-devel] [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port,
return 1;
}
+/* FIXME: arch dependant, x86 version */
+#define smp_wmb() asm volatile( ::: memory)
+
void kvm_flush_coalesced_mmio_buffer(void)
{
#ifdef KVM_CAP_COALESCED_MMIO
@@ -730,7 +733,7 @@ void kvm_flush_coalesced_mmio_buffer(voi
ent = ring-coalesced_mmio[ring-first];
cpu_physical_memory_write(ent-phys_addr, ent-data, ent-len);
-/* FIXME smp_wmb() */
+smp_wmb();
ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX;
}
}
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers, so wakeup the iothread to process that information immediately. Reported-by: Amit Shahamit.s...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/hw/virtio-pci.c === --- qemu.orig/hw/virtio-pci.c +++ qemu/hw/virtio-pci.c @@ -204,6 +204,7 @@ static void virtio_ioport_write(void *op break; case VIRTIO_PCI_QUEUE_NOTIFY: virtio_queue_notify(vdev, val); +qemu_notify_event(); break; virtio_queue_notify() will call -handle_output(), which should either do what's needed to be done, or wake up some iothread itself. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: Cc: Michael S. Tsirkinm...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/kvm-all.c === --- qemu.orig/kvm-all.c +++ qemu/kvm-all.c @@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port, return 1; } +/* FIXME: arch dependant, x86 version */ +#define smp_wmb() asm volatile( ::: memory) + sfence? what about other arches? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
Blue Swirl wrote: Thanks, applied. This patch breaks building on ppc32. Reverting it makes it compile again: In file included from /suse/agraf/git/qemu/tcg/tcg.c:158: /suse/agraf/git/qemu/tcg/ppc/tcg-target.c:1696: error: ‘INDEX_op_qemu_ld32s’ undeclared here (not in a function) Alex On 2/20/10, Jay Foad jay.f...@gmail.com wrote: On 32-bit hosts op_qemu_ld32s is unused. Remove it to fix the following assertion failure: qemu-alpha: tcg/tcg.c:1055: tcg_add_target_add_op_defs: Assertion `tcg_op_defs[op].used' failed. Signed-off-by: Jay Foad jay.f...@gmail.com --- tcg/tcg-opc.h |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/tcg/tcg-opc.h b/tcg/tcg-opc.h index 89db3b4..838f1f4 100644 --- a/tcg/tcg-opc.h +++ b/tcg/tcg-opc.h @@ -224,11 +224,6 @@ DEF2(qemu_ld32u, 1, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) DEF2(qemu_ld32u, 1, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) #endif #if TARGET_LONG_BITS == 32 -DEF2(qemu_ld32s, 1, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) -#else -DEF2(qemu_ld32s, 1, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) -#endif -#if TARGET_LONG_BITS == 32 DEF2(qemu_ld64, 2, 1, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS) #else DEF2(qemu_ld64, 2, 2, 1, TCG_OPF_CALL_CLOBBER | TCG_OPF_SIDE_EFFECTS)
Re: [Qemu-devel] Address translation - virt-phys-ram
On 02/22/2010 07:59 AM, Ian Molton wrote: Hi folks, I've been updating some old patches which make use of a function to translate guest virtual addresses into pointers into the guest RAM. As I understand it qemu has guest virtual and physical addresses, the latter of which map somehow to host ram addresses. The function which the code had been using appears not to work under kvm, which leads me to think that qemu doesnt emulate the MMU (or at least not in the same manner) when it is using kvm as opposed to pure emulation. If I turn off kvm, the patch works, albeit slowly. If I enable it, the code takes the path which looks for the magic value (below). Is there a 'proper' way to translate guest virtual addresses into host RAM addresses? cpu_physical_memory_map(). But this function has some subtle characteristics. It may return a bounce buffer if you attempt to map MMIO memory. There is a limited pool of bounce buffers available so it may return NULL in the event that it cannot allocate a bounce buffer. It may also return a partial result if you're attempting to map a region that straddles multiple memory slots. Regards, Anthony Liguori
Re: [Qemu-devel] [BUG] Regression: readonly raw images no longer work
Stefan Weil wrote: This command used to work, but fails now: $ i386-softmmu/qemu -snapshot /dev/sda qemu: could not open disk image /dev/sda: Permission denied $ ls -l /dev/sda brw-rw-r-- 1 root disk 8, 0 13. Feb 08:55 /dev/sda The original file of a snapshot needs only read access, but QEMU tries read/write access and fails. Variants of above command using -hda or -drive also fail with the same error message. I did not test whether the regression affects other kinds of images, too. Maybe only raw images trigger no longer work. Regards Stefan Weil Sorry for the late reply, this is my fault. It will fail for any image format. It's already fixed with commit 4dca4b639cb20fee38f6eec0a391aecc0ad8848d : block: more read-only changes, related to backing files Now, since the /dev/sda is the backing-file, it's opened as read-only, no permission problem. Notice that if you try to commit your changes to the read-only disk (in monitor command), it will be silently ignored, no error or warning displayed. Should I add a warning/error printing ? Naphtali
Re: [Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
This patch breaks building on ppc32. Reverting it makes it compile again: /suse/agraf/git/qemu/tcg/ppc/tcg-target.c:1696: error: ‘INDEX_op_qemu_ld32s’ undeclared here (not in a function) Does it build if you remove line 1696? If so, I'd suggest doing that. Thanks, Jay.
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On Mon, Feb 22, 2010 at 04:23:32PM +0200, Avi Kivity wrote: On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: Cc: Michael S. Tsirkinm...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/kvm-all.c === --- qemu.orig/kvm-all.c +++ qemu/kvm-all.c @@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port, return 1; } +/* FIXME: arch dependant, x86 version */ +#define smp_wmb() asm volatile( ::: memory) + sfence? There is no need (for this case). Older read cannot be reordered with write, writes are not reordered with other writes, writes by a single processor are observed in the same order by all processors. what about other arches? They need to be fixed? PPC needs an instruction apparently. Is there any objection to including this patch?
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote: On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers, so wakeup the iothread to process that information immediately. Reported-by: Amit Shahamit.s...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/hw/virtio-pci.c === --- qemu.orig/hw/virtio-pci.c +++ qemu/hw/virtio-pci.c @@ -204,6 +204,7 @@ static void virtio_ioport_write(void *op break; case VIRTIO_PCI_QUEUE_NOTIFY: virtio_queue_notify(vdev, val); +qemu_notify_event(); break; virtio_queue_notify() will call -handle_output(), which should either do what's needed to be done, or wake up some iothread itself. kick is used to inform either output processing, in which case -handle_output() does what its supposed to. But its also used to inform availability of new buffers, which is common to all virtio devices. So what is the point pushing this to -handle_output? Are you concerned about spurious wakeups?
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On Mon, Feb 22, 2010 at 10:59:08AM -0300, Marcelo Tosatti wrote:
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Acked-by: Michael S. Tsirkin m...@redhat.com
We'll need implementation for other arches, I'll dust off
my patch that adds it and repost, but for now this
is better than what we have.
Index: qemu/kvm-all.c
===
--- qemu.orig/kvm-all.c
+++ qemu/kvm-all.c
@@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port,
return 1;
}
+/* FIXME: arch dependant, x86 version */
+#define smp_wmb() asm volatile( ::: memory)
+
void kvm_flush_coalesced_mmio_buffer(void)
{
#ifdef KVM_CAP_COALESCED_MMIO
@@ -730,7 +733,7 @@ void kvm_flush_coalesced_mmio_buffer(voi
ent = ring-coalesced_mmio[ring-first];
cpu_physical_memory_write(ent-phys_addr, ent-data, ent-len);
-/* FIXME smp_wmb() */
+smp_wmb();
ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX;
}
}
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On 02/22/2010 04:29 PM, Marcelo Tosatti wrote: On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote: On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers, so wakeup the iothread to process that information immediately. Reported-by: Amit Shahamit.s...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/hw/virtio-pci.c === --- qemu.orig/hw/virtio-pci.c +++ qemu/hw/virtio-pci.c @@ -204,6 +204,7 @@ static void virtio_ioport_write(void *op break; case VIRTIO_PCI_QUEUE_NOTIFY: virtio_queue_notify(vdev, val); +qemu_notify_event(); break; virtio_queue_notify() will call -handle_output(), which should either do what's needed to be done, or wake up some iothread itself. kick is used to inform either output processing, in which case -handle_output() does what its supposed to. But its also used to inform availability of new buffers, which is common to all virtio devices. So what is the point pushing this to -handle_output? I don't understand what this means. -handle_output() _is_ informing the device model of new buffers. What more is needed? Are you concerned about spurious wakeups? Yes. Also, qemu_notify_event() is an undirected notification (wakes up all iothreads, and all devices), whereas -handle_output() is directed (wakes up exactly what is needed). What's the underlying problem? A new input buffer has become available, and we need to re-poll the incoming file descriptor? If so, that's best done from -handle_output() (either by waking the iothread or calling read() itself and perhaps receiving -EAGAIN). -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On 02/22/2010 04:45 PM, Marcelo Tosatti wrote: On Mon, Feb 22, 2010 at 04:23:32PM +0200, Avi Kivity wrote: On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: Cc: Michael S. Tsirkinm...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/kvm-all.c === --- qemu.orig/kvm-all.c +++ qemu/kvm-all.c @@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port, return 1; } +/* FIXME: arch dependant, x86 version */ +#define smp_wmb() asm volatile( ::: memory) + sfence? There is no need (for this case). Older read cannot be reordered with write, writes are not reordered with other writes, writes by a single processor are observed in the same order by all processors. Well, Linux does use sfence. Perhaps it's only needed for WC writes (movnti and friends), but better be careful here. what about other arches? They need to be fixed? PPC needs an instruction apparently. Is there any objection to including this patch? I imagine all arches need an instruction. For reads as well. Note, gcc has a __sync_synchronize() builtin that compiles to mfence on x86. We might use that as a baseline for both rmb and wmb, and let each arch override it incrementally. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On Mon, Feb 22, 2010 at 04:57:29PM +0200, Avi Kivity wrote: On 02/22/2010 04:45 PM, Marcelo Tosatti wrote: On Mon, Feb 22, 2010 at 04:23:32PM +0200, Avi Kivity wrote: On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: Cc: Michael S. Tsirkinm...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/kvm-all.c === --- qemu.orig/kvm-all.c +++ qemu/kvm-all.c @@ -718,6 +718,9 @@ static int kvm_handle_io(uint16_t port, return 1; } +/* FIXME: arch dependant, x86 version */ +#define smp_wmb() asm volatile( ::: memory) + sfence? There is no need (for this case). Older read cannot be reordered with write, writes are not reordered with other writes, writes by a single processor are observed in the same order by all processors. Well, Linux does use sfence. At least on 64 bit it doesnt. Perhaps it's only needed for WC writes (movnti and friends), but better be careful here. what about other arches? They need to be fixed? PPC needs an instruction apparently. Is there any objection to including this patch? I imagine all arches need an instruction. For reads as well. Note, gcc has a __sync_synchronize() builtin that compiles to mfence on x86. We might use that as a baseline for both rmb and wmb, and let each arch override it incrementally. This it what my patch did. Note it only works well for recent gcc. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On 02/22/2010 04:57 PM, Michael S. Tsirkin wrote: There is no need (for this case). Older read cannot be reordered with write, writes are not reordered with other writes, writes by a single processor are observed in the same order by all processors. Well, Linux does use sfence. At least on 64 bit it doesnt. Right, I was looking at wmb(), not smp_wmb(). I imagine all arches need an instruction. For reads as well. Note, gcc has a __sync_synchronize() builtin that compiles to mfence on x86. We might use that as a baseline for both rmb and wmb, and let each arch override it incrementally. This it what my patch did. Note it only works well for recent gcc. Do you know how recent? -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On Mon, Feb 22, 2010 at 05:08:00PM +0200, Avi Kivity wrote: On 02/22/2010 04:57 PM, Michael S. Tsirkin wrote: There is no need (for this case). Older read cannot be reordered with write, writes are not reordered with other writes, writes by a single processor are observed in the same order by all processors. Well, Linux does use sfence. At least on 64 bit it doesnt. Right, I was looking at wmb(), not smp_wmb(). I imagine all arches need an instruction. For reads as well. Note, gcc has a __sync_synchronize() builtin that compiles to mfence on x86. We might use that as a baseline for both rmb and wmb, and let each arch override it incrementally. This it what my patch did. Note it only works well for recent gcc. Do you know how recent? IIRC 4.3 has broken implementation. 4.4 seems OK as far as I can tell. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On Mon, Feb 22, 2010 at 04:51:46PM +0200, Avi Kivity wrote: On 02/22/2010 04:29 PM, Marcelo Tosatti wrote: On Mon, Feb 22, 2010 at 04:20:52PM +0200, Avi Kivity wrote: On 02/22/2010 03:59 PM, Marcelo Tosatti wrote: VIRTIO_PCI_QUEUE_NOTIFY is used to inform availability of new buffers, so wakeup the iothread to process that information immediately. Reported-by: Amit Shahamit.s...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Index: qemu/hw/virtio-pci.c === --- qemu.orig/hw/virtio-pci.c +++ qemu/hw/virtio-pci.c @@ -204,6 +204,7 @@ static void virtio_ioport_write(void *op break; case VIRTIO_PCI_QUEUE_NOTIFY: virtio_queue_notify(vdev, val); +qemu_notify_event(); break; virtio_queue_notify() will call -handle_output(), which should either do what's needed to be done, or wake up some iothread itself. kick is used to inform either output processing, in which case -handle_output() does what its supposed to. But its also used to inform availability of new buffers, which is common to all virtio devices. So what is the point pushing this to -handle_output? I don't understand what this means. -handle_output() _is_ informing the device model of new buffers. What more is needed? Are you concerned about spurious wakeups? Yes. Also, qemu_notify_event() is an undirected notification (wakes up all iothreads, and all devices), whereas -handle_output() is directed (wakes up exactly what is needed). What's the underlying problem? A new input buffer has become available, and we need to re-poll the incoming file descriptor? If so, that's best done from -handle_output() (either by waking the iothread or calling read() itself and perhaps receiving -EAGAIN). Yes. Sure, perhaps calling read() itself is appropriate, and i see your point that handle_output contains more context for a smarter decision. But one can argue thats an improvement on top of a dumb wakeup.
Re: [Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
Jay Foad schrieb: This patch breaks building on ppc32. Reverting it makes it compile again: /suse/agraf/git/qemu/tcg/ppc/tcg-target.c:1696: error: ‘INDEX_op_qemu_ld32s’ undeclared here (not in a function) Does it build if you remove line 1696? If so, I'd suggest doing that. Thanks, Jay. Removing the line helps only in that special case. #if TCG_TARGET_REG_BITS == 64 ... #endif is better. I can provide a patch. Regards, Stefan
Re: [Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
Jay Foad wrote: This patch breaks building on ppc32. Reverting it makes it compile again: /suse/agraf/git/qemu/tcg/ppc/tcg-target.c:1696: error: ‘INDEX_op_qemu_ld32s’ undeclared here (not in a function) Does it build if you remove line 1696? If so, I'd suggest doing that. Yes, that fixes it. Please grep through all tcg targets and send a patch removing all references to ld32s if you think it's not necessary. Alex
[Qemu-devel] Re: Commit 085219f79cad broke Sparc-32 back in 2.6.28.
On Monday 22 February 2010 12:57:19 am David Miller wrote: From: Rob Landley r...@landley.net Date: Sun, 21 Feb 2010 10:25:09 -0600 085219f79cad89291699bd2bfb21c9fdabafe65f is first bad commit commit 085219f79cad89291699bd2bfb21c9fdabafe65f Author: Sam Ravnborg s...@ravnborg.org Date: Fri Jan 2 18:47:34 2009 -0800 sparc32: use proper types in struct stat Like sparc64 use proper types in struct stat Signed-off-by: Sam Ravnborg s...@ravnborg.org Signed-off-by: David S. Miller da...@davemloft.net This commit breaks stat and makes sparc32 essentially unusable. It changes the size of the various types in stat.h, and means that if you mount -t tmpfs /tmp /tmp and then try to ls /tmp, ls dies with a memory allocation error. I've confirmed that reverting it fixes the problem. Thanks for tracking this down Rob, I'll work on a fix and push it around. Looking at how whole sparc32 has been apparently broken for over a year now because of a purely cleanup patch I wonder if it would be appropriate to make sparc32 into 'legacy only' and provide 'a stability promise' for it? Just an idea.. ;) -- Bartlomiej Zolnierkiewicz
[Qemu-devel] Re: Commit 085219f79cad broke Sparc-32 back in 2.6.28.
From: Rob Landley r...@landley.net Date: Sun, 21 Feb 2010 10:25:09 -0600 085219f79cad89291699bd2bfb21c9fdabafe65f is first bad commit commit 085219f79cad89291699bd2bfb21c9fdabafe65f Author: Sam Ravnborg s...@ravnborg.org Date: Fri Jan 2 18:47:34 2009 -0800 sparc32: use proper types in struct stat Like sparc64 use proper types in struct stat Signed-off-by: Sam Ravnborg s...@ravnborg.org Signed-off-by: David S. Miller da...@davemloft.net This commit breaks stat and makes sparc32 essentially unusable. It changes the size of the various types in stat.h, and means that if you mount -t tmpfs /tmp /tmp and then try to ls /tmp, ls dies with a memory allocation error. I've confirmed that reverting it fixes the problem. Thanks for tracking this down Rob, I'll work on a fix and push it around.
[Qemu-devel] Re: Commit 085219f79cad broke Sparc-32 back in 2.6.28.
Here's the fix I'll use, thanks for the report Rob:
sparc32: Fix struct stat uid/gid types.
Commit 085219f79cad89291699bd2bfb21c9fdabafe65f
(sparc32: use proper types in struct stat)
Accidently changed the struct stat uid/gid members
to uid_t and gid_t, but those get set to
__kernel_uid32_t and __kernel_gid32_t respectively.
Those are of type 'int' but the structure is meant
to have 'short'. So use uid16_t and gid16_t to
correct this.
Reported-by: Rob Landley r...@landley.net
Signed-off-by: David S. Miller da...@davemloft.net
---
arch/sparc/include/asm/stat.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/include/asm/stat.h b/arch/sparc/include/asm/stat.h
index 55db5ec..39327d6 100644
--- a/arch/sparc/include/asm/stat.h
+++ b/arch/sparc/include/asm/stat.h
@@ -53,8 +53,8 @@ struct stat {
ino_t st_ino;
mode_t st_mode;
short st_nlink;
- uid_t st_uid;
- gid_t st_gid;
+ uid16_t st_uid;
+ gid16_t st_gid;
unsigned short st_rdev;
off_t st_size;
time_t st_atime;
--
1.6.6.1
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On 02/22/2010 05:08 PM, Michael S. Tsirkin wrote: I imagine all arches need an instruction. For reads as well. Note, gcc has a __sync_synchronize() builtin that compiles to mfence on x86. We might use that as a baseline for both rmb and wmb, and let each arch override it incrementally. This it what my patch did. Note it only works well for recent gcc. Do you know how recent? IIRC 4.3 has broken implementation. 4.4 seems OK as far as I can tell. Well, so that idea's down. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On 02/22/2010 09:16 AM, Marcelo Tosatti wrote: Are you concerned about spurious wakeups? Yes. Also, qemu_notify_event() is an undirected notification (wakes up all iothreads, and all devices), whereas -handle_output() is directed (wakes up exactly what is needed). What's the underlying problem? A new input buffer has become available, and we need to re-poll the incoming file descriptor? If so, that's best done from -handle_output() (either by waking the iothread or calling read() itself and perhaps receiving -EAGAIN). Yes. Sure, perhaps calling read() itself is appropriate, and i see your point thathandle_output contains more context for a smarter decision. But one can argue thats an improvement on top of a dumb wakeup. Spurious calls to qemu_notify_event() also make it difficult to tell when it's actually necessary to call qemu_notify_event() vs. when it's just something that doesn't hurt. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On 02/22/2010 05:29 PM, Anthony Liguori wrote: On 02/22/2010 09:16 AM, Marcelo Tosatti wrote: Are you concerned about spurious wakeups? Yes. Also, qemu_notify_event() is an undirected notification (wakes up all iothreads, and all devices), whereas -handle_output() is directed (wakes up exactly what is needed). What's the underlying problem? A new input buffer has become available, and we need to re-poll the incoming file descriptor? If so, that's best done from -handle_output() (either by waking the iothread or calling read() itself and perhaps receiving -EAGAIN). Yes. Sure, perhaps calling read() itself is appropriate, and i see your point thathandle_output contains more context for a smarter decision. But one can argue thats an improvement on top of a dumb wakeup. Spurious calls to qemu_notify_event() also make it difficult to tell when it's actually necessary to call qemu_notify_event() vs. when it's just something that doesn't hurt. One improvement in this area would be to add a context parameter (which eventually resolves to the underlying thread). Currently we'd ignore it since we have just one iothread, but it would serve to document what's being polled, and later direct the wakeup to the correct thread. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On 02/22/2010 09:32 AM, Avi Kivity wrote: On 02/22/2010 05:29 PM, Anthony Liguori wrote: On 02/22/2010 09:16 AM, Marcelo Tosatti wrote: Are you concerned about spurious wakeups? Yes. Also, qemu_notify_event() is an undirected notification (wakes up all iothreads, and all devices), whereas -handle_output() is directed (wakes up exactly what is needed). What's the underlying problem? A new input buffer has become available, and we need to re-poll the incoming file descriptor? If so, that's best done from -handle_output() (either by waking the iothread or calling read() itself and perhaps receiving -EAGAIN). Yes. Sure, perhaps calling read() itself is appropriate, and i see your point thathandle_output contains more context for a smarter decision. But one can argue thats an improvement on top of a dumb wakeup. Spurious calls to qemu_notify_event() also make it difficult to tell when it's actually necessary to call qemu_notify_event() vs. when it's just something that doesn't hurt. One improvement in this area would be to add a context parameter (which eventually resolves to the underlying thread). Currently we'd ignore it since we have just one iothread, but it would serve to document what's being polled, and later direct the wakeup to the correct thread. Ends up looking a lot like a condition. It's not necessarily a bad thing to model. Regards, Anthony Liguori
[Qemu-devel] [PATCH] tcg: fix build on 32-bit hppa, ppc and sparc hosts
The qemu_ld32s op is only defined if TCG_TARGET_REG_BITS == 64.
Signed-off-by: Jay Foad jay.f...@gmail.com
---
tcg/hppa/tcg-target.c |1 -
tcg/ppc/tcg-target.c |2 --
tcg/sparc/tcg-target.c |4
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tcg/hppa/tcg-target.c b/tcg/hppa/tcg-target.c
index ddce60c..4677971 100644
--- a/tcg/hppa/tcg-target.c
+++ b/tcg/hppa/tcg-target.c
@@ -936,7 +936,6 @@ static const TCGTargetOpDef hppa_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L, L } },
{ INDEX_op_qemu_ld16s, { r, L, L } },
{ INDEX_op_qemu_ld32u, { r, L, L } },
-{ INDEX_op_qemu_ld32s, { r, L, L } },
{ INDEX_op_qemu_ld64, { r, r, L, L } },
{ INDEX_op_qemu_st8, { L, L, L } },
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 903b69f..15d8b85 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -1693,7 +1693,6 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
-{ INDEX_op_qemu_ld32s, { r, L } },
{ INDEX_op_qemu_ld64, { r, r, L } },
{ INDEX_op_qemu_st8, { K, K } },
@@ -1706,7 +1705,6 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L, L } },
{ INDEX_op_qemu_ld16s, { r, L, L } },
{ INDEX_op_qemu_ld32u, { r, L, L } },
-{ INDEX_op_qemu_ld32s, { r, L, L } },
{ INDEX_op_qemu_ld64, { r, L, L, L } },
{ INDEX_op_qemu_st8, { K, K, K } },
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 891b8c4..d4ddaa7 100644
--- a/tcg/sparc/tcg-target.c
+++ b/tcg/sparc/tcg-target.c
@@ -1319,9 +1319,11 @@ static inline void tcg_out_op(TCGContext *s,
int opc, const TCGArg *args,
case INDEX_op_qemu_ld32u:
tcg_out_qemu_ld(s, args, 2);
break;
+#if TCG_TARGET_REG_BITS == 64
case INDEX_op_qemu_ld32s:
tcg_out_qemu_ld(s, args, 2 | 4);
break;
+#endif
case INDEX_op_qemu_st8:
tcg_out_qemu_st(s, args, 0);
break;
@@ -1471,7 +1473,9 @@ static const TCGTargetOpDef sparc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
+#if TCG_TARGET_REG_BITS == 64
{ INDEX_op_qemu_ld32s, { r, L } },
+#endif
{ INDEX_op_qemu_st8, { L, L } },
{ INDEX_op_qemu_st16, { L, L } },
Re: [Qemu-devel] Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY
On 02/22/2010 05:42 PM, Anthony Liguori wrote: Spurious calls to qemu_notify_event() also make it difficult to tell when it's actually necessary to call qemu_notify_event() vs. when it's just something that doesn't hurt. One improvement in this area would be to add a context parameter (which eventually resolves to the underlying thread). Currently we'd ignore it since we have just one iothread, but it would serve to document what's being polled, and later direct the wakeup to the correct thread. Ends up looking a lot like a condition. It's not necessarily a bad thing to model. But the implementation is very different - condition variables sleep in pthread_cond_wait, the iothread sleeps in poll(). qemu_notify_event() is really requesting iothread t to re-add file fd to its poll set. Maybe we should make this a CharDriverState method. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v2] tcg: fix assertion with --enable-debug
Does it build if you remove line 1696? If so, I'd suggest doing that. Yes, that fixes it. Please grep through all tcg targets and send a patch removing all references to ld32s if you think it's not necessary. Done. Unfortunately I'm not in a position to try building any of the affected tcg targets. Or is there a way I can test it without an hppa/ppc/sparc cross-compiler? Thanks, Jay.
Re: [Qemu-devel] [PATCH] tcg: fix build on 32-bit hppa, ppc and sparc hosts
Jay Foad schrieb:
The qemu_ld32s op is only defined if TCG_TARGET_REG_BITS == 64.
Signed-off-by: Jay Foad jay.f...@gmail.com
---
tcg/hppa/tcg-target.c |1 -
tcg/ppc/tcg-target.c |2 --
tcg/sparc/tcg-target.c |4
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/tcg/hppa/tcg-target.c b/tcg/hppa/tcg-target.c
index ddce60c..4677971 100644
--- a/tcg/hppa/tcg-target.c
+++ b/tcg/hppa/tcg-target.c
@@ -936,7 +936,6 @@ static const TCGTargetOpDef hppa_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L, L } },
{ INDEX_op_qemu_ld16s, { r, L, L } },
{ INDEX_op_qemu_ld32u, { r, L, L } },
-{ INDEX_op_qemu_ld32s, { r, L, L } },
{ INDEX_op_qemu_ld64, { r, r, L, L } },
{ INDEX_op_qemu_st8, { L, L, L } },
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 903b69f..15d8b85 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -1693,7 +1693,6 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
-{ INDEX_op_qemu_ld32s, { r, L } },
No. As I wrote in the original thread,
conditional compilation is needed here
(or you will get new compile errors).
{ INDEX_op_qemu_ld64, { r, r, L } },
{ INDEX_op_qemu_st8, { K, K } },
@@ -1706,7 +1705,6 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L, L } },
{ INDEX_op_qemu_ld16s, { r, L, L } },
{ INDEX_op_qemu_ld32u, { r, L, L } },
-{ INDEX_op_qemu_ld32s, { r, L, L } },
dto.
{ INDEX_op_qemu_ld64, { r, L, L, L } },
{ INDEX_op_qemu_st8, { K, K, K } },
diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
index 891b8c4..d4ddaa7 100644
--- a/tcg/sparc/tcg-target.c
+++ b/tcg/sparc/tcg-target.c
@@ -1319,9 +1319,11 @@ static inline void tcg_out_op(TCGContext *s,
int opc, const TCGArg *args,
case INDEX_op_qemu_ld32u:
tcg_out_qemu_ld(s, args, 2);
break;
+#if TCG_TARGET_REG_BITS == 64
case INDEX_op_qemu_ld32s:
tcg_out_qemu_ld(s, args, 2 | 4);
break;
+#endif
case INDEX_op_qemu_st8:
tcg_out_qemu_st(s, args, 0);
break;
@@ -1471,7 +1473,9 @@ static const TCGTargetOpDef sparc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
+#if TCG_TARGET_REG_BITS == 64
{ INDEX_op_qemu_ld32s, { r, L } },
+#endif
{ INDEX_op_qemu_st8, { L, L } },
{ INDEX_op_qemu_st16, { L, L } },
Maybe my comment applies also to the change in
tcg/hppa/tcg-target.c, but I tested only ppc
(using cross compilation).
Regards,
Stefan
Re: [Qemu-devel] [PATCH] tcg: fix build on 32-bit hppa, ppc and sparc hosts
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -1693,7 +1693,6 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
- { INDEX_op_qemu_ld32s, { r, L } },
No. As I wrote in the original thread,
conditional compilation is needed here
(or you will get new compile errors).
In tcg/ppc/, TCG_TARGET_REG_BITS is always 32, isn't it?
Thanks,
Jay.
Re: [Qemu-devel] [PATCH] tcg: fix build on 32-bit hppa, ppc and sparc hosts
On Mon, 22 Feb 2010, Jay Foad wrote: The qemu_ld32s op is only defined if TCG_TARGET_REG_BITS == 64. Your mail client mangled the patch. [..snip..] @@ -1319,9 +1319,11 @@ static inline void tcg_out_op(TCGContext *s, int opc, const TCGArg *args, Here. [..snip..] Fixed and applied. -- mailto:av1...@comtv.ru
[Qemu-devel] [PATCH] tcg/ppc: Add missing conditional compilation
INDEX_op_qemu_ld32s is only used when
TCG_TARGET_REG_BITS == 64.
This fixes a compile error
(reported by Alexander Graf).
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
tcg/ppc/tcg-target.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcg/ppc/tcg-target.c b/tcg/ppc/tcg-target.c
index 903b69f..9f801c2 100644
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -1693,7 +1693,9 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
+#if TCG_TARGET_REG_BITS == 64
{ INDEX_op_qemu_ld32s, { r, L } },
+#endif
{ INDEX_op_qemu_ld64, { r, r, L } },
{ INDEX_op_qemu_st8, { K, K } },
@@ -1706,7 +1708,9 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L, L } },
{ INDEX_op_qemu_ld16s, { r, L, L } },
{ INDEX_op_qemu_ld32u, { r, L, L } },
+#if TCG_TARGET_REG_BITS == 64
{ INDEX_op_qemu_ld32s, { r, L, L } },
+#endif
{ INDEX_op_qemu_ld64, { r, L, L, L } },
{ INDEX_op_qemu_st8, { K, K, K } },
--
1.6.6.1
Re: [Qemu-devel] Address translation - virt-phys-ram
Anthony Liguori wrote: cpu_physical_memory_map(). But this function has some subtle characteristics. It may return a bounce buffer if you attempt to map MMIO memory. There is a limited pool of bounce buffers available so it may return NULL in the event that it cannot allocate a bounce buffer. It may also return a partial result if you're attempting to map a region that straddles multiple memory slots. Thanks. I had found this, but was unsure as to wether it was quite what I wanted. (also is it possible to tell when it has (eg.) allocated a bounce buffer?) Basically, I need to get buffer(s) from guest userspace into the hosts address space. The buffers are virtually contiguous but likely physically discontiguous. They are allocated with malloc() and theres nothing I can do about that. The obvious but slow solution would be to copy all the buffers into nice virtio-based scatter/gather buffers and feed them to the host that way, however its not fast enough. Right now I have a little driver I have written that allows a buffer to be mmap()ed by the guest userspace, and this is pushed to the host via virtio s/g io when the guest calls fsync(). This buffer contains the data that must be passed to the host, however this data may often contain pointers to (that is, userspace virtual addresses of) buffers of unknown sizes which the host also needs to access. These buffers are what I need to read from the guests RAM. The buffers will likely remain active across multiple different calls to the host so their pages will need to be available. As the calls always happen when that specific process is active, I'd guess the worst we need to do is generate a page fault to unswap the page(s). Can that be caused by qemu (under kvm)? It seems that cpu_physical_memory_map() deals with physically contiguous areas of guest address space. I need to get a host-side mapping of a *virtually* contiguous (possibly physically discontiguous) set of guest pages. If this can be done, it'd mean direct transfer of data from guest application to host shared library, which would be a major win. -Ian
Re: [Qemu-devel] [PATCH] Fix hanging user monitor when using balloon command
On Fri, 2010-02-19 at 15:47 -0600, Anthony Liguori wrote: On 02/12/2010 02:55 PM, Adam Litke wrote: Arghh... Adding missing S-O-B Hi Anthony. I wonder if there was a problem when importing my async command handler patchset. Since the 'balloon' command completes immediately, it must call the completion callback before returning. That call was missing but is added by the patch below. Signed-off-by: Adam Litkea...@us.ibm.com Applied. Thanks. This patch application failed. My patch adds a cb() call in do_balloon(), but the change in git has added the cb() call to do_info_balloon(). That is causing qemu segfaults. Applying the following should correct the damage. Thanks. Fix for commit: 5c366a8a3d7ac71beda8499caa815cb3ea95eb58 The cb() call is needed in do_balloon(), not do_info_balloon(). Signed-off-by: Adam Litke a...@us.ibm.com diff --git a/monitor.c b/monitor.c index b1a6edc..c7d2117 100644 --- a/monitor.c +++ b/monitor.c @@ -2309,7 +2309,6 @@ static int do_info_balloon(Monitor *mon, MonitorCompletion cb, void *opaque) return -1; } -cb(opaque, NULL); return 0; } @@ -2332,6 +2331,7 @@ static int do_balloon(Monitor *mon, const QDict *params, return -1; } +cb(opaque, NULL); return 0; } -- Thanks, Adam
Re: [Qemu-devel] Address translation - virt-phys-ram
On 02/22/2010 10:46 AM, Ian Molton wrote: Anthony Liguori wrote: cpu_physical_memory_map(). But this function has some subtle characteristics. It may return a bounce buffer if you attempt to map MMIO memory. There is a limited pool of bounce buffers available so it may return NULL in the event that it cannot allocate a bounce buffer. It may also return a partial result if you're attempting to map a region that straddles multiple memory slots. Thanks. I had found this, but was unsure as to wether it was quite what I wanted. (also is it possible to tell when it has (eg.) allocated a bounce buffer?) Basically, I need to get buffer(s) from guest userspace into the hosts address space. The buffers are virtually contiguous but likely physically discontiguous. They are allocated with malloc() and theres nothing I can do about that. The obvious but slow solution would be to copy all the buffers into nice virtio-based scatter/gather buffers and feed them to the host that way, however its not fast enough. Why is this slow? Regards, Anthony Liguori Right now I have a little driver I have written that allows a buffer to be mmap()ed by the guest userspace, and this is pushed to the host via virtio s/g io when the guest calls fsync(). This buffer contains the data that must be passed to the host, however this data may often contain pointers to (that is, userspace virtual addresses of) buffers of unknown sizes which the host also needs to access. These buffers are what I need to read from the guests RAM. The buffers will likely remain active across multiple different calls to the host so their pages will need to be available. As the calls always happen when that specific process is active, I'd guess the worst we need to do is generate a page fault to unswap the page(s). Can that be caused by qemu (under kvm)? It seems that cpu_physical_memory_map() deals with physically contiguous areas of guest address space. I need to get a host-side mapping of a *virtually* contiguous (possibly physically discontiguous) set of guest pages. If this can be done, it'd mean direct transfer of data from guest application to host shared library, which would be a major win. -Ian
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
Acked-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Index: qemu/kvm-all.c === --- qemu.orig/kvm-all.c +++ qemu/kvm-all.c @@ -21,6 +21,7 @@ #include linux/kvm.h #include qemu-common.h +#include qemu-barrier.h #include sysemu.h #include hw/hw.h #include gdbstub.h @@ -730,7 +731,7 @@ void kvm_flush_coalesced_mmio_buffer(voi ent = ring-coalesced_mmio[ring-first]; cpu_physical_memory_write(ent-phys_addr, ent-data, ent-len); -/* FIXME smp_wmb() */ +smp_wmb(); ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX; } } Index: qemu/qemu-barrier.h === --- /dev/null +++ qemu/qemu-barrier.h @@ -0,0 +1,7 @@ +#ifndef __QEMU_BARRIER_H +#define __QEMU_BARRIER_H 1 + +/* FIXME: arch dependant, x86 version */ +#define smp_wmb() asm volatile( ::: memory) + +#endif
Re: [Qemu-devel] [PATCH] tcg: fix build on 32-bit hppa, ppc and sparc hosts
Jay Foad schrieb:
--- a/tcg/ppc/tcg-target.c
+++ b/tcg/ppc/tcg-target.c
@@ -1693,7 +1693,6 @@ static const TCGTargetOpDef ppc_op_defs[] = {
{ INDEX_op_qemu_ld16u, { r, L } },
{ INDEX_op_qemu_ld16s, { r, L } },
{ INDEX_op_qemu_ld32u, { r, L } },
-{ INDEX_op_qemu_ld32s, { r, L } },
No. As I wrote in the original thread,
conditional compilation is needed here
(or you will get new compile errors).
In tcg/ppc/, TCG_TARGET_REG_BITS is always 32, isn't it?
Thanks,
Jay.
Yes, you are right. Please excuse my wrong feedback.
Stefan
[Qemu-devel] Re: [patch uq/master 2/2] kvm-all.c: define smp_wmb and use it for coalesced mmio
On 02/22/2010 06:57 PM, Marcelo Tosatti wrote: Acked-by: Michael S. Tsirkinm...@redhat.com Signed-off-by: Marcelo Tosattimtosa...@redhat.com Applied, thanks. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] tcg/ppc: Add missing conditional compilation
On Mon, 22 Feb 2010, Stefan Weil wrote: INDEX_op_qemu_ld32s is only used when TCG_TARGET_REG_BITS == 64. TCG_TARGET_REG_BITS is always 32 for PPC32. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] Address translation - virt-phys-ram
Anthony Liguori wrote: On 02/22/2010 10:46 AM, Ian Molton wrote: Anthony Liguori wrote: cpu_physical_memory_map(). But this function has some subtle characteristics. It may return a bounce buffer if you attempt to map MMIO memory. There is a limited pool of bounce buffers available so it may return NULL in the event that it cannot allocate a bounce buffer. It may also return a partial result if you're attempting to map a region that straddles multiple memory slots. Thanks. I had found this, but was unsure as to wether it was quite what I wanted. (also is it possible to tell when it has (eg.) allocated a bounce buffer?) Basically, I need to get buffer(s) from guest userspace into the hosts address space. The buffers are virtually contiguous but likely physically discontiguous. They are allocated with malloc() and theres nothing I can do about that. The obvious but slow solution would be to copy all the buffers into nice virtio-based scatter/gather buffers and feed them to the host that way, however its not fast enough. Why is this slow? Because the buffers will all have to be copied. So far, switching from abusing an instruction to interrupt qemu to using virtio has incurred a roughly 5x slowdown. I'd guess much of this is down to the fact we have to switch to kernel-mode on the guest and back again for every single GL call... If I can establish some kind of stable guest_virt-phys-host_virt mapping, many of the problems will just 'go away'. a way to interrupt qemu from user-mode on the guest without involving the guest kernel would be quite awesome also (theres really nothing we want the kernel to actually /do/ here, it just adds overhead). -Ian
Re: [Qemu-devel] Address translation - virt-phys-ram
Ian Molton wrote: Anthony Liguori wrote: On 02/22/2010 10:46 AM, Ian Molton wrote: Anthony Liguori wrote: cpu_physical_memory_map(). But this function has some subtle characteristics. It may return a bounce buffer if you attempt to map MMIO memory. There is a limited pool of bounce buffers available so it may return NULL in the event that it cannot allocate a bounce buffer. It may also return a partial result if you're attempting to map a region that straddles multiple memory slots. Thanks. I had found this, but was unsure as to wether it was quite what I wanted. (also is it possible to tell when it has (eg.) allocated a bounce buffer?) Basically, I need to get buffer(s) from guest userspace into the hosts address space. The buffers are virtually contiguous but likely physically discontiguous. They are allocated with malloc() and theres nothing I can do about that. The obvious but slow solution would be to copy all the buffers into nice virtio-based scatter/gather buffers and feed them to the host that way, however its not fast enough. Why is this slow? Because the buffers will all have to be copied. So far, switching from abusing an instruction to interrupt qemu to using virtio has incurred a roughly 5x slowdown. I'd guess much of this is down to the fact we have to switch to kernel-mode on the guest and back again for every single GL call... If I can establish some kind of stable guest_virt-phys-host_virt mapping, many of the problems will just 'go away'. a way to interrupt qemu from user-mode on the guest without involving the guest kernel would be quite awesome also (theres really nothing we want the kernel to actually /do/ here, it just adds overhead). I guess what you really want is some shm region between host and guess that you can use as ring buffer. Then you could run a timer on the host side to flush it or have some sort of callback when you urgently need to flush it manually. The benefit here is that you can actually make use of multiple threads. There's no need to intercept the guest at all just because it wants to issue some GL operations. Alex
Re: [Qemu-devel] Re: qemu-kvm 0.12.2 VNC segfault
Avi Kivity a...@redhat.com writes: On 02/21/2010 07:23 PM, Chris Webb wrote: Some sort of race where a client disconnects and is removed from the client list while the vnc_refresh() loop is iterating over it, maybe? Looks like c727a05459, and high time for 0.12.3. Anthony? Ah yes, looks like this was exactly the case that commit was trying to prevent. Thanks! Best wishes, Chris.
[Qemu-devel] [PATCH] Fix to 'gdb detach' stub
With this patch, 'gdb detach' correctly resumes the inferior execution after detaching the debugger. The bug was caused by qemu asking gdb to execute a syscall (isatty) after the detach, and then waiting (forever) for the reply. I fixed this by properly setting gdb_syscall_mode appropriately in the 'detach' packet handling, so subsequent syscalls are solved by qemu rather than gdb. I tested this manually. Please commit it for me if accepted, since I don't have write privileges. Thanks! Daniel. 2010-02-22 Daniel Gutson dgut...@codesourcery.com * gdbstub.c (gdb_handle_packet): set gdb_syscall_mode properly. -- Daniel Gutson CodeSourcery www.codesourcery.com diff --git a/gdbstub.c b/gdbstub.c index 91c5f68..92bb36d 100644 --- a/gdbstub.c +++ b/gdbstub.c @@ -1848,6 +1848,7 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf) case 'D': /* Detach packet */ gdb_breakpoint_remove_all(); + gdb_syscall_mode = GDB_SYS_DISABLED; gdb_continue(s); put_packet(s, OK); break;
Re: [Qemu-devel] getfd monitor command broken
On Fri, 19 Feb 2010 10:21:41 -0800 Ed Swierk eswi...@aristanetworks.com wrote: Commit c62313bbdc48f72e93fa8196f2fff96ba35e4e9d seems to have broken the getfd monitor command in qemu 0.12. Does it work with current master? How do you reproduce it?
[Qemu-devel] Full build broken
Hi Paul, Commit bc3b26f5 breaks a full QEMU build for me: cc1: warnings being treated as errors /home/lcapitulino/src/qmp-unstable/hw/pl181.c: In function ‘pl181_fifo_run’: /home/lcapitulino/src/qmp-unstable/hw/pl181.c:185: error: ‘value’ may be used uninitialized in this function make[1]: *** [pl181.o] Error 1 make: *** [subdir-arm-softmmu] Error 2 make: *** Waiting for unfinished jobs
[Qemu-devel] Re: [PATCH] apb_pci: minor cleanup
Thanks, applied.
On 2/22/10, Michael S. Tsirkin m...@redhat.com wrote:
pci_data_write ignores high 8 bit in address,
so there seems to be no need to set them
in apb_pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Blue Swirl, please consider the following (untested) patch.
Thanks!
hw/apb_pci.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index ebfcd41..f14b432 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -187,8 +187,7 @@ static void apb_pci_config_write(APBState *s,
target_phys_addr_t addr,
uint32_t val, int size)
{
APB_DPRINTF(%s: addr TARGET_FMT_lx val %x\n, __func__, addr, val);
-pci_data_write(s-host_state.bus, (addr 0x00ff) | (1u 31), val,
- size);
+pci_data_write(s-host_state.bus, addr, val, size);
}
static uint32_t apb_pci_config_read(APBState *s, target_phys_addr_t addr,
@@ -196,8 +195,7 @@ static uint32_t apb_pci_config_read(APBState *s,
target_phys_addr_t addr,
{
uint32_t ret;
-ret = pci_data_read(s-host_state.bus, (addr 0x00ff) | (1u 31),
-size);
+ret = pci_data_read(s-host_state.bus, addr, size);
APB_DPRINTF(%s: addr TARGET_FMT_lx - %x\n, __func__, addr, ret);
return ret;
}
--
1.7.0.18.g0d53a5
[Qemu-devel] Re: [PATCH] apc_pci: simplify using rwhandler
Thanks, applied.
On 2/22/10, Michael S. Tsirkin m...@redhat.com wrote:
Use rwhandler to simplify apb_pci.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Blue Swirl, please consider the following
(compile-tested only) patch.
hw/apb_pci.c | 74
++---
1 files changed, 13 insertions(+), 61 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index f14b432..324e74e 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -29,6 +29,7 @@
#include sysbus.h
#include pci.h
#include pci_host.h
+#include rwhandler.h
#include apb_pci.h
/* debug APB */
@@ -65,6 +66,7 @@ do { printf(APB: fmt , ## __VA_ARGS__); } while (0)
typedef struct APBState {
SysBusDevice busdev;
PCIHostState host_state;
+ReadWriteHandler pci_config_handler;
uint32_t iommu[4];
uint32_t pci_control[16];
uint32_t pci_irq_map[8];
@@ -183,80 +185,28 @@ static CPUReadMemoryFunc * const apb_config_read[] = {
apb_config_readl,
};
-static void apb_pci_config_write(APBState *s, target_phys_addr_t addr,
+static void apb_pci_config_write(ReadWriteHandler *h, pcibus_t addr,
uint32_t val, int size)
{
+APBState *s = container_of(h, APBState, pci_config_handler);
+
+val = qemu_bswap_len(val, size);
APB_DPRINTF(%s: addr TARGET_FMT_lx val %x\n, __func__, addr, val);
pci_data_write(s-host_state.bus, addr, val, size);
}
-static uint32_t apb_pci_config_read(APBState *s, target_phys_addr_t addr,
+static uint32_t apb_pci_config_read(ReadWriteHandler *h, pcibus_t addr,
int size)
{
uint32_t ret;
+APBState *s = container_of(h, APBState, pci_config_handler);
ret = pci_data_read(s-host_state.bus, addr, size);
+ret = qemu_bswap_len(ret, size);
APB_DPRINTF(%s: addr TARGET_FMT_lx - %x\n, __func__, addr, ret);
return ret;
}
-static void apb_pci_config_writel(void *opaque, target_phys_addr_t addr,
- uint32_t val)
-{
-APBState *s = opaque;
-
-apb_pci_config_write(s, addr, bswap32(val), 4);
-}
-
-static void apb_pci_config_writew(void *opaque, target_phys_addr_t addr,
- uint32_t val)
-{
-APBState *s = opaque;
-
-apb_pci_config_write(s, addr, bswap16(val), 2);
-}
-
-static void apb_pci_config_writeb(void *opaque, target_phys_addr_t addr,
- uint32_t val)
-{
-APBState *s = opaque;
-
-apb_pci_config_write(s, addr, val, 1);
-}
-
-static uint32_t apb_pci_config_readl(void *opaque, target_phys_addr_t addr)
-{
-APBState *s = opaque;
-
-return bswap32(apb_pci_config_read(s, addr, 4));
-}
-
-static uint32_t apb_pci_config_readw(void *opaque, target_phys_addr_t addr)
-{
-APBState *s = opaque;
-
-return bswap16(apb_pci_config_read(s, addr, 2));
-}
-
-static uint32_t apb_pci_config_readb(void *opaque, target_phys_addr_t addr)
-{
-APBState *s = opaque;
-
-return apb_pci_config_read(s, addr, 1);
-}
-
-static CPUWriteMemoryFunc * const apb_pci_config_writes[] = {
-apb_pci_config_writeb,
-apb_pci_config_writew,
-apb_pci_config_writel,
-};
-
-static CPUReadMemoryFunc * const apb_pci_config_reads[] = {
-apb_pci_config_readb,
-apb_pci_config_readw,
-apb_pci_config_readl,
-};
-
static void pci_apb_iowriteb (void *opaque, target_phys_addr_t addr,
uint32_t val)
{
@@ -453,8 +403,10 @@ static int pci_pbm_init_device(SysBusDevice *dev)
pci_apb_iowrite, s);
sysbus_init_mmio(dev, 0x1ULL, pci_ioport);
/* pci_config */
-pci_config = cpu_register_io_memory(apb_pci_config_reads,
-apb_pci_config_writes, s);
+s-pci_config_handler.read = apb_pci_config_read;
+s-pci_config_handler.write = apb_pci_config_write;
+pci_config = cpu_register_io_memory_simple(s-pci_config_handler);
+assert(pci_config = 0);
sysbus_init_mmio(dev, 0x100ULL, pci_config);
/* mem_data */
pci_mem_data = pci_host_data_register_mmio(s-host_state);
--
1.7.0.18.g0d53a5
[Qemu-devel] [PATCH 0/8] [GIT PULL] qemu-kvm.git uq/master queue
The following changes since commit bf76bafa5ade434ef2747caa95510ecb7946: Edgar E. Iglesias (1): crisv10: Prettify. are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Jan Kiszka (1): kvm: Fix eflags corruption in kvm mode Jes Sorensen (1): kvm: Kill CR3_CACHE feature references Marcelo Tosatti (5): block SIGCHLD in vcpu thread(s) kvm specific wait_io_event kvm: consume internal signal with sigtimedwait kvm: remove pre-entry exit_request check with iothread enabled kvm-all.c: define smp_wmb and use it for coalesced mmio Paolo Bonzini (1): use eventfd for iothread cpu-exec.c| 12 +++-- kvm-all.c | 24 ++- kvm.h |1 + osdep.c | 32 ++ qemu-barrier.h|7 +++ qemu-common.h |1 + target-i386/kvm.c |3 - vl.c | 123 - 8 files changed, 173 insertions(+), 30 deletions(-) create mode 100644 qemu-barrier.h
[Qemu-devel] [PATCH 8/8] kvm-all.c: define smp_wmb and use it for coalesced mmio
Acked-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com --- kvm-all.c |3 ++- qemu-barrier.h |7 +++ 2 files changed, 9 insertions(+), 1 deletions(-) create mode 100644 qemu-barrier.h diff --git a/kvm-all.c b/kvm-all.c index 91d3cbd..1a02076 100644 --- a/kvm-all.c +++ b/kvm-all.c @@ -21,6 +21,7 @@ #include linux/kvm.h #include qemu-common.h +#include qemu-barrier.h #include sysemu.h #include hw/hw.h #include gdbstub.h @@ -730,7 +731,7 @@ void kvm_flush_coalesced_mmio_buffer(void) ent = ring-coalesced_mmio[ring-first]; cpu_physical_memory_write(ent-phys_addr, ent-data, ent-len); -/* FIXME smp_wmb() */ +smp_wmb(); ring-first = (ring-first + 1) % KVM_COALESCED_MMIO_MAX; } } diff --git a/qemu-barrier.h b/qemu-barrier.h new file mode 100644 index 000..3bd1075 --- /dev/null +++ b/qemu-barrier.h @@ -0,0 +1,7 @@ +#ifndef __QEMU_BARRIER_H +#define __QEMU_BARRIER_H 1 + +/* FIXME: arch dependant, x86 version */ +#define smp_wmb() asm volatile( ::: memory) + +#endif -- 1.6.6
[Qemu-devel] [PATCH 5/8] kvm specific wait_io_event
In KVM mode the global mutex is released when vcpus are executing,
which means acquiring the fairness mutex is not required.
Also for KVM there is one thread per vcpu, so tcg_has_work is meaningless.
Add a new qemu_wait_io_event_common function to hold common code
between TCG/KVM.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
---
vl.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/vl.c b/vl.c
index 3bc618d..af198c1 100644
--- a/vl.c
+++ b/vl.c
@@ -3383,6 +3383,7 @@ static QemuCond qemu_pause_cond;
static void block_io_signals(void);
static void unblock_io_signals(void);
static int tcg_has_work(void);
+static int cpu_has_work(CPUState *env);
static int qemu_init_main_loop(void)
{
@@ -3403,6 +3404,15 @@ static int qemu_init_main_loop(void)
return 0;
}
+static void qemu_wait_io_event_common(CPUState *env)
+{
+if (env-stop) {
+env-stop = 0;
+env-stopped = 1;
+qemu_cond_signal(qemu_pause_cond);
+}
+}
+
static void qemu_wait_io_event(CPUState *env)
{
while (!tcg_has_work())
@@ -3419,11 +3429,15 @@ static void qemu_wait_io_event(CPUState *env)
qemu_mutex_unlock(qemu_fair_mutex);
qemu_mutex_lock(qemu_global_mutex);
-if (env-stop) {
-env-stop = 0;
-env-stopped = 1;
-qemu_cond_signal(qemu_pause_cond);
-}
+qemu_wait_io_event_common(env);
+}
+
+static void qemu_kvm_wait_io_event(CPUState *env)
+{
+while (!cpu_has_work(env))
+qemu_cond_timedwait(env-halt_cond, qemu_global_mutex, 1000);
+
+qemu_wait_io_event_common(env);
}
static int qemu_cpu_exec(CPUState *env);
@@ -3449,7 +3463,7 @@ static void *kvm_cpu_thread_fn(void *arg)
while (1) {
if (cpu_can_run(env))
qemu_cpu_exec(env);
-qemu_wait_io_event(env);
+qemu_kvm_wait_io_event(env);
}
return NULL;
--
1.6.6
[Qemu-devel] [PATCH 3/8] kvm: Kill CR3_CACHE feature references
From: Jes Sorensen jes.soren...@redhat.com
Remove all references to KVM_CR3_CACHE as it was never implemented.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
---
target-i386/kvm.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 0d08cd5..5d9aecc 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -158,9 +158,6 @@ struct kvm_para_features {
#ifdef KVM_CAP_PV_MMU
{ KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
#endif
-#ifdef KVM_CAP_CR3_CACHE
-{ KVM_CAP_CR3_CACHE, KVM_FEATURE_CR3_CACHE },
-#endif
{ -1, -1 }
};
--
1.6.6
[Qemu-devel] [PATCH 6/8] kvm: consume internal signal with sigtimedwait
Change the way the internal qemu signal, used for communication between
iothread and vcpus, is handled.
Block and consume it with sigtimedwait on the outer vcpu loop, which
allows more precise timing control.
Change from standard signal (SIGUSR1) to real-time one, so multiple
signals are not collapsed.
Set the signal number on KVM's in-kernel allowed sigmask.
Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
---
kvm-all.c | 19 +
kvm.h |1 +
vl.c | 89
3 files changed, 97 insertions(+), 12 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 79345b2..38c372f 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -771,6 +771,7 @@ int kvm_cpu_exec(CPUState *env)
kvm_arch_post_run(env, run);
if (ret == -EINTR || ret == -EAGAIN) {
+cpu_exit(env);
dprintf(io window exit\n);
ret = 0;
break;
@@ -1116,3 +1117,21 @@ void kvm_remove_all_breakpoints(CPUState *current_env)
{
}
#endif /* !KVM_CAP_SET_GUEST_DEBUG */
+
+int kvm_set_signal_mask(CPUState *env, const sigset_t *sigset)
+{
+struct kvm_signal_mask *sigmask;
+int r;
+
+if (!sigset)
+return kvm_vcpu_ioctl(env, KVM_SET_SIGNAL_MASK, NULL);
+
+sigmask = qemu_malloc(sizeof(*sigmask) + sizeof(*sigset));
+
+sigmask-len = 8;
+memcpy(sigmask-sigset, sigset, sizeof(*sigset));
+r = kvm_vcpu_ioctl(env, KVM_SET_SIGNAL_MASK, sigmask);
+free(sigmask);
+
+return r;
+}
diff --git a/kvm.h b/kvm.h
index e24bbde..9a9cdd5 100644
--- a/kvm.h
+++ b/kvm.h
@@ -53,6 +53,7 @@ int kvm_remove_breakpoint(CPUState *current_env, target_ulong
addr,
target_ulong len, int type);
void kvm_remove_all_breakpoints(CPUState *current_env);
int kvm_update_guest_debug(CPUState *env, unsigned long reinject_trap);
+int kvm_set_signal_mask(CPUState *env, const sigset_t *sigset);
int kvm_pit_in_kernel(void);
int kvm_irqchip_in_kernel(void);
diff --git a/vl.c b/vl.c
index af198c1..dc05da3 100644
--- a/vl.c
+++ b/vl.c
@@ -271,6 +271,12 @@ uint8_t qemu_uuid[16];
static QEMUBootSetHandler *boot_set_handler;
static void *boot_set_opaque;
+#ifdef SIGRTMIN
+#define SIG_IPI (SIGRTMIN+4)
+#else
+#define SIG_IPI SIGUSR1
+#endif
+
static int default_serial = 1;
static int default_parallel = 1;
static int default_virtcon = 1;
@@ -3380,7 +3386,8 @@ static QemuCond qemu_cpu_cond;
static QemuCond qemu_system_cond;
static QemuCond qemu_pause_cond;
-static void block_io_signals(void);
+static void tcg_block_io_signals(void);
+static void kvm_block_io_signals(CPUState *env);
static void unblock_io_signals(void);
static int tcg_has_work(void);
static int cpu_has_work(CPUState *env);
@@ -3432,11 +3439,36 @@ static void qemu_wait_io_event(CPUState *env)
qemu_wait_io_event_common(env);
}
+static void qemu_kvm_eat_signal(CPUState *env, int timeout)
+{
+struct timespec ts;
+int r, e;
+siginfo_t siginfo;
+sigset_t waitset;
+
+ts.tv_sec = timeout / 1000;
+ts.tv_nsec = (timeout % 1000) * 100;
+
+sigemptyset(waitset);
+sigaddset(waitset, SIG_IPI);
+
+qemu_mutex_unlock(qemu_global_mutex);
+r = sigtimedwait(waitset, siginfo, ts);
+e = errno;
+qemu_mutex_lock(qemu_global_mutex);
+
+if (r == -1 !(e == EAGAIN || e == EINTR)) {
+fprintf(stderr, sigtimedwait: %s\n, strerror(e));
+exit(1);
+}
+}
+
static void qemu_kvm_wait_io_event(CPUState *env)
{
while (!cpu_has_work(env))
qemu_cond_timedwait(env-halt_cond, qemu_global_mutex, 1000);
+qemu_kvm_eat_signal(env, 0);
qemu_wait_io_event_common(env);
}
@@ -3446,11 +3478,12 @@ static void *kvm_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
-block_io_signals();
qemu_thread_self(env-thread);
if (kvm_enabled())
kvm_init_vcpu(env);
+kvm_block_io_signals(env);
+
/* signal CPU creation */
qemu_mutex_lock(qemu_global_mutex);
env-created = 1;
@@ -3475,7 +3508,7 @@ static void *tcg_cpu_thread_fn(void *arg)
{
CPUState *env = arg;
-block_io_signals();
+tcg_block_io_signals();
qemu_thread_self(env-thread);
/* signal CPU creation */
@@ -3501,7 +3534,7 @@ void qemu_cpu_kick(void *_env)
CPUState *env = _env;
qemu_cond_broadcast(env-halt_cond);
if (kvm_enabled())
-qemu_thread_signal(env-thread, SIGUSR1);
+qemu_thread_signal(env-thread, SIG_IPI);
}
int qemu_cpu_self(void *_env)
@@ -3520,7 +3553,7 @@ static void cpu_signal(int sig)
cpu_exit(cpu_single_env);
}
-static void block_io_signals(void)
+static void tcg_block_io_signals(void)
{
sigset_t set;
struct sigaction sigact;
@@ -3533,12 +3566,44 @@ static void block_io_signals(void)
pthread_sigmask(SIG_BLOCK, set, NULL);
sigemptyset(set);
-sigaddset(set, SIGUSR1);
+sigaddset(set, SIG_IPI);
[Qemu-devel] [PATCH 2/8] kvm: Fix eflags corruption in kvm mode
From: Jan Kiszka jan.kis...@siemens.com
This should explain a lot of the weird breakages of upstream KVM we've
seen recently (actually we should have seen it much earlier):
Stop translating eflags into TCG format when in kvm mode as we never
translate it back and rather sync this broken state into the kernel.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Signed-off-by: Avi Kivity a...@redhat.com
---
cpu-exec.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 6a290fd..4029ea2 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -228,11 +228,13 @@ int cpu_exec(CPUState *env1)
env = env1;
#if defined(TARGET_I386)
-/* put eflags in CPU temporary format */
-CC_SRC = env-eflags (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
-DF = 1 - (2 * ((env-eflags 10) 1));
-CC_OP = CC_OP_EFLAGS;
-env-eflags = ~(DF_MASK | CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
+if (!kvm_enabled()) {
+/* put eflags in CPU temporary format */
+CC_SRC = env-eflags (CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
+DF = 1 - (2 * ((env-eflags 10) 1));
+CC_OP = CC_OP_EFLAGS;
+env-eflags = ~(DF_MASK | CC_O | CC_S | CC_Z | CC_A | CC_P | CC_C);
+}
#elif defined(TARGET_SPARC)
#elif defined(TARGET_M68K)
env-cc_op = CC_OP_FLAGS;
--
1.6.6
[Qemu-devel] [PATCH 4/8] block SIGCHLD in vcpu thread(s)
Otherwise a vcpu thread can run the sigchild handler causing waitpid() from iothread to fail. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com --- vl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/vl.c b/vl.c index 1957018..3bc618d 100644 --- a/vl.c +++ b/vl.c @@ -3515,6 +3515,7 @@ static void block_io_signals(void) sigaddset(set, SIGUSR2); sigaddset(set, SIGIO); sigaddset(set, SIGALRM); +sigaddset(set, SIGCHLD); pthread_sigmask(SIG_BLOCK, set, NULL); sigemptyset(set); -- 1.6.6
[Qemu-devel] Re: qemu-kvm 0.12.2 VNC segfault
On 02/22/2010 02:54 AM, Avi Kivity wrote: On 02/21/2010 07:23 PM, Chris Webb wrote: Some sort of race where a client disconnects and is removed from the client list while the vnc_refresh() loop is iterating over it, maybe? Looks like c727a05459, and high time for 0.12.3. Anthony? Indeed. Regards, Anthony Liguori
[Qemu-devel] Re: [PATCH] Fix to 'gdb detach' stub
[Re-done with git.] With this patch, 'gdb detach' correctly resumes the inferior execution after detaching the debugger. The bug was caused by qemu asking gdb to execute a syscall (isatty) after the detach, and then waiting (forever) for the reply. I fixed this by properly setting gdb_syscall_mode appropriately in the 'detach' packet handling, so subsequent syscalls are solved by qemu rather than gdb. Signed-off-by: Daniel Gutson dgut...@codesourcery.com --- gdbstub.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/gdbstub.c b/gdbstub.c index 91c5f68..92bb36d 100644 --- a/gdbstub.c +++ b/gdbstub.c @@ -1848,6 +1848,7 @@ static int gdb_handle_packet(GDBState *s, const char *line_buf) case 'D': /* Detach packet */ gdb_breakpoint_remove_all(); + gdb_syscall_mode = GDB_SYS_DISABLED; gdb_continue(s); put_packet(s, OK); break; -- 1.6.2.4
Re: [Qemu-devel] Re: [PATCH] Fix lost serial TX interrupts. Report receive overruns.
On 02/10/2010 04:37 PM, Justin T. Gibbs wrote: Properly formatted patch now attached. Applied. Thanks. Regards, Anthony Liguori -- Justin
Re: [Qemu-devel] [PATCH v2] add close callback for tty-based char device
On 02/10/2010 07:27 PM, David Ahern wrote:
v1 - v2 coding style changes
Add a tty close callback. Right now if a guest device that is connected
to a tty-based chardev in the host is removed, the tty is not closed.
With this patch it is closed.
Example use case is connecting an emulated USB serial cable in the guest
to ttyS0 of the host using the monitor command:
usb_add serial::/dev/ttyS0
and then removing the device with:
usb_del serial::/dev/ttyS0
Signed-off-by: David Aherndaah...@cisco.com
Applied. Thanks.
Regards,
Anthony Liguori
---
qemu-char.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..4169492 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1173,6 +1173,22 @@ static int tty_serial_ioctl(CharDriverState *chr, int
cmd, void *arg)
return 0;
}
+static void qemu_chr_close_tty(CharDriverState *chr)
+{
+FDCharDriver *s = chr-opaque;
+int fd = -1;
+
+if (s) {
+fd = s-fd_in;
+}
+
+fd_chr_close(chr);
+
+if (fd= 0) {
+close(fd);
+}
+}
+
static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
{
const char *filename = qemu_opt_get(opts, path);
@@ -1190,6 +1206,7 @@ static CharDriverState *qemu_chr_open_tty(QemuOpts *opts)
return NULL;
}
chr-chr_ioctl = tty_serial_ioctl;
+chr-chr_close = qemu_chr_close_tty;
return chr;
}
#else /* ! __linux__ ! __sun__ */
Re: [Qemu-devel] Isochronous devices support in QEMU
David Ahern On 02/22/2010 12:32 AM, Taimoor Mirza wrote: Hi all, I've few questions about QEMU: 1) I read in QEMU's official documentation that in case of using host system devices USB devices requiring real time streaming (i.e. USB Video Cameras) are not supported yet. Also there is no isochronous transfer based virtual USB device in QEMU. I want to know what is current status of Iso. support in QEMU? Can I test my Linux based USB As of commit 8e65b7c04965c8355e4ce43211582b6b83054e3d I have been able to pass audio devices to a VM with good success (though I use qemu-kvm, not just qemu). I just started looking at web cameras and not having much luck yet. David host application for ARM with physical iso devices in host USB port? 2) I found a function ohci_service_iso_td in usb-ohci.c file in QEMU source code. 3) I am developing a Linux based USB device using Gadget API. Does QEMU provide USB function controller emulation in such a way that I can run plug this USB device at run time with host machine and can test it? Regards, Taimoor Hotmail: Trusted email with powerful SPAM protection. Sign up now. https://signup.live.com/signup.aspx?id=60969
[Qemu-devel] Re: [PATCH 0/8] [GIT PULL] qemu-kvm.git uq/master queue
On 02/22/2010 03:26 PM, Marcelo Tosatti wrote: The following changes since commit bf76bafa5ade434ef2747caa95510ecb7946: Edgar E. Iglesias (1): crisv10: Prettify. are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Jan Kiszka (1): kvm: Fix eflags corruption in kvm mode Jes Sorensen (1): kvm: Kill CR3_CACHE feature references Marcelo Tosatti (5): block SIGCHLD in vcpu thread(s) kvm specific wait_io_event kvm: consume internal signal with sigtimedwait kvm: remove pre-entry exit_request check with iothread enabled kvm-all.c: define smp_wmb and use it for coalesced mmio Paolo Bonzini (1): use eventfd for iothread Pulled, thanks. In the future, could you just use a [PULL] tag? That's what others are using. Regards, Anthony Liguori cpu-exec.c| 12 +++-- kvm-all.c | 24 ++- kvm.h |1 + osdep.c | 32 ++ qemu-barrier.h|7 +++ qemu-common.h |1 + target-i386/kvm.c |3 - vl.c | 123 - 8 files changed, 173 insertions(+), 30 deletions(-) create mode 100644 qemu-barrier.h
[Qemu-devel] KVM call agenda for Feb 23
Please send in any agenda items you are interested in covering. thanks, -chris
Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch
On Mon, Feb 22, 2010 at 10:33:12AM +0200, Gleb Natapov wrote: On Sun, Feb 21, 2010 at 02:13:51PM -0500, Kevin O'Connor wrote: Are you thinking of moving qemu more torwards what coreboot does, or did you have a different idea in mind? We shouldn't compare coreboot with qemu. Qemu is a hardware. Coreboot is part of a firmware. Coreboot and qemu often face the same problems when trying to pass information into the BIOS. I think it helps to look at how others have solved similar problems. -Kevin
[Qemu-devel] Regression: DOSPlus 1.2-je5 doesn't boot correctly since QEMU-0.6.1
Hi all, This is an very old regression that DOSPlus 1.2-je5 boots in QEMU 0.5~0.6.0, and 0.6.1 breaks booting DOSPlus 1.2-je5 till now. Floppy Disk Image: http://roy.reactos.me:9088/files/dp12je5.zip
[Qemu-devel] Re: Regression: DOSPlus 1.2-je5 doesn't boot correctly since QEMU-0.6.1
2010/2/23 Roy Tam roy...@gmail.com: Hi all, This is an very old regression that DOSPlus 1.2-je5 boots in QEMU 0.5~0.6.0, and 0.6.1 breaks booting DOSPlus 1.2-je5 till now. Floppy Disk Image: http://roy.reactos.me:9088/files/dp12je5.zip OK r1049 breaks booting DOSPlus. Is it really fix the serial interrupt issue? http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=60e336dbb837ef4d5053433f9ee391feb102be36
Re: [Qemu-devel] getfd monitor command broken
On Mon, Feb 22, 2010 at 12:51 PM, Luiz Capitulino
lcapitul...@redhat.com wrote:
How do you reproduce it?
Here's a test program that reproduces the problem. Start qemu with
-chardev socket,id=monitor,path=/tmp/qemu-monitor,server,nowait -mon
chardev=monitor,mode=readline
and run check_getfd /tmp/qemu-monitor. It will print an error and
return nonzero if the monitor output indicates getfd or closefd
failed.
--Ed
/*
* check_getfd
*
* Tests the qemu getfd monitor command
*
* Copyright (c) 2010 Arista Networks, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include stdio.h
#include stdlib.h
#include unistd.h
#include fcntl.h
#include sys/types.h
#include sys/socket.h
#include sys/un.h
int receive_output(int s, char *m) {
unsigned int i = 0;
char buf[10240];
buf[0] = '\0';
while (1) {
if (recv(s, buf[i], 1, 0) 0) {
perror(Failed to receive);
return -1;
}
buf[++i] = '\0';
if ((i 7) !strcmp(buf[i-7], (qemu) ))
break;
}
if (m
((i strlen(m) + 7) || strncmp(buf[i-7-strlen(m)], m, strlen(m {
fprintf(stderr, %s\n, buf);
return -1;
}
return 0;
}
int main(int argc, char *argv[]) {
struct sockaddr_un addr;
int s;
int fd;
char fdbuf[CMSG_SPACE(sizeof(fd))];
struct msghdr msg;
struct cmsghdr *cmsg;
struct iovec mvec;
char *cmd = getfd MYFD\nclosefd MYFD\n;
if (argc != 2) {
printf(Usage: %s QEMU_MONITOR\n\n, argv[0]);
printf( (start qemu with -chardev socket,id=monitor,path=QEMU_MONITOR
,server,nowait -mon chardev=monitor,mode=readline)\n);
return 1;
}
fd = open(/dev/null, O_RDWR);
if (fd 0) {
perror(Failed to open /dev/null);
return 1;
}
memset(addr, 0, sizeof(addr));
addr.sun_family = AF_UNIX;
strncpy(addr.sun_path, argv[1], sizeof(addr.sun_path));
s = socket(PF_UNIX, SOCK_STREAM, 0);
if (s 0) {
perror(No socket);
return 1;
}
if (connect(s, (struct sockaddr *) addr, sizeof(addr)) 0) {
perror(Failed to connect);
return 1;
}
if (receive_output(s, NULL) 0)
return 1;
mvec.iov_base = cmd;
mvec.iov_len = strlen(cmd) + 1;
msg.msg_name = NULL;
msg.msg_namelen = 0;
msg.msg_iov = mvec;
msg.msg_iovlen = 1;
msg.msg_control = fdbuf;
msg.msg_controllen = CMSG_LEN(sizeof(fd));
msg.msg_flags = 0;
cmsg = CMSG_FIRSTHDR(msg);
cmsg-cmsg_level = SOL_SOCKET;
cmsg-cmsg_type = SCM_RIGHTS;
cmsg-cmsg_len = msg.msg_controllen;
memcpy(CMSG_DATA(cmsg), fd, sizeof(fd));
if (sendmsg(s, msg, 0) 0) {
perror(Failed to send);
return 1;
}
if (receive_output(s, \033[K\r\n) 0)
return 1;
if (receive_output(s, \033[K\r\n) 0)
return 1;
return 0;
}
[Qemu-devel] Re: Regression: DOSPlus 1.2-je5 doesn't boot correctly since QEMU-0.6.1
2010/2/23 Roy Tam roy...@gmail.com: 2010/2/23 Roy Tam roy...@gmail.com: Hi all, This is an very old regression that DOSPlus 1.2-je5 boots in QEMU 0.5~0.6.0, and 0.6.1 breaks booting DOSPlus 1.2-je5 till now. Floppy Disk Image: http://roy.reactos.me:9088/files/dp12je5.zip OK r1049 breaks booting DOSPlus. Is it really fix the serial interrupt issue? http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=60e336dbb837ef4d5053433f9ee391feb102be36 Comment out s-thr_ipending = 1; in if (s-lsr UART_LSR_THRE) seems fix this issue.
[Qemu-devel] [BREAKAGE] cc84de9570ffe01a9c3c169bd62ab9586a9a080c breaks win32 build
Hi all, cc84de9570ffe01a9c3c169bd62ab9586a9a080c breaks win32 build as there is no sigset_t in MinGW.
[Qemu-devel] Serial: not checking (lsr UART_LSR_THRE) in IER and not setting thr_ipending (Was Re: Regression: DOSPlus 1.2-je5 doesn't boot correctly since QEMU-0.6.1)
2010/2/23 Roy Tam roy...@gmail.com: 2010/2/23 Roy Tam roy...@gmail.com: 2010/2/23 Roy Tam roy...@gmail.com: Hi all, This is an very old regression that DOSPlus 1.2-je5 boots in QEMU 0.5~0.6.0, and 0.6.1 breaks booting DOSPlus 1.2-je5 till now. Floppy Disk Image: http://roy.reactos.me:9088/files/dp12je5.zip OK r1049 breaks booting DOSPlus. Is it really fix the serial interrupt issue? http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=60e336dbb837ef4d5053433f9ee391feb102be36 Comment out s-thr_ipending = 1; in if (s-lsr UART_LSR_THRE) seems fix this issue. bochs implementation doesn't check for (lsr UART_LSR_THRE) in IER(addr7 == 1), I think we need not check for them and setting thr_ipending. Any serial experts here?
