[Qemu-devel] [PATCH] qemu: virtio-9p: Do not reset atime
Current code resets file's atime to 0 when there is a change in mtime. This results in resetting the atime to "1970-01-01 05:30:00". For example, truncate -s 0 filename results in changing the mtime to the truncate time, but resets the atime to "1970-01-01 05:30:00". utime system call does not have any provision to set only mtime or atime. So change v9fs_wstat_post_chmod function to use utimensat function to change the atime and mtime fields. If tv_nsec field is set to the special value "UTIME_OMIT", corresponding file time stamp is not updated. Signed-off-by: M. Mohan Kumar --- hw/file-op-9p.h |2 +- hw/virtio-9p-local.c |8 hw/virtio-9p.c | 28 3 files changed, 25 insertions(+), 13 deletions(-) diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h index dd82ac7..120c803 100644 --- a/hw/file-op-9p.h +++ b/hw/file-op-9p.h @@ -52,7 +52,7 @@ typedef struct FileOperations int (*chmod)(FsContext *, const char *, FsCred *); int (*chown)(FsContext *, const char *, FsCred *); int (*mknod)(FsContext *, const char *, FsCred *); -int (*utime)(FsContext *, const char *, const struct utimbuf *); +int (*utimensat)(FsContext *, const char *, const struct timespec *); int (*remove)(FsContext *, const char *); int (*symlink)(FsContext *, const char *, const char *, FsCred *); int (*link)(FsContext *, const char *, const char *); diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c index ecd5db9..dd60354 100644 --- a/hw/virtio-9p-local.c +++ b/hw/virtio-9p-local.c @@ -451,10 +451,10 @@ static int local_chown(FsContext *fs_ctx, const char *path, FsCred *credp) return -1; } -static int local_utime(FsContext *ctx, const char *path, -const struct utimbuf *buf) +static int local_utimensat(FsContext *s, const char *path, + const struct timespec *buf) { -return utime(rpath(ctx, path), buf); +return utimensat(AT_FDCWD, rpath(s, path), buf, AT_SYMLINK_NOFOLLOW); } static int local_remove(FsContext *ctx, const char *path) @@ -496,7 +496,7 @@ FileOperations local_ops = { .truncate = local_truncate, .rename = local_rename, .chown = local_chown, -.utime = local_utime, +.utimensat = local_utimensat, .remove = local_remove, .fsync = local_fsync, .statfs = local_statfs, diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c index 1615924..f087122 100644 --- a/hw/virtio-9p.c +++ b/hw/virtio-9p.c @@ -238,10 +238,25 @@ static int v9fs_do_chown(V9fsState *s, V9fsString *path, uid_t uid, gid_t gid) return s->ops->chown(&s->ctx, path->data, &cred); } -static int v9fs_do_utime(V9fsState *s, V9fsString *path, -const struct utimbuf *buf) +static int v9fs_do_utimensat(V9fsState *s, V9fsString *path, V9fsStat v9stat) { -return s->ops->utime(&s->ctx, path->data, buf); +struct timespec ts[2]; + +if (v9stat.atime != -1) { +ts[0].tv_sec = v9stat.atime; +ts[0].tv_nsec = 0; +} else { +ts[0].tv_nsec = UTIME_OMIT; +} + +if (v9stat.mtime != -1) { +ts[1].tv_sec = v9stat.mtime; +ts[1].tv_nsec = 0; +} else { +ts[1].tv_nsec = UTIME_OMIT; +} + +return s->ops->utimensat(&s->ctx, path->data, ts); } static int v9fs_do_remove(V9fsState *s, V9fsString *path) @@ -2184,11 +2199,8 @@ static void v9fs_wstat_post_chmod(V9fsState *s, V9fsWstatState *vs, int err) goto out; } -if (vs->v9stat.mtime != -1) { -struct utimbuf tb; -tb.actime = 0; -tb.modtime = vs->v9stat.mtime; -if (v9fs_do_utime(s, &vs->fidp->path, &tb)) { +if (vs->v9stat.mtime != -1 || vs->v9stat.atime != -1) { +if (v9fs_do_utimensat(s, &vs->fidp->path, vs->v9stat)) { err = -errno; } } -- 1.6.6.1
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 08:21:30PM +, Blue Swirl wrote: > On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov wrote: > > On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote: > >> On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov wrote: > >> > On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: > >> >> >> Well, I'd like to get the test program also trigger it. Now I'm > >> >> >> getting: > >> >> >> apic: write: 0350 = > >> >> >> apic: apic_reset_irq_delivered: old coalescing 0 > >> >> >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> >> >> apic: apic_set_irq: coalescing 1 > >> >> >> apic: apic_get_irq_delivered: returning coalescing 1 > >> >> >> apic: apic_reset_irq_delivered: old coalescing 1 > >> >> >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> >> >> apic: apic_set_irq: coalescing 0 > >> >> >> apic: apic_get_irq_delivered: returning coalescing 0 > >> >> >> apic: apic_reset_irq_delivered: old coalescing 0 > >> >> >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> >> >> apic: apic_set_irq: coalescing 0 > >> >> >> > >> > So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns > >> > 0 it means the interrupt was not delivered. > >> > >> That seems strange. I changed the program so that the handler gets > >> executed, also output a dot to serial from the handler. I changed the > >> frequency to 2Hz. > >> > >> Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. > >> With -rtc-td-hack, the dots come out much faster. I added > >> DEBUG_COALESCING also to RTC, with that enabled I get: > >> qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial > >> stdio > >> cmos: coalesced irqs scaled to 0 > >> cmos: coalesced irqs increased to 1 > >> cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> .cmos: injecting on ack > >> ..cmos: injecting from timer > >> .cmos: coalesced irqs increased to 2 > >> cmos: injecting on ack > >> > >> So, there are bogus injections. > > > > Looks like irr in apic is never cleared. Probably bug in userspace apic > > emulation. I'll look into it. Try to route interrupt via APIC (not ExtInt), > > or use qemu-kvm with in kernel irq chip. > > With APIC you mean Fixed? Then the IRQ is not delivered at all. You need to deliver it through IOAPIC. -- Gleb.
[Qemu-devel] What's the meaning and the functionality of the assembly instructions in the beginning of cpu_exec?
I’m working with Qemu source study, but now I have some difficulty in these assembly instructions at the beginning of cpu_exec function. My question as follows: After entering function cpu_exec, there are some assembly codes: register host_reg_t reg_AREG0 asm("ebp"); volatile host_reg_t saved_AREG0; register host_reg_t reg_AREG1 asm("ebx"); volatile host_reg_t saved_AREG1; register host_reg_t reg_AREG2 asm("esi"); volatile host_reg_t saved_AREG2; register host_reg_t reg_AREG3 asm("edi"); volatile host_reg_t saved_AREG3; and there is also: __asm__ __volatile__ ("" : "=r" (reg_AREG0)); saved_AREG0 = reg_AREG0; __asm__ __volatile__ ("" : "=r" (reg_AREG1)); saved_AREG1 = reg_AREG1; __asm__ __volatile__ ("" : "=r" (reg_AREG2)); saved_AREG2 = reg_AREG2; __asm__ __volatile__ ("" : "=r" (reg_AREG3)); saved_AREG3 = reg_AREG3; Where are variables: reg_AREG-, saved_AREG- defined and how they are used in the later codes? I really understand these assembly codes’ functionality. Do they use for Qemu virtual register mapping or translating optimization? Could anyone give me some advise, thank. Thank you very much for your help.
Re: [Qemu-devel] Re: [PATCH v2] pci-hotplug: make them aware of pci domain.
On Sun, May 30, 2010 at 06:48:03PM +0300, Michael S. Tsirkin wrote: > On Fri, May 28, 2010 at 06:30:46PM +0900, Isaku Yamahata wrote: > > add helper function which converts root bus to pci domain. > > make them aware of pci domain. > > > > Signed-off-by: Isaku Yamahata > > Doesn't seem to apply to master. Do you mean master == pci branch of git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git Here is the version rebased to 4cecb52f3370d9c1a4251eef7c9331253c9f9719 of the branch. The previous one applies to the change set of aa6f63fff62faf2fe9ffba5a789675d49293614d in qemu.org main branch which does include 6c6a58aee425338bf67ec8faffdcda56b0b82090, but the pci branch doesn't include it. >From 389ec34a80d2630ff4ad3e491328c2e1fb53be6f Mon Sep 17 00:00:00 2001 Message-Id: <389ec34a80d2630ff4ad3e491328c2e1fb53be6f.1275273565.git.yamah...@valinux.co.jp> In-Reply-To: References: From: Isaku Yamahata Date: Mon, 31 May 2010 11:32:52 +0900 Subject: [PATCH] pci-hotplug: make them aware of pci domain. add helper function which converts root bus to pci domain. make them aware of pci domain. Signed-off-by: Isaku Yamahata --- Changes: V1 -> V2 - removed pci_find_bus() - renamed pci_find_bus_by_bus() to pci_find_bus() - add abort() --- hw/pci-hotplug.c |9 + hw/pci.c | 22 +- hw/pci.h |1 + 3 files changed, 27 insertions(+), 5 deletions(-) diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c index cc45c50..9c7161b 100644 --- a/hw/pci-hotplug.c +++ b/hw/pci-hotplug.c @@ -125,7 +125,7 @@ void drive_hot_add(Monitor *mon, const QDict *qdict) if (pci_read_devaddr(mon, pci_addr, &dom, &pci_bus, &slot)) { goto err; } -dev = pci_find_device(pci_find_root_bus(0), pci_bus, slot, 0); +dev = pci_find_device(pci_find_root_bus(dom), pci_bus, slot, 0); if (!dev) { monitor_printf(mon, "no pci device with address %s\n", pci_addr); goto err; @@ -283,8 +283,9 @@ int pci_device_hot_add(Monitor *mon, const QDict *qdict, QObject **ret_data) if (dev) { *ret_data = -qobject_from_jsonf("{ 'domain': 0, 'bus': %d, 'slot': %d, " - "'function': %d }", pci_bus_num(dev->bus), +qobject_from_jsonf("{ 'domain': %d, 'bus': %d, 'slot': %d, " + "'function': %d }", + pci_find_domain(dev->bus), pci_bus_num(dev->bus), PCI_SLOT(dev->devfn), PCI_FUNC(dev->devfn)); } else { monitor_printf(mon, "failed to add %s\n", opts); @@ -305,7 +306,7 @@ int pci_device_hot_remove(Monitor *mon, const char *pci_addr) return -1; } -d = pci_find_device(pci_find_root_bus(0), bus, slot, 0); +d = pci_find_device(pci_find_root_bus(dom), bus, slot, 0); if (!d) { monitor_printf(mon, "slot %d empty\n", slot); return -1; diff --git a/hw/pci.c b/hw/pci.c index 3362842..f084cc0 100644 --- a/hw/pci.c +++ b/hw/pci.c @@ -200,6 +200,26 @@ PCIBus *pci_find_root_bus(int domain) return NULL; } +int pci_find_domain(const PCIBus *bus) +{ +PCIDevice *d; +struct PCIHostBus *host; + +/* obtain root bus */ +while ((d = bus->parent_dev) != NULL) { +bus = d->bus; +} + +QLIST_FOREACH(host, &host_buses, next) { +if (host->bus == bus) { +return host->domain; +} +} + +abort();/* should not be reached */ +return -1; +} + void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent, const char *name, int devfn_min) { @@ -505,7 +525,7 @@ PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr) } *devfnp = slot << 3; -return pci_find_bus(pci_find_root_bus(0), bus); +return pci_find_bus(pci_find_root_bus(dom), bus); } static void pci_init_cmask(PCIDevice *dev) diff --git a/hw/pci.h b/hw/pci.h index b803593..3a15bd4 100644 --- a/hw/pci.h +++ b/hw/pci.h @@ -218,6 +218,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char *default_model, int pci_bus_num(PCIBus *s); void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, PCIDevice *d)); PCIBus *pci_find_root_bus(int domain); +int pci_find_domain(const PCIBus *bus); PCIBus *pci_find_bus(PCIBus *bus, int bus_num); PCIDevice *pci_find_device(PCIBus *bus, int bus_num, int slot, int function); PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr); -- 1.6.6.1 -- yamahata
[Qemu-devel] [PATCH 2/2] [scsi-bus]: Add MAINTENANCE_IN and MAINTENANCE_OUT case for SCSIRequest xfer and xfer_mode setup
From: Nicholas Bellinger This patch updates hw/scsi-bus.c to add MAINTENANCE_IN and MAINTENANCE_OUT case in scsi_req_length() to extra the incoming buffer length into SCSIRequest->cmd.xfer, and adds a second MAINTENANCE_OUT case in scsi_req_xfer_mode() in order to properly set SCSI_XFER_TO_DEV for WRITE data. Tested with Linux KVM guests and Megasas 8708EM2 HBA emulation and TCM_Loop target ports. Signed-off-by: Nicholas A. Bellinger --- hw/scsi-bus.c | 14 ++ hw/scsi-defs.h |2 ++ 2 files changed, 16 insertions(+), 0 deletions(-) diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c index 75ec74e..7d80405 100644 --- a/hw/scsi-bus.c +++ b/hw/scsi-bus.c @@ -329,6 +329,17 @@ static int scsi_req_length(SCSIRequest *req, uint8_t *cmd) case PERSISTENT_RESERVE_IN: req->cmd.xfer = cmd[8] | (cmd[7] << 8); break; +case MAINTENANCE_OUT: +case MAINTENANCE_IN: +if (req->dev->type != TYPE_ROM) { +/* Used for MI_REPORT_TARGET_PGS, MO_SET_TARGET_PGS et al. */ +req->cmd.xfer = cmd[9] | (cmd[8] << 8) | +(cmd[7] << 16) | (cmd[6] << 24); +} else { +/* GPCMD_REPORT_KEY and GPCMD_SEND_KEY from multi media commands */ +req->cmd.xfer = cmd[9] | (cmd[8] << 8); +} +break; } return 0; } @@ -394,6 +405,7 @@ static void scsi_req_xfer_mode(SCSIRequest *req) case SEND_VOLUME_TAG: case WRITE_LONG_2: case PERSISTENT_RESERVE_OUT: +case MAINTENANCE_OUT: req->cmd.mode = SCSI_XFER_TO_DEV; break; default: @@ -539,6 +551,8 @@ const char *scsi_command_name(uint8_t cmd) [ SPACE] = "SPACE", [ INQUIRY ] = "INQUIRY", [ RECOVER_BUFFERED_DATA] = "RECOVER_BUFFERED_DATA", +[ MAINTENANCE_IN ] = "MAINTENANCE_IN", +[ MAINTENANCE_OUT ] = "MAINTENANCE_OUT", [ MODE_SELECT ] = "MODE_SELECT", [ RESERVE ] = "RESERVE", [ RELEASE ] = "RELEASE", diff --git a/hw/scsi-defs.h b/hw/scsi-defs.h index 5890094..a4a3518 100644 --- a/hw/scsi-defs.h +++ b/hw/scsi-defs.h @@ -84,6 +84,8 @@ #define MODE_SENSE_10 0x5a #define PERSISTENT_RESERVE_IN 0x5e #define PERSISTENT_RESERVE_OUT 0x5f +#define MAINTENANCE_IN0xa3 +#define MAINTENANCE_OUT 0xa4 #define MOVE_MEDIUM 0xa5 #define READ_12 0xa8 #define WRITE_12 0xaa -- 1.5.6.5
[Qemu-devel] [PATCH 1/2] [scsi-bus]: Add PR-OUT and PR-IN case for SCSIRequest xfer and xfer_mode setup
From: Nicholas Bellinger This patch updates hw/scsi-bus.c to add PERSISTENT_RESERVE_OUT and PERSISTENT_RESERVE_IN case in scsi_req_length() to extra the incoming buffer length into SCSIRequest->cmd.xfer, and adds a second PERSISTENT_RESERVE_OUT case in scsi_req_xfer_mode() in order to properly set SCSI_XFER_TO_DEV for WRITE data. Tested with Linux KVM guests and Megasas 8708EM2 HBA emulation and TCM_Loop target ports. Signed-off-by: Nicholas A. Bellinger --- hw/scsi-bus.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c index b8e4b71..75ec74e 100644 --- a/hw/scsi-bus.c +++ b/hw/scsi-bus.c @@ -325,6 +325,10 @@ static int scsi_req_length(SCSIRequest *req, uint8_t *cmd) case INQUIRY: req->cmd.xfer = cmd[4] | (cmd[3] << 8); break; +case PERSISTENT_RESERVE_OUT: +case PERSISTENT_RESERVE_IN: +req->cmd.xfer = cmd[8] | (cmd[7] << 8); +break; } return 0; } @@ -389,6 +393,7 @@ static void scsi_req_xfer_mode(SCSIRequest *req) case MEDIUM_SCAN: case SEND_VOLUME_TAG: case WRITE_LONG_2: +case PERSISTENT_RESERVE_OUT: req->cmd.mode = SCSI_XFER_TO_DEV; break; default: -- 1.5.6.5
[Qemu-devel] [PATCH 0/2] Setup scsi-bus xfer and xfer_mode for PR IN/OUT and Maintenance IN/OUT
From: Nicholas Bellinger Greetings Gerd, Kevin and Co, Attached are two patches to add the necesary CDB parsing to determine SCSIRequest->cmd.xfer (length) and SCSIRequest->cmd.mode (direction) for Persistent Reservation IN/OUT CDBs and for Maintenance IN/OUT CDBs used for Asymmetric Logical Unit Access, et al. There is a special case for the latter Maintenance CDBs with TYPE_ROM that has been included in scsi_req_length(). Also, I should mention this is a temporary measure in order to ensure that we can actually do passthrough of these CDBs into KVM Guest for lsi and megaraid HBA emulation. What will need to eventually happen is to get rid of scsi_req_xfer_mode() all together and just setup SCSIRequest->cmd.mode based on CDB type in scsi_req_length(), instead of having to have another switch(cdb[0]) statement for every SCSI WRITE CDB on the planet to set SCSI_XFER_TO_DEV. Anyways, I will look at doing this conversion in scsi_req_length() at some point, but please apply these for the moment so folks can get access to their SPC-4 Port LUNs with QEMU. ;) Best, --nab Nicholas Bellinger (2): [scsi-bus]: Add PR-OUT and PR-IN case for SCSIRequest xfer and xfer_mode setup [scsi-bus]: Add MAINTENANCE_IN and MAINTENANCE_OUT case for SCSIRequest xfer and xfer_mode setup hw/scsi-bus.c | 19 +++ hw/scsi-defs.h |2 ++ 2 files changed, 21 insertions(+), 0 deletions(-)
[Qemu-devel] [PATCH] sparc32 esp fix spurious interrupts in chip reset
lower interrupt during chip reset. Otherwise the ESP_RSTAT register may get out of sync with the IRQ line status. This effect became visible after commit 65899fe3 Signed-off-by: Artyom Tarasenko --- hw/esp.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/esp.c b/hw/esp.c index 0a8cf6e..0532c67 100644 --- a/hw/esp.c +++ b/hw/esp.c @@ -423,6 +423,7 @@ static void esp_reset(DeviceState *d) { ESPState *s = container_of(d, ESPState, busdev.qdev); +esp_lower_irq(s); memset(s->rregs, 0, ESP_REGS); memset(s->wregs, 0, ESP_REGS); s->rregs[ESP_TCHI] = TCHI_FAS100A; // Indicate fas100a -- 1.6.2.5
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 8:07 PM, Gleb Natapov wrote: > On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote: >> On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov wrote: >> > On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: >> >> >> Well, I'd like to get the test program also trigger it. Now I'm >> >> >> getting: >> >> >> apic: write: 0350 = >> >> >> apic: apic_reset_irq_delivered: old coalescing 0 >> >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> >> apic: apic_set_irq: coalescing 1 >> >> >> apic: apic_get_irq_delivered: returning coalescing 1 >> >> >> apic: apic_reset_irq_delivered: old coalescing 1 >> >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> >> apic: apic_set_irq: coalescing 0 >> >> >> apic: apic_get_irq_delivered: returning coalescing 0 >> >> >> apic: apic_reset_irq_delivered: old coalescing 0 >> >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> >> apic: apic_set_irq: coalescing 0 >> >> >> >> > So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns >> > 0 it means the interrupt was not delivered. >> >> That seems strange. I changed the program so that the handler gets >> executed, also output a dot to serial from the handler. I changed the >> frequency to 2Hz. >> >> Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. >> With -rtc-td-hack, the dots come out much faster. I added >> DEBUG_COALESCING also to RTC, with that enabled I get: >> qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial >> stdio >> cmos: coalesced irqs scaled to 0 >> cmos: coalesced irqs increased to 1 >> cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> .cmos: injecting on ack >> ..cmos: injecting from timer >> .cmos: coalesced irqs increased to 2 >> cmos: injecting on ack >> >> So, there are bogus injections. > > Looks like irr in apic is never cleared. Probably bug in userspace apic > emulation. I'll look into it. Try to route interrupt via APIC (not ExtInt), > or use qemu-kvm with in kernel irq chip. With APIC you mean Fixed? Then the IRQ is not delivered at all.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 07:37:59PM +, Blue Swirl wrote: > On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov wrote: > > On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: > >> >> Well, I'd like to get the test program also trigger it. Now I'm getting: > >> >> apic: write: 0350 = > >> >> apic: apic_reset_irq_delivered: old coalescing 0 > >> >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> >> apic: apic_set_irq: coalescing 1 > >> >> apic: apic_get_irq_delivered: returning coalescing 1 > >> >> apic: apic_reset_irq_delivered: old coalescing 1 > >> >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> >> apic: apic_set_irq: coalescing 0 > >> >> apic: apic_get_irq_delivered: returning coalescing 0 > >> >> apic: apic_reset_irq_delivered: old coalescing 0 > >> >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> >> apic: apic_set_irq: coalescing 0 > >> >> > > So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns > > 0 it means the interrupt was not delivered. > > That seems strange. I changed the program so that the handler gets > executed, also output a dot to serial from the handler. I changed the > frequency to 2Hz. > > Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. > With -rtc-td-hack, the dots come out much faster. I added > DEBUG_COALESCING also to RTC, with that enabled I get: > qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial > stdio > cmos: coalesced irqs scaled to 0 > cmos: coalesced irqs increased to 1 > cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > .cmos: injecting on ack > ..cmos: injecting from timer > .cmos: coalesced irqs increased to 2 > cmos: injecting on ack > > So, there are bogus injections. Looks like irr in apic is never cleared. Probably bug in userspace apic emulation. I'll look into it. Try to route interrupt via APIC (not ExtInt), or use qemu-kvm with in kernel irq chip. -- Gleb.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov wrote: > On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: >> >> Well, I'd like to get the test program also trigger it. Now I'm getting: >> >> apic: write: 0350 = >> >> apic: apic_reset_irq_delivered: old coalescing 0 >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> apic: apic_set_irq: coalescing 1 >> >> apic: apic_get_irq_delivered: returning coalescing 1 >> >> apic: apic_reset_irq_delivered: old coalescing 1 >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> apic: apic_set_irq: coalescing 0 >> >> apic: apic_get_irq_delivered: returning coalescing 0 >> >> apic: apic_reset_irq_delivered: old coalescing 0 >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> apic: apic_set_irq: coalescing 0 >> >> > So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns > 0 it means the interrupt was not delivered. That seems strange. I changed the program so that the handler gets executed, also output a dot to serial from the handler. I changed the frequency to 2Hz. Now, if I leave out -rtc-td-hack, I get the dots at 2Hz as expected. With -rtc-td-hack, the dots come out much faster. I added DEBUG_COALESCING also to RTC, with that enabled I get: qemu -L . -bios coalescing.bin -d in_asm,int -no-hpet -rtc-td-hack -serial stdio cmos: coalesced irqs scaled to 0 cmos: coalesced irqs increased to 1 cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack .cmos: injecting on ack ..cmos: injecting from timer .cmos: coalesced irqs increased to 2 cmos: injecting on ack So, there are bogus injections. coalescing.S Description: Binary data coalescing.bin.bz2 Description: BZip2 compressed data
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 06:19:40PM +, Blue Swirl wrote: > On Sun, May 30, 2010 at 6:05 PM, Michael S. Tsirkin wrote: > > On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: > >> On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin > >> wrote: > >> > The following changes since commit > >> > 259d5577ae546de27e25a40710f81aa031660de8: > >> > > >> > lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 > >> > +0200) > >> > > >> > are available in the git repository at: > >> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci > >> > > >> > Isaku Yamahata (4): > >> > pci: clean up of pci_set_default_subsystem_id(). > >> > pci: add const to pci_is_express(), pci_config_size(). > >> > pci.h: remove unused constants. > >> > msix: remove duplicated defines. > >> > > >> > Michael S. Tsirkin (1): > >> > vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 > >> > >> Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. > > > > Did you follow the discussion about that patch before applying? > > 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense > > to me, I think it should be reverted. > > we have long long value, let us just print with %ll. > > casting to uint64 and printing with PRi64 is silly. > > We have PRI*64 just for this purpose, so let's use them. The > discussion about that was earlier. Ho hum. As long as enough people got annoyed, there was hope that debian will upodate their mingw port. I guess if everyone works around this in code no one'll bother. Oh well, not important enough to care. -- MST
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 6:58 PM, Michael S. Tsirkin wrote: > On Sun, May 30, 2010 at 06:19:40PM +, Blue Swirl wrote: >> On Sun, May 30, 2010 at 6:05 PM, Michael S. Tsirkin wrote: >> > On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: >> >> On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin >> >> wrote: >> >> > The following changes since commit >> >> > 259d5577ae546de27e25a40710f81aa031660de8: >> >> > >> >> > lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 >> >> > +0200) >> >> > >> >> > are available in the git repository at: >> >> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci >> >> > >> >> > Isaku Yamahata (4): >> >> > pci: clean up of pci_set_default_subsystem_id(). >> >> > pci: add const to pci_is_express(), pci_config_size(). >> >> > pci.h: remove unused constants. >> >> > msix: remove duplicated defines. >> >> > >> >> > Michael S. Tsirkin (1): >> >> > vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 >> >> >> >> Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. >> > >> > Did you follow the discussion about that patch before applying? >> > 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense >> > to me, I think it should be reverted. >> > we have long long value, let us just print with %ll. >> > casting to uint64 and printing with PRi64 is silly. >> >> We have PRI*64 just for this purpose, so let's use them. The >> discussion about that was earlier. > > Ho hum. As long as enough people got annoyed, there was hope that > debian will upodate their mingw port. I guess if everyone works around > this in code no one'll bother. Oh well, not important enough to care. To make things even more annoying, mingw gcc from Debian stable (4.2.1-sjlj) gives no warnings, the warnings came from the updated compiler (4.4.2) of the future release. So we'll be stuck with the warnings for a looong time. :-(
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 6:05 PM, Michael S. Tsirkin wrote: > On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: >> On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin wrote: >> > The following changes since commit >> > 259d5577ae546de27e25a40710f81aa031660de8: >> > >> > lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 >> > +0200) >> > >> > are available in the git repository at: >> > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci >> > >> > Isaku Yamahata (4): >> > pci: clean up of pci_set_default_subsystem_id(). >> > pci: add const to pci_is_express(), pci_config_size(). >> > pci.h: remove unused constants. >> > msix: remove duplicated defines. >> > >> > Michael S. Tsirkin (1): >> > vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 >> >> Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. > > Did you follow the discussion about that patch before applying? > 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense > to me, I think it should be reverted. > we have long long value, let us just print with %ll. > casting to uint64 and printing with PRi64 is silly. We have PRI*64 just for this purpose, so let's use them. The discussion about that was earlier.
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 04:56:11PM +, Blue Swirl wrote: > On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin wrote: > > The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: > > > > lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 > > +0200) > > > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci > > > > Isaku Yamahata (4): > > pci: clean up of pci_set_default_subsystem_id(). > > pci: add const to pci_is_express(), pci_config_size(). > > pci.h: remove unused constants. > > msix: remove duplicated defines. > > > > Michael S. Tsirkin (1): > > vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 > > Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb. Did you follow the discussion about that patch before applying? 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb does not make sense to me, I think it should be reverted. we have long long value, let us just print with %ll. casting to uint64 and printing with PRi64 is silly. -- MST
Re: [Qemu-devel] [PULL] pci, vhost fixes
On Sun, May 30, 2010 at 3:50 PM, Michael S. Tsirkin wrote: > The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: > > lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci > > Isaku Yamahata (4): > pci: clean up of pci_set_default_subsystem_id(). > pci: add const to pci_is_express(), pci_config_size(). > pci.h: remove unused constants. > msix: remove duplicated defines. > > Michael S. Tsirkin (1): > vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 Nack, see 29f91781bd300b228d9c38b9f6c1e0b6a38f25fb.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 1:49 PM, Gleb Natapov wrote: > On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: >> >> Well, I'd like to get the test program also trigger it. Now I'm getting: >> >> apic: write: 0350 = >> >> apic: apic_reset_irq_delivered: old coalescing 0 >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> apic: apic_set_irq: coalescing 1 >> >> apic: apic_get_irq_delivered: returning coalescing 1 >> >> apic: apic_reset_irq_delivered: old coalescing 1 >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> apic: apic_set_irq: coalescing 0 >> >> apic: apic_get_irq_delivered: returning coalescing 0 >> >> apic: apic_reset_irq_delivered: old coalescing 0 >> >> apic: apic_local_deliver: vector 3 delivery mode 0 >> >> apic: apic_set_irq: coalescing 0 >> >> > So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns > 0 it means the interrupt was not delivered. > >> >> It looks like some other IRQs cause the coalescing, because also >> >> looking at RTC code, it seems it's not possible for RTC to raise the >> >> IRQ (except update IRQ, alarm etc.) without calling >> >> apic_reset_irq_delivered(). >> >> >> >> I've attached my test program. Compile: >> >> gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T >> >> coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin >> >> >> >> Run: >> >> qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack >> >> >> > The application does not work for me. Looks like it fails to enter >> > protected mode. $pc jumps from 0xfff0 to 0x000f003e >> > and back. >> >> Strange. Here's a working binary. >> > Your binary works here too. What compiler are you using? Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1)
[Qemu-devel] [PATCH] [virtio-9p] Server side implementation for TLINK
Create a link. SYNOPSIS size[4] Tlink tag[2] dfid[4] oldpath[s] newpath[s] size[4] Rlink tag[2] DESCRIPTION Create a link 'newpath' in directory pointed by dfid linking to oldpath. Signed-off-by: Venkateswararao Jujjuri --- hw/file-op-9p.h |2 +- hw/virtio-9p-debug.c |9 + hw/virtio-9p-local.c |2 +- hw/virtio-9p.c | 40 hw/virtio-9p.h |2 ++ 5 files changed, 45 insertions(+), 10 deletions(-) diff --git a/hw/file-op-9p.h b/hw/file-op-9p.h index b3a320c..6744d69 100644 --- a/hw/file-op-9p.h +++ b/hw/file-op-9p.h @@ -55,7 +55,7 @@ typedef struct FileOperations int (*utime)(FsContext *, const char *, const struct utimbuf *); int (*remove)(FsContext *, const char *); int (*symlink)(FsContext *, const char *, const char *, FsCred *); -int (*link)(FsContext *, const char *, const char *, FsCred *); +int (*link)(FsContext *, const char *, const char *); int (*setuid)(FsContext *, uid_t); int (*close)(FsContext *, int); int (*closedir)(FsContext *, DIR *); diff --git a/hw/virtio-9p-debug.c b/hw/virtio-9p-debug.c index a82b771..a870b97 100644 --- a/hw/virtio-9p-debug.c +++ b/hw/virtio-9p-debug.c @@ -463,6 +463,15 @@ void pprint_pdu(V9fsPDU *pdu) case P9_RCLUNK: fprintf(llogfile, "RCLUNK: ("); break; +case P9_TLINK: +fprintf(llogfile, "TLINK: ("); +pprint_int32(pdu, 0, &offset, "fid"); +pprint_str(pdu, 0, &offset, ", name"); +pprint_str(pdu, 0, &offset, ", linkname"); +break; +case P9_RLINK: +fprintf(llogfile, "RLINK: ("); +break; case P9_TREMOVE: fprintf(llogfile, "TREMOVE: ("); pprint_int32(pdu, 0, &offset, "fid"); diff --git a/hw/virtio-9p-local.c b/hw/virtio-9p-local.c index c5678ae..fa8d05c 100644 --- a/hw/virtio-9p-local.c +++ b/hw/virtio-9p-local.c @@ -375,7 +375,7 @@ err_end: } static int local_link(FsContext *fs_ctx, const char *oldpath, -const char *newpath, FsCred *credp) +const char *newpath) { char *tmp = qemu_strdup(rpath(fs_ctx, oldpath)); int err; diff --git a/hw/virtio-9p.c b/hw/virtio-9p.c index 097dce8..d36d206 100644 --- a/hw/virtio-9p.c +++ b/hw/virtio-9p.c @@ -212,14 +212,9 @@ static int v9fs_do_symlink(V9fsState *s, V9fsCreateState *vs) &cred); } -static int v9fs_do_link(V9fsState *s, V9fsFidState *nfidp, V9fsCreateState *vs) +static int v9fs_do_link(V9fsState *s, char *oldpath, char *fullname) { -FsCred cred; -cred_init(&cred); -cred.fc_uid = nfidp->uid; -cred.fc_mode = vs->perm & 0777; - -return s->ops->link(&s->ctx, nfidp->path.data, vs->fullname.data, &cred); +return s->ops->link(&s->ctx, oldpath, fullname); } static int v9fs_do_truncate(V9fsState *s, V9fsString *path, off_t size) @@ -1919,7 +1914,7 @@ static void v9fs_create_post_lstat(V9fsState *s, V9fsCreateState *vs, int err) err = -errno; v9fs_post_create(s, vs, err); } -err = v9fs_do_link(s, nfidp, vs); +err = v9fs_do_link(s, nfidp->path.data, vs->fullname.data); v9fs_create_post_perms(s, vs, err); } else if (vs->perm & P9_STAT_MODE_DEVICE) { char ctype; @@ -1999,6 +1994,34 @@ out: qemu_free(vs); } +static void v9fs_link(V9fsState *s, V9fsPDU *pdu) +{ +int32_t dfid; +V9fsFidState *dfidp; +V9fsString name, fullname, oldname; +size_t offset = 7; +int err = 0; + +v9fs_string_init(&fullname); + +pdu_unmarshal(pdu, offset, "dss", &dfid, &oldname, &name); + +dfidp = lookup_fid(s, dfid); +if (dfidp == NULL) { +err = -errno; +goto out; +} + +v9fs_string_sprintf(&fullname, "%s/%s", dfidp->path.data, name.data); +err = v9fs_do_link(s, oldname.data, fullname.data); +v9fs_string_free(&fullname); + +out: +v9fs_string_free(&name); +v9fs_string_free(&oldname); +complete_pdu(s, pdu, err); +} + static void v9fs_flush(V9fsState *s, V9fsPDU *pdu) { /* A nop call with no return */ @@ -2354,6 +2377,7 @@ static pdu_handler_t *pdu_handlers[] = { [P9_TAUTH] = v9fs_auth, #endif [P9_TFLUSH] = v9fs_flush, +[P9_TLINK] = v9fs_link, [P9_TCREATE] = v9fs_create, [P9_TWRITE] = v9fs_write, [P9_TWSTAT] = v9fs_wstat, diff --git a/hw/virtio-9p.h b/hw/virtio-9p.h index 9773659..6b3d4a4 100644 --- a/hw/virtio-9p.h +++ b/hw/virtio-9p.h @@ -17,6 +17,8 @@ enum { P9_RSTATFS, P9_TREADDIR = 40, P9_RREADDIR, +P9_TLINK = 70, +P9_RLINK, P9_TVERSION = 100, P9_RVERSION, P9_TAUTH = 102, -- 1.6.5.2
[Qemu-devel] [PULL] pci, vhost fixes
The following changes since commit 259d5577ae546de27e25a40710f81aa031660de8: lsi: Fix value overflow in request tag processing (2010-05-22 15:32:32 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu.git pci Isaku Yamahata (4): pci: clean up of pci_set_default_subsystem_id(). pci: add const to pci_is_express(), pci_config_size(). pci.h: remove unused constants. msix: remove duplicated defines. Michael S. Tsirkin (1): vhost: fix build broken by 0bfcd599e3f5c5679cc7d0165a0a1822e2f60de2 hw/msix.c |8 hw/pci.c | 12 +--- hw/pci.h | 15 ++- hw/vhost_net.c |2 +- 4 files changed, 8 insertions(+), 29 deletions(-) -- MST
[Qemu-devel] Re: [PATCH v2] pci-hotplug: make them aware of pci domain.
On Fri, May 28, 2010 at 06:30:46PM +0900, Isaku Yamahata wrote: > add helper function which converts root bus to pci domain. > make them aware of pci domain. > > Signed-off-by: Isaku Yamahata Doesn't seem to apply to master. > --- > Changes: V1 -> V2 > - removed pci_find_bus() > - renamed pci_find_bus_by_bus() to pci_find_bus() > - add abort() > --- > hw/pci-hotplug.c |7 --- > hw/pci.c | 22 +- > hw/pci.h |1 + > 3 files changed, 26 insertions(+), 4 deletions(-) > > diff --git a/hw/pci-hotplug.c b/hw/pci-hotplug.c > index 37ac015..a8f3df1 100644 > --- a/hw/pci-hotplug.c > +++ b/hw/pci-hotplug.c > @@ -124,7 +124,7 @@ void drive_hot_add(Monitor *mon, const QDict *qdict) > if (pci_read_devaddr(mon, pci_addr, &dom, &pci_bus, &slot)) { > goto err; > } > -dev = pci_find_device(pci_find_root_bus(0), pci_bus, slot, 0); > +dev = pci_find_device(pci_find_root_bus(dom), pci_bus, slot, 0); > if (!dev) { > monitor_printf(mon, "no pci device with address %s\n", pci_addr); > goto err; > @@ -252,7 +252,8 @@ void pci_device_hot_add(Monitor *mon, const QDict *qdict) > > if (dev) { > monitor_printf(mon, "OK domain %d, bus %d, slot %d, function %d\n", > - 0, pci_bus_num(dev->bus), PCI_SLOT(dev->devfn), > + pci_find_domain(dev->bus), > + pci_bus_num(dev->bus), PCI_SLOT(dev->devfn), > PCI_FUNC(dev->devfn)); > } else > monitor_printf(mon, "failed to add %s\n", opts); > @@ -269,7 +270,7 @@ int pci_device_hot_remove(Monitor *mon, const char > *pci_addr) > return -1; > } > > -d = pci_find_device(pci_find_root_bus(0), bus, slot, 0); > +d = pci_find_device(pci_find_root_bus(dom), bus, slot, 0); > if (!d) { > monitor_printf(mon, "slot %d empty\n", slot); > return -1; > diff --git a/hw/pci.c b/hw/pci.c > index 39a6206..f046029 100644 > --- a/hw/pci.c > +++ b/hw/pci.c > @@ -200,6 +200,26 @@ PCIBus *pci_find_root_bus(int domain) > return NULL; > } > > +int pci_find_domain(const PCIBus *bus) > +{ > +PCIDevice *d; > +struct PCIHostBus *host; > + > +/* obtain root bus */ > +while ((d = bus->parent_dev) != NULL) { > +bus = d->bus; > +} > + > +QLIST_FOREACH(host, &host_buses, next) { > +if (host->bus == bus) { > +return host->domain; > +} > +} > + > +abort();/* should not be reached */ > +return -1; > +} > + > void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent, > const char *name, int devfn_min) > { > @@ -505,7 +525,7 @@ PCIBus *pci_get_bus_devfn(int *devfnp, const char > *devaddr) > } > > *devfnp = slot << 3; > -return pci_find_bus(pci_find_root_bus(0), bus); > +return pci_find_bus(pci_find_root_bus(dom), bus); > } > > static void pci_init_cmask(PCIDevice *dev) > diff --git a/hw/pci.h b/hw/pci.h > index b803593..3a15bd4 100644 > --- a/hw/pci.h > +++ b/hw/pci.h > @@ -218,6 +218,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, const char > *default_model, > int pci_bus_num(PCIBus *s); > void pci_for_each_device(PCIBus *bus, int bus_num, void (*fn)(PCIBus *bus, > PCIDevice *d)); > PCIBus *pci_find_root_bus(int domain); > +int pci_find_domain(const PCIBus *bus); > PCIBus *pci_find_bus(PCIBus *bus, int bus_num); > PCIDevice *pci_find_device(PCIBus *bus, int bus_num, int slot, int function); > PCIBus *pci_get_bus_devfn(int *devfnp, const char *devaddr); > -- > 1.6.6.1 > > > > -- > yamahata
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 12:56:26PM +, Blue Swirl wrote: > >> Well, I'd like to get the test program also trigger it. Now I'm getting: > >> apic: write: 0350 = > >> apic: apic_reset_irq_delivered: old coalescing 0 > >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> apic: apic_set_irq: coalescing 1 > >> apic: apic_get_irq_delivered: returning coalescing 1 > >> apic: apic_reset_irq_delivered: old coalescing 1 > >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> apic: apic_set_irq: coalescing 0 > >> apic: apic_get_irq_delivered: returning coalescing 0 > >> apic: apic_reset_irq_delivered: old coalescing 0 > >> apic: apic_local_deliver: vector 3 delivery mode 0 > >> apic: apic_set_irq: coalescing 0 > >> So interrupt is _alway_ coalesced. If apic_get_irq_delivered() returns 0 it means the interrupt was not delivered. > >> It looks like some other IRQs cause the coalescing, because also > >> looking at RTC code, it seems it's not possible for RTC to raise the > >> IRQ (except update IRQ, alarm etc.) without calling > >> apic_reset_irq_delivered(). > >> > >> I've attached my test program. Compile: > >> gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T > >> coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin > >> > >> Run: > >> qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack > >> > > The application does not work for me. Looks like it fails to enter > > protected mode. $pc jumps from 0xfff0 to 0x000f003e > > and back. > > Strange. Here's a working binary. > Your binary works here too. What compiler are you using? -- Gleb.
[Qemu-devel] Re: Qemu-devel Digest, Vol 86, Issue 533
QtEmu 1.0.5 in Linux KDuXPv1.97 , workfine. qemu-devel-requ...@nongnu.org escreveu: Send Qemu-devel mailing list submissions to qemu-devel@nongnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.nongnu.org/mailman/listinfo/qemu-devel or, via email, send a message with subject or body 'help' to qemu-devel-requ...@nongnu.org You can reach the person managing the list at qemu-devel-ow...@nongnu.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Qemu-devel digest..." Today's Topics: 1. [PATCH 2/3] qemu-thread: add cleanup_push() and cleanup_pop() (Corentin Chary) 2. (no subject) 3. [PATCH 0/3] [RFC] Threaded vnc server (Corentin Chary) 4. [PATCH 1/3] qemu-thread: add qemu_mutex/cond_destroy and qemu_mutex_exit (Corentin Chary) 5. Re: [PATCH] savevm: Really verify if a drive supports snapshots (Markus Armbruster) 6. Re: [PATCH] Name the default PCI bus "pci.0" on all architectures (Markus Armbruster) 7. (no subject) 8. Re: cg14 (Bob Breuer) -- Message: 1 Date: Sat, 29 May 2010 09:38:05 +0200 From: Corentin Chary Subject: [Qemu-devel] [PATCH 2/3] qemu-thread: add cleanup_push() and cleanup_pop() To: qemu-devel@nongnu.org Cc: Corentin Chary , Anthony Liguori ,Gautham R Shenoy , Alexander Graf , Adam Litke Message-ID: <1275118686-15649-3-git-send-email-corenti...@iksaif.net> -- Message: 2 Message-ID: These functions manipulate the calling thread's stack of thread-cancellation clean-up handlers. A clean-up handler is a function that is automatically executed when a thread is canceled [...] it might, for example, unlock a mutex so that it becomes available to other threads in the process. These two functions are implemented using macros because there is no other way to do that (pthread man, again): On Linux, the pthread_cleanup_push() and pthread_cleanup_pop() functions are implemented as macros that expand to text containing '{' and '}', respectively. This means that variables declared within the scope of paired calls to these functions will only be visible within that scope. Signed-off-by: Corentin Chary --- qemu-thread.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/qemu-thread.h b/qemu-thread.h index 19bb30c..e5006bb 100644 --- a/qemu-thread.h +++ b/qemu-thread.h @@ -41,4 +41,8 @@ void qemu_thread_self(QemuThread *thread); int qemu_thread_equal(QemuThread *thread1, QemuThread *thread2); void qemu_thread_exit(void *retval); +#define qemu_thread_cleanup_pop(execute) pthread_cleanup_pop(execute) +#define qemu_thread_cleanup_push(routine, arg) \ +pthread_cleanup_push(routine, arg) + #endif
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov : > On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote: >> >> >> You missed the key word 'stopped'. If the timer is really stopped, no >> >> >> IRQs should ever come out afterwards, just like on real HW. For the >> >> >> emulation, this means loss of ticks which should have been delivered >> >> >> before the change. >> >> >> >> >> > I haven't missed it. I describe to you reality of the situation. You >> >> > want >> >> > to change reality to be more close to what you want it to be by adding >> >> > words to my description. >> >> >> >> Quoting Jan: 'So what to do with the backlog when the timer is >> >> stopped?' I didn't add any words to your description, please be more >> >> careful with your attributions. Why do you think I want to change the >> >> reality? >> > Please refer to my words when you answer to my quote. You quoted my >> > answer to you statement: >> > Gleb only mentioned the frequency change, I thought that was not so big >> > problem. But I don't think this case should be allowed happen at all, >> > it can't exist on real HW. >> >> With 'this case' I was referring to 'case with timer stopped', not >> 'case which Gleb mentioned'. >> >> > No 'stopped' was under discussion nowhere. >> >> It's clearly written there in the sentence Jan wrote. >> > Jan, not me, but lets leave this topic alone since you agree that > stopped is just a case of frequency change anyway. > >> > FWIW 'stopped' is just a case >> > of frequency change. >> >> True. >> >> > >> >> >> >> XP frequency change isn't the same case as timer being stopped. >> >> >> > And what is the big difference exactly? >> >> Because after the timer is stopped, its extremely unrealistic to send >> any IRQs. Whereas if the frequency is changed to some other nonzero >> value, we can cheat and inject some more queued IRQs. >> > Correct, when gets disables clock source (by reset or any other means) > coalesced backlog should be forgotten. > >> Anyway, if this case is not interesting because it doesn't happen in >> real life emulation scenarios, we can forget it no matter how buggy >> the current QEMU implementation is. >> >> >> > Please just go write code, experiment, debug >> >> > and _then_ come here with design. >> >> >> >> I added some debugging to RTC, PIC and APIC. I also built a small >> >> guest in x86 assembly to test the coalescing. However, in the tests >> >> with this guest and others I noticed that the coalescing only happens >> >> in some obscure conditions. >> > So try with real guest and with real load. >> >> Well, I'd like to get the test program also trigger it. Now I'm getting: >> apic: write: 0350 = >> apic: apic_reset_irq_delivered: old coalescing 0 >> apic: apic_local_deliver: vector 3 delivery mode 0 >> apic: apic_set_irq: coalescing 1 >> apic: apic_get_irq_delivered: returning coalescing 1 >> apic: apic_reset_irq_delivered: old coalescing 1 >> apic: apic_local_deliver: vector 3 delivery mode 0 >> apic: apic_set_irq: coalescing 0 >> apic: apic_get_irq_delivered: returning coalescing 0 >> apic: apic_reset_irq_delivered: old coalescing 0 >> apic: apic_local_deliver: vector 3 delivery mode 0 >> apic: apic_set_irq: coalescing 0 >> >> It looks like some other IRQs cause the coalescing, because also >> looking at RTC code, it seems it's not possible for RTC to raise the >> IRQ (except update IRQ, alarm etc.) without calling >> apic_reset_irq_delivered(). >> >> I've attached my test program. Compile: >> gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T >> coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin >> >> Run: >> qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack >> > The application does not work for me. Looks like it fails to enter > protected mode. $pc jumps from 0xfff0 to 0x000f003e > and back. > >> >> >> >> By default the APIC's delivery method for IRQs is ExtInt and >> >> coalescing counting happens only with Fixed. This means that the guest >> >> needs to reprogram APIC. It also looks like RTC interrupts need to be >> >> triggered. But I didn't see both of these to happen simultaneously in >> >> my tests with Linux and Windows guests. Of course, -rtc-td-hack flag >> >> must be used and I also disabled HPET to be sure that RTC would be >> >> used. >> >> >> >> With DEBUG_COALESCING enabled, I just get increasing numbers for >> >> apic_irq_delivered: >> >> apic: apic_set_irq: coalescing 67123 >> >> apic: apic_set_irq: coalescing 67124 >> >> apic: apic_set_irq: coalescing 67125 >> > So have you actually used -rtc-td-hack option? I compiled head of >> > qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack >> > and I get: >> > apic: apic_reset_irq_delivered: old coalescing 3 >> > apic: apic_set_irq: coalescing 1 >> > apic: apic_get_irq_delivered: returning coalescing 1 >> > apic: apic_set_irq: coalescing 2 >> > apic: apic_set_irq: coalescing 3 >> > apic: apic_set_irq: coalescing 4 >> > apic: apic_set_irq: coal
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 12:24 PM, Jan Kiszka wrote: > Blue Swirl wrote: >>> Linux don't use RTC as time source and I don't know about BSD, so no >>> Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put >>> heavy load on the host. You can run video inside the gust to trigger >>> coalescing more easily. >> >> I don't have Windows XP, sorry. > > ReactOS [1], at least its 32-bit version, appears to use the RTC as well. I tried LiveCD and QEMU versions, both seem to hang at boot. Is that expected?
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov : > On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote: >> >> >> You missed the key word 'stopped'. If the timer is really stopped, no >> >> >> IRQs should ever come out afterwards, just like on real HW. For the >> >> >> emulation, this means loss of ticks which should have been delivered >> >> >> before the change. >> >> >> >> >> > I haven't missed it. I describe to you reality of the situation. You >> >> > want >> >> > to change reality to be more close to what you want it to be by adding >> >> > words to my description. >> >> >> >> Quoting Jan: 'So what to do with the backlog when the timer is >> >> stopped?' I didn't add any words to your description, please be more >> >> careful with your attributions. Why do you think I want to change the >> >> reality? >> > Please refer to my words when you answer to my quote. You quoted my >> > answer to you statement: >> > Gleb only mentioned the frequency change, I thought that was not so big >> > problem. But I don't think this case should be allowed happen at all, >> > it can't exist on real HW. >> >> With 'this case' I was referring to 'case with timer stopped', not >> 'case which Gleb mentioned'. >> >> > No 'stopped' was under discussion nowhere. >> >> It's clearly written there in the sentence Jan wrote. >> > Jan, not me, but lets leave this topic alone since you agree that > stopped is just a case of frequency change anyway. > >> > FWIW 'stopped' is just a case >> > of frequency change. >> >> True. >> >> > >> >> >> >> XP frequency change isn't the same case as timer being stopped. >> >> >> > And what is the big difference exactly? >> >> Because after the timer is stopped, its extremely unrealistic to send >> any IRQs. Whereas if the frequency is changed to some other nonzero >> value, we can cheat and inject some more queued IRQs. >> > Correct, when gets disables clock source (by reset or any other means) > coalesced backlog should be forgotten. > >> Anyway, if this case is not interesting because it doesn't happen in >> real life emulation scenarios, we can forget it no matter how buggy >> the current QEMU implementation is. >> >> >> > Please just go write code, experiment, debug >> >> > and _then_ come here with design. >> >> >> >> I added some debugging to RTC, PIC and APIC. I also built a small >> >> guest in x86 assembly to test the coalescing. However, in the tests >> >> with this guest and others I noticed that the coalescing only happens >> >> in some obscure conditions. >> > So try with real guest and with real load. >> >> Well, I'd like to get the test program also trigger it. Now I'm getting: >> apic: write: 0350 = >> apic: apic_reset_irq_delivered: old coalescing 0 >> apic: apic_local_deliver: vector 3 delivery mode 0 >> apic: apic_set_irq: coalescing 1 >> apic: apic_get_irq_delivered: returning coalescing 1 >> apic: apic_reset_irq_delivered: old coalescing 1 >> apic: apic_local_deliver: vector 3 delivery mode 0 >> apic: apic_set_irq: coalescing 0 >> apic: apic_get_irq_delivered: returning coalescing 0 >> apic: apic_reset_irq_delivered: old coalescing 0 >> apic: apic_local_deliver: vector 3 delivery mode 0 >> apic: apic_set_irq: coalescing 0 >> >> It looks like some other IRQs cause the coalescing, because also >> looking at RTC code, it seems it's not possible for RTC to raise the >> IRQ (except update IRQ, alarm etc.) without calling >> apic_reset_irq_delivered(). >> >> I've attached my test program. Compile: >> gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T >> coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin >> >> Run: >> qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack >> > The application does not work for me. Looks like it fails to enter > protected mode. $pc jumps from 0xfff0 to 0x000f003e > and back. Strange. Here's a working binary. > >> >> >> >> By default the APIC's delivery method for IRQs is ExtInt and >> >> coalescing counting happens only with Fixed. This means that the guest >> >> needs to reprogram APIC. It also looks like RTC interrupts need to be >> >> triggered. But I didn't see both of these to happen simultaneously in >> >> my tests with Linux and Windows guests. Of course, -rtc-td-hack flag >> >> must be used and I also disabled HPET to be sure that RTC would be >> >> used. >> >> >> >> With DEBUG_COALESCING enabled, I just get increasing numbers for >> >> apic_irq_delivered: >> >> apic: apic_set_irq: coalescing 67123 >> >> apic: apic_set_irq: coalescing 67124 >> >> apic: apic_set_irq: coalescing 67125 >> > So have you actually used -rtc-td-hack option? I compiled head of >> > qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack >> > and I get: >> > apic: apic_reset_irq_delivered: old coalescing 3 >> > apic: apic_set_irq: coalescing 1 >> > apic: apic_get_irq_delivered: returning coalescing 1 >> > apic: apic_set_irq: coalescing 2 >> > apic: apic_set_irq: coalescing 3 >> > apic: apic_set_irq: coales
Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
Avi Kivity wrote: > On 05/29/2010 11:14 AM, Jan Kiszka wrote: >>> Currently breaks down when IDs contain '/', but permitting that is a >>> bug. There may be more problems; the path lookup code is way too >>> clever. >>> >> Indeed. Less can sometimes be more. My impression is that some of the >> cleverness was motivated by lacking qtree completion for the HMP. >> > > Can we disable abbreviations for QMP and only allow them for HMP? > > We can support that by adding a hidden argument to commands specifying > whether the input comes from a human or machine. Abbreviations are > dangerous if they become ambiguous; a human can recover while a machine > can't. > Both QMP _and_ HMP suffer from ambitious and inconsistent addressing schemes. Therefore, I'm more and more in favor of [1]. We just need to add command line completion for option values, something that would be beneficial for 'drive_add file=...' as well. Jan [1] http://article.gmane.org/gmane.comp.emulators.qemu/72152 signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 12:10:16PM +, Blue Swirl wrote: > >> >> You missed the key word 'stopped'. If the timer is really stopped, no > >> >> IRQs should ever come out afterwards, just like on real HW. For the > >> >> emulation, this means loss of ticks which should have been delivered > >> >> before the change. > >> >> > >> > I haven't missed it. I describe to you reality of the situation. You want > >> > to change reality to be more close to what you want it to be by adding > >> > words to my description. > >> > >> Quoting Jan: 'So what to do with the backlog when the timer is > >> stopped?' I didn't add any words to your description, please be more > >> careful with your attributions. Why do you think I want to change the > >> reality? > > Please refer to my words when you answer to my quote. You quoted my > > answer to you statement: > > Gleb only mentioned the frequency change, I thought that was not so big > > problem. But I don't think this case should be allowed happen at all, > > it can't exist on real HW. > > With 'this case' I was referring to 'case with timer stopped', not > 'case which Gleb mentioned'. > > > No 'stopped' was under discussion nowhere. > > It's clearly written there in the sentence Jan wrote. > Jan, not me, but lets leave this topic alone since you agree that stopped is just a case of frequency change anyway. > > FWIW 'stopped' is just a case > > of frequency change. > > True. > > > > >> > >> XP frequency change isn't the same case as timer being stopped. > >> > > And what is the big difference exactly? > > Because after the timer is stopped, its extremely unrealistic to send > any IRQs. Whereas if the frequency is changed to some other nonzero > value, we can cheat and inject some more queued IRQs. > Correct, when gets disables clock source (by reset or any other means) coalesced backlog should be forgotten. > Anyway, if this case is not interesting because it doesn't happen in > real life emulation scenarios, we can forget it no matter how buggy > the current QEMU implementation is. > > >> > Please just go write code, experiment, debug > >> > and _then_ come here with design. > >> > >> I added some debugging to RTC, PIC and APIC. I also built a small > >> guest in x86 assembly to test the coalescing. However, in the tests > >> with this guest and others I noticed that the coalescing only happens > >> in some obscure conditions. > > So try with real guest and with real load. > > Well, I'd like to get the test program also trigger it. Now I'm getting: > apic: write: 0350 = > apic: apic_reset_irq_delivered: old coalescing 0 > apic: apic_local_deliver: vector 3 delivery mode 0 > apic: apic_set_irq: coalescing 1 > apic: apic_get_irq_delivered: returning coalescing 1 > apic: apic_reset_irq_delivered: old coalescing 1 > apic: apic_local_deliver: vector 3 delivery mode 0 > apic: apic_set_irq: coalescing 0 > apic: apic_get_irq_delivered: returning coalescing 0 > apic: apic_reset_irq_delivered: old coalescing 0 > apic: apic_local_deliver: vector 3 delivery mode 0 > apic: apic_set_irq: coalescing 0 > > It looks like some other IRQs cause the coalescing, because also > looking at RTC code, it seems it's not possible for RTC to raise the > IRQ (except update IRQ, alarm etc.) without calling > apic_reset_irq_delivered(). > > I've attached my test program. Compile: > gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T > coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin > > Run: > qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack > The application does not work for me. Looks like it fails to enter protected mode. $pc jumps from 0xfff0 to 0x000f003e and back. > >> > >> By default the APIC's delivery method for IRQs is ExtInt and > >> coalescing counting happens only with Fixed. This means that the guest > >> needs to reprogram APIC. It also looks like RTC interrupts need to be > >> triggered. But I didn't see both of these to happen simultaneously in > >> my tests with Linux and Windows guests. Of course, -rtc-td-hack flag > >> must be used and I also disabled HPET to be sure that RTC would be > >> used. > >> > >> With DEBUG_COALESCING enabled, I just get increasing numbers for > >> apic_irq_delivered: > >> apic: apic_set_irq: coalescing 67123 > >> apic: apic_set_irq: coalescing 67124 > >> apic: apic_set_irq: coalescing 67125 > > So have you actually used -rtc-td-hack option? I compiled head of > > qemu.git with DEBUG_COALESCING and run WindowsXP guest with -rtc-td-hack > > and I get: > > apic: apic_reset_irq_delivered: old coalescing 3 > > apic: apic_set_irq: coalescing 1 > > apic: apic_get_irq_delivered: returning coalescing 1 > > apic: apic_set_irq: coalescing 2 > > apic: apic_set_irq: coalescing 3 > > apic: apic_set_irq: coalescing 4 > > apic: apic_set_irq: coalescing 5 > > apic: apic_set_irq: coalescing 6 > > apic: apic_reset_irq_delivered: old coalescing 6 > > apic: apic_set_irq: coalescing 1 > > api
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
Blue Swirl wrote: >> Linux don't use RTC as time source and I don't know about BSD, so no >> Linux or BSD test case for you, sorry. Run WindowXP standard HAL and put >> heavy load on the host. You can run video inside the gust to trigger >> coalescing more easily. > > I don't have Windows XP, sorry. ReactOS [1], at least its 32-bit version, appears to use the RTC as well. Jan [1] http://www.reactos.org/de/download.html signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov : > On Sat, May 29, 2010 at 09:21:14PM +, Blue Swirl wrote: >> On Sat, May 29, 2010 at 4:37 PM, Gleb Natapov wrote: >> > On Sat, May 29, 2010 at 04:13:22PM +, Blue Swirl wrote: >> >> On Sat, May 29, 2010 at 2:46 PM, Gleb Natapov wrote: >> >> > On Sat, May 29, 2010 at 09:35:30AM +, Blue Swirl wrote: >> >> >> > I still don't see how the alternative is supposed to simplify our >> >> >> > life >> >> >> > or improve the efficiency of the de-coalescing workaround. It's >> >> >> > rather >> >> >> > problematic like Gleb pointed out: The de-coalescing logic needs to >> >> >> > be >> >> >> > informed about periodicity changes that can only be delivered along >> >> >> > IRQs. So what to do with the backlog when the timer is stopped? >> >> >> >> >> >> What happens with the current design? Gleb only mentioned the >> >> >> frequency change, I thought that was not so big problem. But I don't >> >> >> think this case should be allowed happen at all, it can't exist on >> >> >> real HW. >> >> >> >> >> > Hm, why it can't exist on real HW? Do simple exercise. Run WindowsXP >> >> > inside QEMU, connect with gdb to QEMU process and check what frequency >> >> > RTC configured with (hint: it will be 64Hz), now run video inside the >> >> > guest and check frequency again (hint: it will be 1Khz). >> >> >> >> You missed the key word 'stopped'. If the timer is really stopped, no >> >> IRQs should ever come out afterwards, just like on real HW. For the >> >> emulation, this means loss of ticks which should have been delivered >> >> before the change. >> >> >> > I haven't missed it. I describe to you reality of the situation. You want >> > to change reality to be more close to what you want it to be by adding >> > words to my description. >> >> Quoting Jan: 'So what to do with the backlog when the timer is >> stopped?' I didn't add any words to your description, please be more >> careful with your attributions. Why do you think I want to change the >> reality? > Please refer to my words when you answer to my quote. You quoted my > answer to you statement: > Gleb only mentioned the frequency change, I thought that was not so big > problem. But I don't think this case should be allowed happen at all, > it can't exist on real HW. With 'this case' I was referring to 'case with timer stopped', not 'case which Gleb mentioned'. > No 'stopped' was under discussion nowhere. It's clearly written there in the sentence Jan wrote. > FWIW 'stopped' is just a case > of frequency change. True. > >> >> XP frequency change isn't the same case as timer being stopped. >> > And what is the big difference exactly? Because after the timer is stopped, its extremely unrealistic to send any IRQs. Whereas if the frequency is changed to some other nonzero value, we can cheat and inject some more queued IRQs. Anyway, if this case is not interesting because it doesn't happen in real life emulation scenarios, we can forget it no matter how buggy the current QEMU implementation is. >> > Please just go write code, experiment, debug >> > and _then_ come here with design. >> >> I added some debugging to RTC, PIC and APIC. I also built a small >> guest in x86 assembly to test the coalescing. However, in the tests >> with this guest and others I noticed that the coalescing only happens >> in some obscure conditions. > So try with real guest and with real load. Well, I'd like to get the test program also trigger it. Now I'm getting: apic: write: 0350 = apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 1 apic: apic_get_irq_delivered: returning coalescing 1 apic: apic_reset_irq_delivered: old coalescing 1 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 apic: apic_get_irq_delivered: returning coalescing 0 apic: apic_reset_irq_delivered: old coalescing 0 apic: apic_local_deliver: vector 3 delivery mode 0 apic: apic_set_irq: coalescing 0 It looks like some other IRQs cause the coalescing, because also looking at RTC code, it seems it's not possible for RTC to raise the IRQ (except update IRQ, alarm etc.) without calling apic_reset_irq_delivered(). I've attached my test program. Compile: gcc -m32 -o coalescing coalescing.S -ffreestanding -nostdlib -Wl,-T coalescing.ld -g && objcopy -Obinary coalescing coalescing.bin Run: qemu -L . -bios coalescing.bin -no-hpet -rtc-td-hack >> >> By default the APIC's delivery method for IRQs is ExtInt and >> coalescing counting happens only with Fixed. This means that the guest >> needs to reprogram APIC. It also looks like RTC interrupts need to be >> triggered. But I didn't see both of these to happen simultaneously in >> my tests with Linux and Windows guests. Of course, -rtc-td-hack flag >> must be used and I also disabled HPET to be sure that RTC would be >> used. >> >> With DEBUG_COALESCING enabled, I just get increasing numbers for >> apic_irq_delivered:
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On 05/29/2010 12:15 PM, Blue Swirl wrote: This would allow counting the executed instructions and limit it. Thus we could emulate a 500MHz CPU on a 2GHz CPU more accurately. Why would you want to limit number of instruction executed by guest if CPU has nothing else to do anyway? The problem occurs not when we have spare cycles so give to a guest, but in opposite case. I think one problem is that the guest has executed too much compared to what would happen with real HW with a lesser CPU. That explains the RTC frequency reprogramming case. The root cause is that while qemu is scheduled out, the real time clock keeps ticking. Since we can't stop real time, we must compensate in other ways. So write the code and show us. You haven't show any evidence that RTC is the wrong place. RTC knows when interrupt was acknowledge to RTC, it know when clock frequency changes, it know when device reset happened. APIC knows only that interrupt was coalesced. It doesn't even know that it may be masked by a guest in IOAPIC (interrupts delivered while they are masked not considered coalesced). Oh, I thought interrupt masking was the reason for coalescing! What exactly is the reason then? The above. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On 05/28/2010 01:19 AM, Jan Kiszka wrote: Still, this does not answer: - How do you want to detect lost timer ticks? Your (and Gleb's) approach: during injection An alternative: during guest ack The normal pattern is inj/ack/inj/ack; if we see inj/inj/inj we know the guest isn't keeping up. - What subsystem(s) keeps track of the backlog? Clearly, the clock chip (hpet/rtc/pit). With the alternative approach, the clock emulation requests that acks be reported via a qemu_irq interface. - And depending on the above: How to detect at all that a specific IRQ is a timer tick? Clearly, a blocker unless the clock is responsible for timekeeping. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
On Sun, May 30, 2010 at 11:41:36AM +, Blue Swirl wrote: > >> I meant that in the scenario, the guest won't change the RTC before > >> 30Mcyc because of some built in determinism in the guest. At that > >> point, because of some reason, the change would happen. > >> > > I still don't understand what are you trying to say here. Guest changes > > frequency because of some even in the guest. It is totally independent > > of what happens in QEMUs RTC emulation. > > I'm trying to understand the order of events. In the scenario, the > order of events on real HW would be: > 10Mcyc: tick IRQ 1 > 20Mcyc: tick IRQ 2 > 30Mcyc: tick IRQ 3 > 30Mcyc: reprogram timer > 31Mcyc: tick IRQ 4 > 32Mcyc: tick IRQ 5 > 33Mcyc: tick IRQ 6 > 34Mcyc: tick IRQ 7 > > With QEMU, the order could become: > 30Mcyc: reprogram timer > 30.5Mcyc: tick IRQ 1 > 31Mcyc: tick IRQ 2 > 31.5Mcyc: tick IRQ 3 > 32Mcyc: tick IRQ 4 > 32.5Mcyc: tick IRQ 5 > 33Mcyc: tick IRQ 6 > 34Mcyc: tick IRQ 7 > > Correct? Not sure, your description is not complete. Let me try: On real HW: 10Mcyc: tick IRQ 1 -> delivered to an OS 20Mcyc: tick IRQ 2 -> delivered to an OS 30Mcyc: tick IRQ 3 -> delivered to an OS 30Mcyc: reprogram timer 31Mcyc: tick IRQ 4 -> delivered to an OS 32Mcyc: tick IRQ 5 -> delivered to an OS 33Mcyc: tick IRQ 6 -> delivered to an OS 34Mcyc: tick IRQ 7 -> delivered to an OS With QEMU: 10Mcyc: tick IRQ 1 -> coalesced 20Mcyc: tick IRQ 2 -> coalesced 30Mcyc: tick IRQ 3 -> coalesced 30Mcyc: reprogram timer 30.1Mcyc: tick IRQ 1 -> delivered to an OS 30.2Mcyc: tick IRQ 2 -> delivered to an OS 30.3Mcyc: tick IRQ 3 -> delivered to an OS 31Mcyc: tick IRQ 4 -> delivered to an OS 32Mcyc: tick IRQ 5 -> delivered to an OS 33Mcyc: tick IRQ 6 -> delivered to an OS 34Mcyc: tick IRQ 7 -> delivered to an OS -- Gleb.
Re: [Qemu-devel] Re: [RFT][PATCH 07/15] qemu_irq: Add IRQ handlers with delivery feedback
2010/5/30 Gleb Natapov : > On Sat, May 29, 2010 at 08:52:34PM +, Blue Swirl wrote: >> On Sat, May 29, 2010 at 4:32 PM, Gleb Natapov wrote: >> > On Sat, May 29, 2010 at 04:03:22PM +, Blue Swirl wrote: >> >> 2010/5/29 Gleb Natapov : >> >> > On Sat, May 29, 2010 at 09:15:11AM +, Blue Swirl wrote: >> >> >> >> There is no code, because we're still at architecture design stage. >> >> >> >> >> >> >> > Try to write test code to understand the problem better. >> >> >> >> >> >> I will. >> >> >> >> >> > Please do ASAP. This discussion shows that you don't understand what is >> >> > the >> >> > problem that we are dialing with. >> >> >> >> Which part of the problem you think I don't understand? >> >> >> > It seams to me you don't understand how Windows uses RTC for time >> > keeping and how the QEMU solves the problem today. >> >> RTC causes periodic interrupts and Windows interrupt handler >> increments jiffies, like Linux? >> > Linux does much more complicated things than that to keep time, so the > only way to fix time drift in Linux was to introduce pvclock. For Window > it is not so accurate too, since Windows can change clock frequency any > time it can't calculate time from jiffies, it needs to update clock at > each time tick. > >> >> >> >> >> >> guests could also be assisted with special handling (like >> >> >> >> >> >> win2k >> >> >> >> >> >> install hack), for example guest instructions could be counted >> >> >> >> >> >> (approximately, for example using TB size or TSC) and only >> >> >> >> >> >> inject >> >> >> >> >> >> after at least N instructions have passed. >> >> >> >> >> > Guest instructions cannot be easily counted in KVM (it can be >> >> >> >> >> > done more >> >> >> >> >> > or less reliably using perf counters, may be). >> >> >> >> >> >> >> >> >> >> Aren't there any debug registers or perf counters, which can >> >> >> >> >> generate >> >> >> >> >> an interrupt after some number of instructions have been >> >> >> >> >> executed? >> >> >> >> > Don't think debug registers have something like that and they are >> >> >> >> > available for guest use anyway. Perf counters differs greatly >> >> >> >> > from CPU >> >> >> >> > to CPU (even between two CPUs of the same manufacturer), and we >> >> >> >> > want to >> >> >> >> > keep using them for profiling guests. And I don't see what >> >> >> >> > problem it >> >> >> >> > will solve anyway that can be solved by simple delay between irq >> >> >> >> > reinjection. >> >> >> >> >> >> >> >> This would allow counting the executed instructions and limit it. >> >> >> >> Thus >> >> >> >> we could emulate a 500MHz CPU on a 2GHz CPU more accurately. >> >> >> >> >> >> >> > Why would you want to limit number of instruction executed by guest >> >> >> > if >> >> >> > CPU has nothing else to do anyway? The problem occurs not when we >> >> >> > have >> >> >> > spare cycles so give to a guest, but in opposite case. >> >> >> >> >> >> I think one problem is that the guest has executed too much compared >> >> >> to what would happen with real HW with a lesser CPU. That explains the >> >> >> RTC frequency reprogramming case. >> >> > You think wrong. The problem is exactly opposite: the guest haven't >> >> > had enough execution time between two time interrupts. I don't know what >> >> > RTC frequency reprogramming case you are talking about here. >> >> >> >> The case you told me where N pending tick IRQs exist but the guest >> >> wants to change the RTC frequency from 64Hz to 1024Hz. >> >> >> >> Let's make this more concrete. 1 GHz CPU, initially 100Hz RTC, so >> >> 10Mcycles/tick or 10ms/tick. At T = 30Mcycles, guest wants to change >> >> the frequency to 1000Hz. >> >> >> >> The problem for emulation is that for the same 3 ticks, there has been >> >> so little execution power that the ticks have been coalesced. But >> >> isn't the guest cycle count then much lower than 30Mcyc? >> >> >> >> Isn't it so that the guest must be above 30Mcyc to be able to want the >> >> change? But if we reach that point, the problem must have not been >> >> too little execution time, but too much. >> >> >> > Sorry I tried hard to understand what have you said above but failed. >> > What do you mean "to be able to want the change"? Guest sometimes wants >> > to get 64 timer interrupts per second and sometimes it wants to get 1024 >> > timer interrupt per second. It wants it not as a result of time drift or >> > anything. It's just how guest behaves. You seams to be to fixated on >> > guest frequency change. It's just something you have to take into >> > account when you reinject interrupts. >> >> I meant that in the scenario, the guest won't change the RTC before >> 30Mcyc because of some built in determinism in the guest. At that >> point, because of some reason, the change would happen. >> > I still don't understand what are you trying to say here. Guest changes > frequency because of some even in the guest. It is totally independent > of what happens in QEMUs RTC emulation
[Qemu-devel] Re: sparc mmu
On Sat, May 29, 2010 at 9:33 PM, Artyom Tarasenko wrote: > 2010/5/29 Blue Swirl : >> Robert Reif did some improvements to SuperSparc emulation, but the >> work was not finished. That should be a good starting point. > > Do you mean the last patch he sent to us or are there some earlier > unapplied patches? The last one. > The last patch _seems_ to be mainly refactoring and disabling features > which are not > presented in certain models. I might have missed something of course: > the patch is large. > > For me is also interesting what do we miss in the microSPARC implementation. > If I switch off POST (which crashes due to the known FPU problems) > LX/CX/X OBPs hang. Looks like it's expecting some interrupt (the SS-5 > OBP escapes a similar endless loop on a timer irq), but not getting > it. > Do you know anything obvious qemu is missing in LX machine? I don't have a device tree for LX, but unimplemented interrupt sources could be audio, parallel port, video, modem. Floppy may be buggy.
[Qemu-devel] Re: [PATCHv2-RFC 0/2] virtio: put last seen used index into ring itself
On Fri, May 28, 2010 at 11:56:54AM +0200, Jes Sorensen wrote: > On 05/26/10 21:50, Michael S. Tsirkin wrote: > > Here's a rewrite of the original patch with a new layout. > > I haven't tested it yet so no idea how this performs, but > > I think this addresses the cache bounce issue raised by Avi. > > Posting for early flames/comments. > > > > Generally, the Host end of the virtio ring doesn't need to see where > > Guest is up to in consuming the ring. However, to completely understand > > what's going on from the outside, this information must be exposed. > > For example, host can reduce the number of interrupts by detecting > > that the guest is currently handling previous buffers. > > > > We add a feature bit so the guest can tell the host that it's writing > > out the current value there, if it wants to use that. > > > > This differs from original approach in that the used index > > is put after avail index (they are typically written out together). > > To avoid cache bounces on descriptor access, > > and make future extensions easier, we put the ring itself at start of > > page, and move the control after it. > > Hi Michael, > > It looks pretty good to me, however one thing I have been thinking of > while reading through it: > > Rather than storing a pointer within the ring struct, pointing into a > position within the same struct. How about storing a byte offset instead > and using a cast to get to the pointer position? That would avoid the > pointer dereference, which is less effective cache wise and harder for > the CPU to predict. > > Not sure whether it really matters performance wise, just a thought. > > Cheers, > Jes I think this won't work: when PUBLUSH_USED_IDX is negotiated, the pointer is to within the ring. -- MST
Re: [Qemu-devel] Re: [PATCH 12/12] hw/omap : make local function static and remove declaration from header
Am 30.05.2010 um 12:30 schrieb Chih-Min Chao: I found i missed one line modification in this patch that produce compilation error Should i 1 re-send complete series patched 2 re-send this patch only 3 just provide a fix for it. (if they are acceptable) Committing known-broken patches is bad for bisecting, so resending a new version of the patch or the series is preferred. Andreas
[Qemu-devel] Re: [PATCH 12/12] hw/omap : make local function static and remove declaration from header
On Sat, May 29, 2010 at 1:43 AM, cmchao wrote: > > Signed-off-by: cmchao > --- > hw/omap.h | 36 > hw/omap1.c | 10 +- > hw/omap2.c |6 +++--- > 3 files changed, 8 insertions(+), 44 deletions(-) > > diff --git a/hw/omap.h b/hw/omap.h > index 34443b4..18eb72b 100644 > --- a/hw/omap.h > +++ b/hw/omap.h > @@ -108,15 +108,6 @@ struct omap_intr_handler_s > *omap2_inth_init(target_phys_addr_t base, > void omap_inth_reset(struct omap_intr_handler_s *s); > qemu_irq omap_inth_get_pin(struct omap_intr_handler_s *s, int n); > > -struct omap_prcm_s; > -struct omap_prcm_s *omap_prcm_init(struct omap_target_agent_s *ta, > -qemu_irq mpu_int, qemu_irq dsp_int, qemu_irq iva_int, > -struct omap_mpu_state_s *mpu); > - > -struct omap_sysctl_s; > -struct omap_sysctl_s *omap_sysctl_init(struct omap_target_agent_s *ta, > -omap_clk iclk, struct omap_mpu_state_s *mpu); > - > /* OMAP2 SDRAM controller */ > struct omap_sdrc_s; > struct omap_sdrc_s *omap_sdrc_init(target_phys_addr_t base); > @@ -658,34 +649,18 @@ struct omap_dma_lcd_channel_s { > # define OMAP24XX_DMA_EXT_DMAREQ5 64 > > /* omap[123].c */ > -struct omap_mpu_timer_s; > -struct omap_mpu_timer_s *omap_mpu_timer_init(target_phys_addr_t base, > -qemu_irq irq, omap_clk clk); > - > /* OMAP2 gp timer */ > struct omap_gp_timer_s; > struct omap_gp_timer_s *omap_gp_timer_init(struct omap_target_agent_s *ta, > qemu_irq irq, omap_clk fclk, omap_clk iclk); > void omap_gp_timer_reset(struct omap_gp_timer_s *s); > > -struct omap_watchdog_timer_s; > -struct omap_watchdog_timer_s *omap_wd_timer_init(target_phys_addr_t base, > -qemu_irq irq, omap_clk clk); > - > -struct omap_32khz_timer_s; > -struct omap_32khz_timer_s *omap_os_timer_init(target_phys_addr_t base, > -qemu_irq irq, omap_clk clk); > - > /* OMAP2 sysctimer */ > struct omap_synctimer_s; > struct omap_synctimer_s *omap_synctimer_init(struct omap_target_agent_s > *ta, > struct omap_mpu_state_s *mpu, omap_clk fclk, omap_clk > iclk); > void omap_synctimer_reset(struct omap_synctimer_s *s); > > -struct omap_tipb_bridge_s; > -struct omap_tipb_bridge_s *omap_tipb_bridge_init(target_phys_addr_t base, > -qemu_irq abort_irq, omap_clk clk); > - > struct omap_uart_s; > struct omap_uart_s *omap_uart_init(target_phys_addr_t base, > qemu_irq irq, omap_clk fclk, omap_clk iclk, > @@ -740,10 +715,6 @@ void omap_mcspi_attach(struct omap_mcspi_s *s, > int chipselect); > void omap_mcspi_reset(struct omap_mcspi_s *s); > > -struct omap_rtc_s; > -struct omap_rtc_s *omap_rtc_init(target_phys_addr_t base, > -qemu_irq *irq, omap_clk clk); > - > struct I2SCodec { > void *opaque; > > @@ -773,16 +744,9 @@ struct omap_mcbsp_s > *omap_mcbsp_init(target_phys_addr_t base, > qemu_irq *irq, qemu_irq *dma, omap_clk clk); > void omap_mcbsp_i2s_attach(struct omap_mcbsp_s *s, I2SCodec *slave); > > -struct omap_lpg_s; > -struct omap_lpg_s *omap_lpg_init(target_phys_addr_t base, omap_clk clk); > - > void omap_tap_init(struct omap_target_agent_s *ta, > struct omap_mpu_state_s *mpu); > > -struct omap_eac_s; > -struct omap_eac_s *omap_eac_init(struct omap_target_agent_s *ta, > -qemu_irq irq, qemu_irq *drq, omap_clk fclk, omap_clk > iclk); > - > /* omap_lcdc.c */ > struct omap_lcd_panel_s; > void omap_lcdc_reset(struct omap_lcd_panel_s *s); > diff --git a/hw/omap1.c b/hw/omap1.c > index 301eec5..e38fd83 100644 > --- a/hw/omap1.c > +++ b/hw/omap1.c > @@ -247,7 +247,7 @@ static void omap_mpu_timer_reset(struct > omap_mpu_timer_s *s) > s->it_ena = 1; > } > > -struct omap_mpu_timer_s *omap_mpu_timer_init(target_phys_addr_t base, > +static struct omap_mpu_timer_s *omap_mpu_timer_init(target_phys_addr_t > base, > qemu_irq irq, omap_clk clk) > { > int iomemtype; > @@ -371,7 +371,7 @@ static void omap_wd_timer_reset(struct > omap_watchdog_timer_s *s) > omap_timer_update(&s->timer); > } > > -struct omap_watchdog_timer_s *omap_wd_timer_init(target_phys_addr_t base, > +static struct omap_watchdog_timer_s *omap_wd_timer_init(target_phys_addr_t > base, > qemu_irq irq, omap_clk clk) > { > int iomemtype; > @@ -473,7 +473,7 @@ static void omap_os_timer_reset(struct > omap_32khz_timer_s *s) > s->timer.ar = 1; > } > > -struct omap_32khz_timer_s *omap_os_timer_init(target_phys_addr_t base, > +static struct omap_32khz_timer_s *omap_os_timer_init(target_phys_addr_t > base, > qemu_irq irq, omap_clk clk) > { > int iomemtype; > @@ -1180,7 +1180,7 @@ static void omap_tipb_bridge_reset(struct > omap_tipb_bridge_s *s) > s->enh_control = 0x000f; > } > > -struct omap_tipb_bridge_s *omap_tipb_bridge_init(target_phys_addr_t base, > +static struct omap_tipb_bridge_s *omap_tipb_bridge_init(target
Re: [Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs
On 05/28/2010 10:24 PM, Luiz Capitulino wrote: If a password is needed, we should throw an error and let the QMP client set the password and try again. It's what we do today, a password should be set with block_passwd before issuing the change command. Otherwise an error is throw. Is the password some kind of global or per-monitor property? In that case it doesn't work with parallel execution of commands; better to have a password field (or assign IDs to passwords and require a passwordid=... argument). -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: RFC: blockdev_add & friends, brief rationale, QMP docs
On 05/28/2010 09:21 PM, Markus Armbruster wrote: Summary of the host / guest split: -drive options host or guest? bus, unit, if, index, addr guest, already covered by qdev cyls, heads, secs, transguest, new qdev properties (but defaults depend on image) media guest snapshot, file, cache, aio, format host, blockdev_add options We expose some of the cache property to the guest. IMO we need the cache property to be both guest and host, with qemu bridging the impedance mismatch if needed. rerror, werror host, guest drivers will reject values they don't support Did you mean 'block format drivers will reject'? serial guest, new qdev properties readonlyboth host& guest, qdev will refuse to connect readonly host to read/ write guest QMP command docs: blockdev_add Add host block device. Arguments: - "id": the host block device's ID, must be unique (json-string) Unique in which namespace? A global ID namespace if fine. - "file": the disk image file to use (json-string, optional) - "format": disk format (json-string, optional) - Possible values: "raw", "qcow2", ... Need some way to list supported formats. - "aio": host AIO (json-string, optional) - Possible values: "threads" (default), "native" Need some way to list supported options. - "cache": host cache usage (json-string, optional) - Possible values: "writethrough" (default), "writeback", "unsafe", "none" ... - "readonly": open image read-only (json-bool, optional, default false) - "rerror": what to do on read error (json-string, optional) - Possible values: "report" (default), "ignore", "stop" ... - "werror": what to do on write error (json-string, optional) - Possible values: "enospc" (default), "report", "ignore", "stop" ... - "snapshot": enable snapshot (json-bool, optional, default false) An alternative to the "Need some way to list *" is to provide another query capability, akin to KVM_CAP_..., but I think listing is superior. Example: -> { "execute": "blockdev_add", "arguments": { "format": "raw", "id": "blk1", "file": "fedora.img" } } <- { "return": {} } Notes: (1) If argument "file" is missing, all other optional arguments must be missing as well. This defines a block device with no media inserted. (2) It's possible to list supported disk formats by running QEMU with arguments "-blockdev_add \?". Ok, so there's a partial answer here. blockdev_change --- Change host block device media. Arguments are exactly like blockdev_add. Notes: (1) If argument "file" is missing, all other optional arguments must be missing as well. This ejects the media without inserting a new one. Maybe we want an explicit blockdev_eject instead, not sure. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
On 05/29/2010 11:14 AM, Jan Kiszka wrote: Currently breaks down when IDs contain '/', but permitting that is a bug. There may be more problems; the path lookup code is way too clever. Indeed. Less can sometimes be more. My impression is that some of the cleverness was motivated by lacking qtree completion for the HMP. Can we disable abbreviations for QMP and only allow them for HMP? We can support that by adding a hidden argument to commands specifying whether the input comes from a human or machine. Abbreviations are dangerous if they become ambiguous; a human can recover while a machine can't. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus
On 05/12/2010 09:11 PM, Stefano Stabellini wrote: On Wed, 12 May 2010, Jamie Lokier wrote: Stefano Stabellini wrote: On Wed, 12 May 2010, Avi Kivity wrote: It's useful if you have a one-line horizontal pattern you want to propagate all over. It might be useful all right, but it is not entirely clear what the hardware should do in this situation from the documentation we have, and certainly the current state of the cirrus emulation code doesn't help. It's quite a reasonable thing for hardware to do, even if not documented. It would be surprising if the hardware didn't copy the one-line pattern. All right then, you convinced me :) This is my proposed solution, however it is untested with Windows NT. Signed-off-by: Stefano Stabellini --- diff --git a/hw/cirrus_vga.c b/hw/cirrus_vga.c index 9f61a01..a7f0d3c 100644 --- a/hw/cirrus_vga.c +++ b/hw/cirrus_vga.c @@ -676,15 +676,17 @@ static void cirrus_do_copy(CirrusVGAState *s, int dst, int src, int w, int h) int sx, sy; int dx, dy; int width, height; +uint32_t start_addr, line_offset, line_compare; int depth; int notify = 0; depth = s->vga.get_bpp(&s->vga) / 8; s->vga.get_resolution(&s->vga,&width,&height); +s->vga.get_offsets(&s->vga,&line_offset,&start_addr,&line_compare); /* extra x, y */ -sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth; -sy = (src / ABS(s->cirrus_blt_srcpitch)); +sx = (src % line_offset) / depth; +sy = (src / line_offset); dx = (dst % ABS(s->cirrus_blt_dstpitch)) / depth; dy = (dst / ABS(s->cirrus_blt_dstpitch)); dx/dy also need to be calculated according to line_offset. I think the rules are: if src_byte_range in screen and dst_byte_range in screen and srcpitch == dstpitch == line_offset: can use qemu_console_copy elif dst_byte_range overlaps screen: if dstpitch == line_offset: invalidate rectangle else: invalidate full screen -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH v3 04/17] qdev: Give qtree names precedence over user-assigned IDs
On 05/29/2010 11:01 AM, Markus Armbruster wrote: Jan Kiszka writes: From: Jan Kiszka As the user may specify ambiguous device IDs, let's search for their official names first before considering the user-supplied identifiers. Signed-off-by: Jan Kiszka The problem is letting the user specify ambiguous device IDs in the first place! That way is madness... Agreed, we're sowing the seeds for future problems. -- error compiling committee.c: too many arguments to function