[Qemu-devel] qemu on sparc host
Hello, I'm trying to emulate an x86 application on linux for sparc by using qemu user space emulator. However, it doesn't work correctly. Any ideas? Yours, sincerely Chen Baozi
Re: [Qemu-devel] qemu on sparc host
On Sun, Jun 13, 2010 at 7:52 AM, Chen Baozi chenba...@gmail.com wrote: Hello, I'm trying to emulate an x86 application on linux for sparc by using qemu user space emulator. However, it doesn't work correctly. Any ideas? It's hard to say on this level of information. Which x86 application? Can you provide traces (-d in_asm,out_asm -strace)?
Re: [Qemu-devel] Re: [PATCH] configure: Fix evaluation of config-host.mak in create_config
On Sat, Jun 12, 2010 at 07:57:52PM +0200, Paolo Bonzini wrote: On 06/12/2010 06:44 PM, Jan Kiszka wrote: Yes, but only for this line. What I mean is something more generic like: #*) # comment continue ;; IMO, that would only paper over suboptimally expressed patterns for the other line evaluations. Agreed. I like Jan's patch more. I have applied it. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH 15/35] tcg-s390: Query instruction extensions that are installed.
On Fri, Jun 11, 2010 at 06:13:49AM -0700, Richard Henderson wrote: On 06/11/2010 01:06 AM, Aurelien Jarno wrote: That said, all the hardware to which either I or agraf have access are the latest z10 machines. Frankly I expect that to be true of most if not all machines, since I think it's just a microcode update which everyone with an active support contract can get. FYI, that's the /proc/cpuinfo of s390 machines I have (more or less) access: features: esan3 zarch msa ldisp features: esan3 zarch stfle msa ldisp eimm dfp features: esan3 zarch stfle msa ldisp eimm dfp etf3eh highgprs Interesting that your first one doesn't have stfle. That one will have to go through the SIGILL path. I would be very interested to have you test that code path. I have tried, it correctly detects zarch and ldisp. Also, what era is that second machine without highgprs? Is it running an old kernel, or a 32-bit kernel? I have very few infos about it, it's an IBM System z10 machine running a 64-bit 2.6.26 kernel. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH v4 03/13] hpet: Silence warning on write to running main counter
From: Jan Kiszka jan.kis...@siemens.com
Setting the main counter while the HPET is enabled may not be a good
idea of the guest, but it is supported and should, thus, not spam the
host console with warnings.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 2836fb0..bcb160b 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -520,7 +520,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_COUNTER:
if (hpet_enabled()) {
-printf(qemu: Writing counter while HPET enabled!\n);
+DPRINTF(qemu: Writing counter while HPET enabled!\n);
}
s-hpet_counter =
(s-hpet_counter 0xULL) | value;
@@ -529,7 +529,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_COUNTER + 4:
if (hpet_enabled()) {
-printf(qemu: Writing counter while HPET enabled!\n);
+DPRINTF(qemu: Writing counter while HPET enabled!\n);
}
s-hpet_counter =
(s-hpet_counter 0xULL) | (((uint64_t)value) 32);
--
1.6.0.2
[Qemu-devel] [PATCH v4 00/13] HPET cleanups, fixes, enhancements
As the discussion around how to extend the IRQ framework /wrt de-coalescing or message passing support still hasn't settled yet, this series now skips the related changes, just focusing on the HPET. No further changes compared to v3. Please merge. Jan Kiszka (13): hpet: Catch out-of-bounds timer access hpet: Coding style cleanups and some refactorings hpet: Silence warning on write to running main counter hpet: Move static timer field initialization hpet: Convert to qdev hpet: Start/stop timer when HPET_TN_ENABLE is modified hpet/rtc: Rework RTC IRQ replacement by HPET hpet: Drop static state hpet: Add support for level-triggered interrupts vmstate: Add VMSTATE_STRUCT_VARRAY_UINT8 hpet: Make number of timers configurable hpet: Add MSI support monitor/QMP: Drop info hpet / query-hpet QMP/vm-info |2 +- hw/hpet.c| 580 + hw/hpet_emul.h | 46 + hw/hw.h | 10 + hw/mc146818rtc.c | 49 ++ hw/mc146818rtc.h |4 +- hw/mips_jazz.c |2 +- hw/mips_malta.c |2 +- hw/mips_r4k.c|2 +- hw/pc.c | 15 +- hw/ppc_prep.c|2 +- monitor.c| 22 -- qemu-monitor.hx | 21 -- 13 files changed, 415 insertions(+), 342 deletions(-)
[Qemu-devel] [PATCH v4 06/13] hpet: Start/stop timer when HPET_TN_ENABLE is modified
From: Jan Kiszka jan.kis...@siemens.com
We have to update the qemu timer when the per-timer enable bit is
toggled, just like for HPET_CFG_ENABLE changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 6974935..041dd84 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -430,6 +430,11 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
printf(qemu: level-triggered hpet not supported\n);
exit (-1);
}
+if (activating_bit(old_val, new_val, HPET_TN_ENABLE)) {
+hpet_set_timer(timer);
+} else if (deactivating_bit(old_val, new_val, HPET_TN_ENABLE)) {
+hpet_del_timer(timer);
+}
break;
case HPET_TN_CFG + 4: // Interrupt capabilities
DPRINTF(qemu: invalid HPET_TN_CFG+4 write\n);
--
1.6.0.2
[Qemu-devel] [PATCH v4 01/13] hpet: Catch out-of-bounds timer access
From: Jan Kiszka jan.kis...@siemens.com
Also prevent out-of-bounds write access to the timers but don't spam the
host console if it triggers.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 8729fb2..1980906 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -294,7 +294,7 @@ static uint32_t hpet_ram_readl(void *opaque,
target_phys_addr_t addr)
if (index = 0x100 index = 0x3ff) {
uint8_t timer_id = (addr - 0x100) / 0x20;
if (timer_id HPET_NUM_TIMERS - 1) {
-printf(qemu: timer id out of range\n);
+DPRINTF(qemu: timer id out of range\n);
return 0;
}
HPETTimer *timer = s-timer[timer_id];
@@ -383,6 +383,10 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
DPRINTF(qemu: hpet_ram_writel timer_id = %#x \n, timer_id);
HPETTimer *timer = s-timer[timer_id];
+if (timer_id HPET_NUM_TIMERS - 1) {
+DPRINTF(qemu: timer id out of range\n);
+return;
+}
switch ((addr - 0x100) % 0x20) {
case HPET_TN_CFG:
DPRINTF(qemu: hpet_ram_writel HPET_TN_CFG\n);
--
1.6.0.2
[Qemu-devel] [PATCH v4 05/13] hpet: Convert to qdev
From: Jan Kiszka jan.kis...@siemens.com
Register the HPET as a sysbus device and create it that way. As it can
route its IRQs to any ISA IRQ, we need to connect it to all 24 of them.
Once converted to qdev, we can move reset handler and vmstate
registration into its hands as well.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c | 43 ++-
hw/hpet_emul.h |3 ++-
hw/pc.c|7 ++-
3 files changed, 38 insertions(+), 15 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index fd7a1fd..6974935 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -29,6 +29,7 @@
#include console.h
#include qemu-timer.h
#include hpet_emul.h
+#include sysbus.h
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -54,8 +55,9 @@ typedef struct HPETTimer { /* timers */
} HPETTimer;
typedef struct HPETState {
+SysBusDevice busdev;
uint64_t hpet_offset;
-qemu_irq *irqs;
+qemu_irq irqs[HPET_NUM_IRQ_ROUTES];
HPETTimer timer[HPET_NUM_TIMERS];
/* Memory-mapped, software visible registers */
@@ -565,9 +567,9 @@ static CPUWriteMemoryFunc * const hpet_ram_write[] = {
hpet_ram_writel,
};
-static void hpet_reset(void *opaque)
+static void hpet_reset(DeviceState *d)
{
-HPETState *s = opaque;
+HPETState *s = FROM_SYSBUS(HPETState, sysbus_from_qdev(d));
int i;
static int count = 0;
@@ -600,28 +602,43 @@ static void hpet_reset(void *opaque)
count = 1;
}
-
-void hpet_init(qemu_irq *irq)
+static int hpet_init(SysBusDevice *dev)
{
+HPETState *s = FROM_SYSBUS(HPETState, dev);
int i, iomemtype;
HPETTimer *timer;
-HPETState *s;
-
-DPRINTF (hpet_init\n);
-s = qemu_mallocz(sizeof(HPETState));
+assert(!hpet_statep);
hpet_statep = s;
-s-irqs = irq;
+for (i = 0; i HPET_NUM_IRQ_ROUTES; i++) {
+sysbus_init_irq(dev, s-irqs[i]);
+}
for (i = 0; i HPET_NUM_TIMERS; i++) {
timer = s-timer[i];
timer-qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
timer-tn = i;
timer-state = s;
}
-vmstate_register(-1, vmstate_hpet, s);
-qemu_register_reset(hpet_reset, s);
+
/* HPET Area */
iomemtype = cpu_register_io_memory(hpet_ram_read,
hpet_ram_write, s);
-cpu_register_physical_memory(HPET_BASE, 0x400, iomemtype);
+sysbus_init_mmio(dev, 0x400, iomemtype);
+return 0;
}
+
+static SysBusDeviceInfo hpet_device_info = {
+.qdev.name= hpet,
+.qdev.size= sizeof(HPETState),
+.qdev.no_user = 1,
+.qdev.vmsd= vmstate_hpet,
+.qdev.reset = hpet_reset,
+.init = hpet_init,
+};
+
+static void hpet_register_device(void)
+{
+sysbus_register_withprop(hpet_device_info);
+}
+
+device_init(hpet_register_device)
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index 2f5f8ba..785f850 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -19,6 +19,8 @@
#define FS_PER_NS 100
#define HPET_NUM_TIMERS 3
+#define HPET_NUM_IRQ_ROUTES 32
+
#define HPET_CFG_ENABLE 0x001
#define HPET_CFG_LEGACY 0x002
@@ -47,7 +49,6 @@
#if defined TARGET_I386
extern uint32_t hpet_in_legacy_mode(void);
-extern void hpet_init(qemu_irq *irq);
#endif
#endif
diff --git a/hw/pc.c b/hw/pc.c
index 9b85c42..ae31e2e 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -35,6 +35,7 @@
#include elf.h
#include multiboot.h
#include mc146818rtc.h
+#include sysbus.h
/* output Bochs bios info messages */
//#define DEBUG_BIOS
@@ -957,7 +958,11 @@ void pc_basic_device_init(qemu_irq *isa_irq,
pit = pit_init(0x40, isa_reserve_irq(0));
pcspk_init(pit);
if (!no_hpet) {
-hpet_init(isa_irq);
+DeviceState *hpet = sysbus_create_simple(hpet, HPET_BASE, NULL);
+
+for (i = 0; i 24; i++) {
+sysbus_connect_irq(sysbus_from_qdev(hpet), i, isa_irq[i]);
+}
}
for(i = 0; i MAX_SERIAL_PORTS; i++) {
--
1.6.0.2
[Qemu-devel] [PATCH v4 02/13] hpet: Coding style cleanups and some refactorings
From: Jan Kiszka jan.kis...@siemens.com
This moves the private HPET structures into the C module, simplifies
some helper functions and fixes most coding style issues (biggest chunk
was improper switch-case indention). No functional changes.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
Reviewed-by: Juan Quintela quint...@redhat.com
---
hw/hpet.c | 413 ++-
hw/hpet_emul.h | 31 +
2 files changed, 226 insertions(+), 218 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 1980906..2836fb0 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -37,21 +37,47 @@
#define DPRINTF(...)
#endif
+struct HPETState;
+typedef struct HPETTimer { /* timers */
+uint8_t tn; /*timer number*/
+QEMUTimer *qemu_timer;
+struct HPETState *state;
+/* Memory-mapped, software visible timer registers */
+uint64_t config;/* configuration/cap */
+uint64_t cmp; /* comparator */
+uint64_t fsb; /* FSB route, not supported now */
+/* Hidden register state */
+uint64_t period;/* Last value written to comparator */
+uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot 32-bit
+ * mode. Next pop will be actual timer expiration.
+ */
+} HPETTimer;
+
+typedef struct HPETState {
+uint64_t hpet_offset;
+qemu_irq *irqs;
+HPETTimer timer[HPET_NUM_TIMERS];
+
+/* Memory-mapped, software visible registers */
+uint64_t capability;/* capabilities */
+uint64_t config;/* configuration */
+uint64_t isr; /* interrupt status reg */
+uint64_t hpet_counter; /* main counter */
+} HPETState;
+
static HPETState *hpet_statep;
uint32_t hpet_in_legacy_mode(void)
{
-if (hpet_statep)
-return hpet_statep-config HPET_CFG_LEGACY;
-else
+if (!hpet_statep) {
return 0;
+}
+return hpet_statep-config HPET_CFG_LEGACY;
}
static uint32_t timer_int_route(struct HPETTimer *timer)
{
-uint32_t route;
-route = (timer-config HPET_TN_INT_ROUTE_MASK)
HPET_TN_INT_ROUTE_SHIFT;
-return route;
+return (timer-config HPET_TN_INT_ROUTE_MASK) HPET_TN_INT_ROUTE_SHIFT;
}
static uint32_t hpet_enabled(void)
@@ -108,9 +134,7 @@ static int deactivating_bit(uint64_t old, uint64_t new,
uint64_t mask)
static uint64_t hpet_get_ticks(void)
{
-uint64_t ticks;
-ticks = ns_to_ticks(qemu_get_clock(vm_clock) + hpet_statep-hpet_offset);
-return ticks;
+return ns_to_ticks(qemu_get_clock(vm_clock) + hpet_statep-hpet_offset);
}
/*
@@ -121,12 +145,14 @@ static inline uint64_t hpet_calculate_diff(HPETTimer *t,
uint64_t current)
if (t-config HPET_TN_32BIT) {
uint32_t diff, cmp;
+
cmp = (uint32_t)t-cmp;
diff = cmp - (uint32_t)current;
diff = (int32_t)diff 0 ? diff : (uint32_t)0;
return (uint64_t)diff;
} else {
uint64_t diff, cmp;
+
cmp = t-cmp;
diff = cmp - current;
diff = (int64_t)diff 0 ? diff : (uint64_t)0;
@@ -136,7 +162,6 @@ static inline uint64_t hpet_calculate_diff(HPETTimer *t,
uint64_t current)
static void update_irq(struct HPETTimer *timer)
{
-qemu_irq irq;
int route;
if (timer-tn = 1 hpet_in_legacy_mode()) {
@@ -144,22 +169,20 @@ static void update_irq(struct HPETTimer *timer)
* timer0 be routed to IRQ0 in NON-APIC or IRQ2 in the I/O APIC,
* timer1 be routed to IRQ8 in NON-APIC or IRQ8 in the I/O APIC.
*/
-if (timer-tn == 0) {
-irq=timer-state-irqs[0];
-} else
-irq=timer-state-irqs[8];
+route = (timer-tn == 0) ? 0 : 8;
} else {
-route=timer_int_route(timer);
-irq=timer-state-irqs[route];
+route = timer_int_route(timer);
}
-if (timer_enabled(timer) hpet_enabled()) {
-qemu_irq_pulse(irq);
+if (!timer_enabled(timer) || !hpet_enabled()) {
+return;
}
+qemu_irq_pulse(timer-state-irqs[route]);
}
static void hpet_pre_save(void *opaque)
{
HPETState *s = opaque;
+
/* save current counter value */
s-hpet_counter = hpet_get_ticks();
}
@@ -212,7 +235,7 @@ static const VMStateDescription vmstate_hpet = {
*/
static void hpet_timer(void *opaque)
{
-HPETTimer *t = (HPETTimer*)opaque;
+HPETTimer *t = opaque;
uint64_t diff;
uint64_t period = t-period;
@@ -220,20 +243,22 @@ static void hpet_timer(void *opaque)
if (timer_is_periodic(t) period != 0) {
if (t-config HPET_TN_32BIT) {
-while (hpet_time_after(cur_tick, t-cmp))
+while (hpet_time_after(cur_tick, t-cmp)) {
t-cmp = (uint32_t)(t-cmp + t-period);
-} else
-while (hpet_time_after64(cur_tick, t-cmp))
+}
+} else {
+while (hpet_time_after64(cur_tick, t-cmp)) {
[Qemu-devel] [PATCH v4 04/13] hpet: Move static timer field initialization
From: Jan Kiszka jan.kis...@siemens.com
Properly initialize HPETTimer::tn and HPETTimer::state once during
hpet_init instead of (re-)writing them on every reset.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index bcb160b..fd7a1fd 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -575,12 +575,10 @@ static void hpet_reset(void *opaque)
HPETTimer *timer = s-timer[i];
hpet_del_timer(timer);
-timer-tn = i;
timer-cmp = ~0ULL;
timer-config = HPET_TN_PERIODIC_CAP | HPET_TN_SIZE_CAP;
/* advertise availability of ioapic inti2 */
timer-config |= 0x0004ULL 32;
-timer-state = s;
timer-period = 0ULL;
timer-wrap_flag = 0;
}
@@ -617,6 +615,8 @@ void hpet_init(qemu_irq *irq)
for (i = 0; i HPET_NUM_TIMERS; i++) {
timer = s-timer[i];
timer-qemu_timer = qemu_new_timer(vm_clock, hpet_timer, timer);
+timer-tn = i;
+timer-state = s;
}
vmstate_register(-1, vmstate_hpet, s);
qemu_register_reset(hpet_reset, s);
--
1.6.0.2
[Qemu-devel] [PATCH v4 10/13] vmstate: Add VMSTATE_STRUCT_VARRAY_UINT8
From: Jan Kiszka jan.kis...@siemens.com
Required for hpet.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hw.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index fc2d184..36be0be 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -474,6 +474,16 @@ extern const VMStateInfo vmstate_info_unused_buffer;
.offset = vmstate_offset_array(_state, _field, _type, _num), \
}
+#define VMSTATE_STRUCT_VARRAY_UINT8(_field, _state, _field_num, _version,
_vmsd, _type) { \
+.name = (stringify(_field)), \
+.num_offset = vmstate_offset_value(_state, _field_num, uint8_t), \
+.version_id = (_version),\
+.vmsd = (_vmsd), \
+.size = sizeof(_type), \
+.flags = VMS_STRUCT|VMS_VARRAY_INT32, \
+.offset = offsetof(_state, _field), \
+}
+
#define VMSTATE_STATIC_BUFFER(_field, _state, _version, _test, _start, _size)
{ \
.name = (stringify(_field)), \
.version_id = (_version), \
--
1.6.0.2
[Qemu-devel] [PATCH v4 07/13] hpet/rtc: Rework RTC IRQ replacement by HPET
From: Jan Kiszka jan.kis...@siemens.com
Allow the intercept the RTC IRQ for the HPET legacy mode. Then push
routing to IRQ8 completely into the HPET. This allows to turn
hpet_in_legacy_mode() into a private function. Furthermore, this stops
the RTC from clearing IRQ8 even if the HPET is in control.
This patch comes with a side effect: The RTC timers will no longer be
stoppend when there is no IRQ consumer, possibly causing a minor
performance degration. But as the guest may want to redirect the RTC to
the SCI in that mode, it should normally disable unused IRQ source
anyway.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c| 28 +---
hw/hpet_emul.h |4
hw/mc146818rtc.c | 49 +++--
hw/mc146818rtc.h |4 +++-
hw/mips_jazz.c |2 +-
hw/mips_malta.c |2 +-
hw/mips_r4k.c|2 +-
hw/pc.c | 14 --
hw/ppc_prep.c|2 +-
9 files changed, 51 insertions(+), 56 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 041dd84..edfe02e 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -30,6 +30,7 @@
#include qemu-timer.h
#include hpet_emul.h
#include sysbus.h
+#include mc146818rtc.h
//#define HPET_DEBUG
#ifdef HPET_DEBUG
@@ -58,6 +59,7 @@ typedef struct HPETState {
SysBusDevice busdev;
uint64_t hpet_offset;
qemu_irq irqs[HPET_NUM_IRQ_ROUTES];
+uint8_t rtc_irq_level;
HPETTimer timer[HPET_NUM_TIMERS];
/* Memory-mapped, software visible registers */
@@ -69,12 +71,9 @@ typedef struct HPETState {
static HPETState *hpet_statep;
-uint32_t hpet_in_legacy_mode(void)
+static uint32_t hpet_in_legacy_mode(HPETState *s)
{
-if (!hpet_statep) {
-return 0;
-}
-return hpet_statep-config HPET_CFG_LEGACY;
+return s-config HPET_CFG_LEGACY;
}
static uint32_t timer_int_route(struct HPETTimer *timer)
@@ -166,12 +165,12 @@ static void update_irq(struct HPETTimer *timer)
{
int route;
-if (timer-tn = 1 hpet_in_legacy_mode()) {
+if (timer-tn = 1 hpet_in_legacy_mode(timer-state)) {
/* if LegacyReplacementRoute bit is set, HPET specification requires
* timer0 be routed to IRQ0 in NON-APIC or IRQ2 in the I/O APIC,
* timer1 be routed to IRQ8 in NON-APIC or IRQ8 in the I/O APIC.
*/
-route = (timer-tn == 0) ? 0 : 8;
+route = (timer-tn == 0) ? 0 : RTC_ISA_IRQ;
} else {
route = timer_int_route(timer);
}
@@ -515,8 +514,10 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
/* i8254 and RTC are disabled when HPET is in legacy mode */
if (activating_bit(old_val, new_val, HPET_CFG_LEGACY)) {
hpet_pit_disable();
+qemu_irq_lower(s-irqs[RTC_ISA_IRQ]);
} else if (deactivating_bit(old_val, new_val, HPET_CFG_LEGACY)) {
hpet_pit_enable();
+qemu_set_irq(s-irqs[RTC_ISA_IRQ], s-rtc_irq_level);
}
break;
case HPET_CFG + 4:
@@ -607,6 +608,16 @@ static void hpet_reset(DeviceState *d)
count = 1;
}
+static void hpet_handle_rtc_irq(void *opaque, int n, int level)
+{
+HPETState *s = FROM_SYSBUS(HPETState, opaque);
+
+s-rtc_irq_level = level;
+if (!hpet_in_legacy_mode(s)) {
+qemu_set_irq(s-irqs[RTC_ISA_IRQ], level);
+}
+}
+
static int hpet_init(SysBusDevice *dev)
{
HPETState *s = FROM_SYSBUS(HPETState, dev);
@@ -625,6 +636,9 @@ static int hpet_init(SysBusDevice *dev)
timer-state = s;
}
+isa_reserve_irq(RTC_ISA_IRQ);
+qdev_init_gpio_in(dev-qdev, hpet_handle_rtc_irq, 1);
+
/* HPET Area */
iomemtype = cpu_register_io_memory(hpet_ram_read,
hpet_ram_write, s);
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index 785f850..9c268cc 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -47,8 +47,4 @@
#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
-#if defined TARGET_I386
-extern uint32_t hpet_in_legacy_mode(void);
-#endif
-
#endif
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index c3e6a70..c3459bf 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -27,7 +27,6 @@
#include pc.h
#include apic.h
#include isa.h
-#include hpet_emul.h
#include mc146818rtc.h
//#define DEBUG_CMOS
@@ -101,19 +100,6 @@ typedef struct RTCState {
QEMUTimer *second_timer2;
} RTCState;
-static void rtc_irq_raise(qemu_irq irq)
-{
-/* When HPET is operating in legacy mode, RTC interrupts are disabled
- * We block qemu_irq_raise, but not qemu_irq_lower, in case legacy
- * mode is established while interrupt is raised. We want it to
- * be lowered in any case
- */
-#if defined TARGET_I386
-if (!hpet_in_legacy_mode())
-#endif
-qemu_irq_raise(irq);
-}
-
static void rtc_set_time(RTCState *s);
static void rtc_copy_date(RTCState *s);
@@ -139,7
[Qemu-devel] [PATCH v4 09/13] hpet: Add support for level-triggered interrupts
From: Jan Kiszka jan.kis...@siemens.com
By implementing this feature we can also remove a nasty way to kill qemu
(by trying to enable level-triggered hpet interrupts).
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c | 32 ++--
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 59a06f6..f24b227 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -159,8 +159,10 @@ static inline uint64_t hpet_calculate_diff(HPETTimer *t,
uint64_t current)
}
}
-static void update_irq(struct HPETTimer *timer)
+static void update_irq(struct HPETTimer *timer, int set)
{
+uint64_t mask;
+HPETState *s;
int route;
if (timer-tn = 1 hpet_in_legacy_mode(timer-state)) {
@@ -172,10 +174,18 @@ static void update_irq(struct HPETTimer *timer)
} else {
route = timer_int_route(timer);
}
-if (!timer_enabled(timer) || !hpet_enabled(timer-state)) {
-return;
+s = timer-state;
+mask = 1 timer-tn;
+if (!set || !timer_enabled(timer) || !hpet_enabled(timer-state)) {
+s-isr = ~mask;
+qemu_irq_lower(s-irqs[route]);
+} else if (timer-config HPET_TN_TYPE_LEVEL) {
+s-isr |= mask;
+qemu_irq_raise(s-irqs[route]);
+} else {
+s-isr = ~mask;
+qemu_irq_pulse(s-irqs[route]);
}
-qemu_irq_pulse(timer-state-irqs[route]);
}
static void hpet_pre_save(void *opaque)
@@ -261,7 +271,7 @@ static void hpet_timer(void *opaque)
t-wrap_flag = 0;
}
}
-update_irq(t);
+update_irq(t, 1);
}
static void hpet_set_timer(HPETTimer *t)
@@ -291,6 +301,7 @@ static void hpet_set_timer(HPETTimer *t)
static void hpet_del_timer(HPETTimer *t)
{
qemu_del_timer(t-qemu_timer);
+update_irq(t, 0);
}
#ifdef HPET_DEBUG
@@ -423,10 +434,6 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
timer-cmp = (uint32_t)timer-cmp;
timer-period = (uint32_t)timer-period;
}
-if (new_val HPET_TN_TYPE_LEVEL) {
-printf(qemu: level-triggered hpet not supported\n);
-exit (-1);
-}
if (activating_bit(old_val, new_val, HPET_TN_ENABLE)) {
hpet_set_timer(timer);
} else if (deactivating_bit(old_val, new_val, HPET_TN_ENABLE)) {
@@ -522,7 +529,12 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
DPRINTF(qemu: invalid HPET_CFG+4 write \n);
break;
case HPET_STATUS:
-/* FIXME: need to handle level-triggered interrupts */
+val = new_val s-isr;
+for (i = 0; i HPET_NUM_TIMERS; i++) {
+if (val (1 i)) {
+update_irq(s-timer[i], 0);
+}
+}
break;
case HPET_COUNTER:
if (hpet_enabled(s)) {
--
1.6.0.2
[Qemu-devel] [PATCH v4 08/13] hpet: Drop static state
From: Jan Kiszka jan.kis...@siemens.com
Instead of keeping a static reference around, pass the state to
hpet_enabled and hpet_get_ticks. All callers now have it at hand. Will
once allow to instantiate the HPET more than a single time.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c | 38 +-
1 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index edfe02e..59a06f6 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -69,8 +69,6 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
-static HPETState *hpet_statep;
-
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
return s-config HPET_CFG_LEGACY;
@@ -81,9 +79,9 @@ static uint32_t timer_int_route(struct HPETTimer *timer)
return (timer-config HPET_TN_INT_ROUTE_MASK) HPET_TN_INT_ROUTE_SHIFT;
}
-static uint32_t hpet_enabled(void)
+static uint32_t hpet_enabled(HPETState *s)
{
-return hpet_statep-config HPET_CFG_ENABLE;
+return s-config HPET_CFG_ENABLE;
}
static uint32_t timer_is_periodic(HPETTimer *t)
@@ -133,9 +131,9 @@ static int deactivating_bit(uint64_t old, uint64_t new,
uint64_t mask)
return ((old mask) !(new mask));
}
-static uint64_t hpet_get_ticks(void)
+static uint64_t hpet_get_ticks(HPETState *s)
{
-return ns_to_ticks(qemu_get_clock(vm_clock) + hpet_statep-hpet_offset);
+return ns_to_ticks(qemu_get_clock(vm_clock) + s-hpet_offset);
}
/*
@@ -174,7 +172,7 @@ static void update_irq(struct HPETTimer *timer)
} else {
route = timer_int_route(timer);
}
-if (!timer_enabled(timer) || !hpet_enabled()) {
+if (!timer_enabled(timer) || !hpet_enabled(timer-state)) {
return;
}
qemu_irq_pulse(timer-state-irqs[route]);
@@ -185,7 +183,7 @@ static void hpet_pre_save(void *opaque)
HPETState *s = opaque;
/* save current counter value */
-s-hpet_counter = hpet_get_ticks();
+s-hpet_counter = hpet_get_ticks(s);
}
static int hpet_post_load(void *opaque, int version_id)
@@ -240,7 +238,7 @@ static void hpet_timer(void *opaque)
uint64_t diff;
uint64_t period = t-period;
-uint64_t cur_tick = hpet_get_ticks();
+uint64_t cur_tick = hpet_get_ticks(t-state);
if (timer_is_periodic(t) period != 0) {
if (t-config HPET_TN_32BIT) {
@@ -270,7 +268,7 @@ static void hpet_set_timer(HPETTimer *t)
{
uint64_t diff;
uint32_t wrap_diff; /* how many ticks until we wrap? */
-uint64_t cur_tick = hpet_get_ticks();
+uint64_t cur_tick = hpet_get_ticks(t-state);
/* whenever new timer is being set up, make sure wrap_flag is 0 */
t-wrap_flag = 0;
@@ -353,16 +351,16 @@ static uint32_t hpet_ram_readl(void *opaque,
target_phys_addr_t addr)
DPRINTF(qemu: invalid HPET_CFG + 4 hpet_ram_readl \n);
return 0;
case HPET_COUNTER:
-if (hpet_enabled()) {
-cur_tick = hpet_get_ticks();
+if (hpet_enabled(s)) {
+cur_tick = hpet_get_ticks(s);
} else {
cur_tick = s-hpet_counter;
}
DPRINTF(qemu: reading counter = % PRIx64 \n, cur_tick);
return cur_tick;
case HPET_COUNTER + 4:
-if (hpet_enabled()) {
-cur_tick = hpet_get_ticks();
+if (hpet_enabled(s)) {
+cur_tick = hpet_get_ticks(s);
} else {
cur_tick = s-hpet_counter;
}
@@ -457,7 +455,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
(timer-period 0xULL) | new_val;
}
timer-config = ~HPET_TN_SETVAL;
-if (hpet_enabled()) {
+if (hpet_enabled(s)) {
hpet_set_timer(timer);
}
break;
@@ -476,7 +474,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
(timer-period 0xULL) | new_val 32;
}
timer-config = ~HPET_TN_SETVAL;
-if (hpet_enabled()) {
+if (hpet_enabled(s)) {
hpet_set_timer(timer);
}
break;
@@ -506,7 +504,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
}
} else if (deactivating_bit(old_val, new_val, HPET_CFG_ENABLE)) {
/* Halt main counter and disable interrupt generation. */
-s-hpet_counter = hpet_get_ticks();
+s-hpet_counter = hpet_get_ticks(s);
for (i = 0; i HPET_NUM_TIMERS; i++) {
hpet_del_timer(s-timer[i]);
}
@@ -527,7 +525,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
/* FIXME: need to handle level-triggered interrupts */
break;
case HPET_COUNTER:
-
[Qemu-devel] [PATCH v4 13/13] monitor/QMP: Drop info hpet / query-hpet
From: Jan Kiszka jan.kis...@siemens.com
This command was of minimal use before, now it is useless as the hpet
become a qdev device and is thus easily discoverable. We should
definitely not set query-hpet in QMP's stone, and there is also no good
reason to keep it for the interactive monitor.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
QMP/vm-info |2 +-
monitor.c | 22 --
qemu-monitor.hx | 21 -
3 files changed, 1 insertions(+), 44 deletions(-)
diff --git a/QMP/vm-info b/QMP/vm-info
index b150d82..8ebaeb3 100755
--- a/QMP/vm-info
+++ b/QMP/vm-info
@@ -25,7 +25,7 @@ def main():
qemu = qmp.QEMUMonitorProtocol(argv[1])
qemu.connect()
-for cmd in [ 'version', 'hpet', 'kvm', 'status', 'uuid', 'balloon' ]:
+for cmd in [ 'version', 'kvm', 'status', 'uuid', 'balloon' ]:
print cmd + ': ' + str(qemu.send('query-' + cmd))
if __name__ == '__main__':
diff --git a/monitor.c b/monitor.c
index 15b53b9..14f77bd 100644
--- a/monitor.c
+++ b/monitor.c
@@ -740,20 +740,6 @@ static void do_info_commands(Monitor *mon, QObject
**ret_data)
*ret_data = QOBJECT(cmd_list);
}
-#if defined(TARGET_I386)
-static void do_info_hpet_print(Monitor *mon, const QObject *data)
-{
-monitor_printf(mon, HPET is %s by QEMU\n,
- qdict_get_bool(qobject_to_qdict(data), enabled) ?
- enabled : disabled);
-}
-
-static void do_info_hpet(Monitor *mon, QObject **ret_data)
-{
-*ret_data = qobject_from_jsonf({ 'enabled': %i }, !no_hpet);
-}
-#endif
-
static void do_info_uuid_print(Monitor *mon, const QObject *data)
{
monitor_printf(mon, %s\n, qdict_get_str(qobject_to_qdict(data), UUID));
@@ -2509,14 +2495,6 @@ static const mon_cmd_t info_cmds[] = {
.help = show the active virtual memory mappings,
.mhandler.info = mem_info,
},
-{
-.name = hpet,
-.args_type = ,
-.params = ,
-.help = show state of HPET,
-.user_print = do_info_hpet_print,
-.mhandler.info_new = do_info_hpet,
-},
#endif
{
.name = jit,
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index f6a94f2..9f62b94 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -2144,27 +2144,6 @@ show the active virtual memory mappings (i386 only)
ETEXI
STEXI
-...@item info hpet
-show state of HPET (i386 only)
-ETEXI
-SQMP
-query-hpet
---
-
-Show HPET state.
-
-Return a json-object with the following information:
-
-- enabled: true if hpet if enabled, false otherwise (json-bool)
-
-Example:
-
-- { execute: query-hpet }
-- { return: { enabled: true } }
-
-EQMP
-
-STEXI
@item info jit
show dynamic compiler info
@item info kvm
--
1.6.0.2
[Qemu-devel] [PATCH v4 12/13] hpet: Add MSI support
From: Jan Kiszka jan.kis...@siemens.com
This implements the HPET capability of routing IRQs to the front-side
bus, aka MSI support. This feature can be enabled via the qdev property
msi and is off by default.
Note that switching it on can cause guests (at least Linux) to use the
HPET as timer instead of the LAPIC. KVM users should recall that only
the latter is currently available as fast in-kernel model.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c | 38 ++
hw/hpet_emul.h |4 +++-
2 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 6187e5e..93fc399 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -39,6 +39,8 @@
#define DPRINTF(...)
#endif
+#define HPET_MSI_SUPPORT0
+
struct HPETState;
typedef struct HPETTimer { /* timers */
uint8_t tn; /*timer number*/
@@ -47,7 +49,7 @@ typedef struct HPETTimer { /* timers */
/* Memory-mapped, software visible timer registers */
uint64_t config;/* configuration/cap */
uint64_t cmp; /* comparator */
-uint64_t fsb; /* FSB route, not supported now */
+uint64_t fsb; /* FSB route */
/* Hidden register state */
uint64_t period;/* Last value written to comparator */
uint8_t wrap_flag; /* timer pop will indicate wrap for one-shot 32-bit
@@ -59,6 +61,7 @@ typedef struct HPETState {
SysBusDevice busdev;
uint64_t hpet_offset;
qemu_irq irqs[HPET_NUM_IRQ_ROUTES];
+uint32_t flags;
uint8_t rtc_irq_level;
uint8_t num_timers;
HPETTimer timer[HPET_MAX_TIMERS];
@@ -80,6 +83,11 @@ static uint32_t timer_int_route(struct HPETTimer *timer)
return (timer-config HPET_TN_INT_ROUTE_MASK) HPET_TN_INT_ROUTE_SHIFT;
}
+static uint32_t timer_fsb_route(HPETTimer *t)
+{
+return t-config HPET_TN_FSB_ENABLE;
+}
+
static uint32_t hpet_enabled(HPETState *s)
{
return s-config HPET_CFG_ENABLE;
@@ -179,7 +187,11 @@ static void update_irq(struct HPETTimer *timer, int set)
mask = 1 timer-tn;
if (!set || !timer_enabled(timer) || !hpet_enabled(timer-state)) {
s-isr = ~mask;
-qemu_irq_lower(s-irqs[route]);
+if (!timer_fsb_route(timer)) {
+qemu_irq_lower(s-irqs[route]);
+}
+} else if (timer_fsb_route(timer)) {
+stl_phys(timer-fsb 32, timer-fsb 0x);
} else if (timer-config HPET_TN_TYPE_LEVEL) {
s-isr |= mask;
qemu_irq_raise(s-irqs[route]);
@@ -216,6 +228,12 @@ static int hpet_post_load(void *opaque, int version_id)
/* Push number of timers into capability returned via HPET_ID */
s-capability = ~HPET_ID_NUM_TIM_MASK;
s-capability |= (s-num_timers - 1) HPET_ID_NUM_TIM_SHIFT;
+
+/* Derive HPET_MSI_SUPPORT from the capability of the first timer. */
+s-flags = ~(1 HPET_MSI_SUPPORT);
+if (s-timer[0].config HPET_TN_FSB_CAP) {
+s-flags |= 1 HPET_MSI_SUPPORT;
+}
return 0;
}
@@ -361,6 +379,8 @@ static uint32_t hpet_ram_readl(void *opaque,
target_phys_addr_t addr)
case HPET_TN_CMP + 4:
return timer-cmp 32;
case HPET_TN_ROUTE:
+return timer-fsb;
+case HPET_TN_ROUTE + 4:
return timer-fsb 32;
default:
DPRINTF(qemu: invalid hpet_ram_readl\n);
@@ -444,6 +464,9 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
switch ((addr - 0x100) % 0x20) {
case HPET_TN_CFG:
DPRINTF(qemu: hpet_ram_writel HPET_TN_CFG\n);
+if (activating_bit(old_val, new_val, HPET_TN_FSB_ENABLE)) {
+update_irq(timer, 0);
+}
val = hpet_fixup_reg(new_val, old_val, HPET_TN_CFG_WRITE_MASK);
timer-config = (timer-config 0xULL) | val;
if (new_val HPET_TN_32BIT) {
@@ -501,8 +524,11 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
hpet_set_timer(timer);
}
break;
+case HPET_TN_ROUTE:
+timer-fsb = (timer-fsb 0xULL) | new_val;
+break;
case HPET_TN_ROUTE + 4:
-DPRINTF(qemu: hpet_ram_writel HPET_TN_ROUTE + 4\n);
+timer-fsb = (new_val 32) | (timer-fsb 0x);
break;
default:
DPRINTF(qemu: invalid hpet_ram_writel\n);
@@ -610,7 +636,10 @@ static void hpet_reset(DeviceState *d)
hpet_del_timer(timer);
timer-cmp = ~0ULL;
-timer-config = HPET_TN_PERIODIC_CAP | HPET_TN_SIZE_CAP;
+timer-config = HPET_TN_PERIODIC_CAP | HPET_TN_SIZE_CAP;
+if (s-flags (1 HPET_MSI_SUPPORT)) {
+timer-config |= HPET_TN_FSB_CAP;
+}
/* advertise availability of ioapic inti2 */
timer-config |= 0x0004ULL 32;
timer-period = 0ULL;
@@ -686,6 +715,7 @@ static
[Qemu-devel] [PATCH v4 11/13] hpet: Make number of timers configurable
From: Jan Kiszka jan.kis...@siemens.com
One HPET block supports up to 32 timers. Allow to instantiate more than
the recommended and implemented minimum of 3. The number is configured
via the qdev property timers. It is also saved/restored so that it
need not match between migration peers.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
hw/hpet.c | 53 -
hw/hpet_emul.h |6 +-
2 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index f24b227..6187e5e 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -60,7 +60,8 @@ typedef struct HPETState {
uint64_t hpet_offset;
qemu_irq irqs[HPET_NUM_IRQ_ROUTES];
uint8_t rtc_irq_level;
-HPETTimer timer[HPET_NUM_TIMERS];
+uint8_t num_timers;
+HPETTimer timer[HPET_MAX_TIMERS];
/* Memory-mapped, software visible registers */
uint64_t capability;/* capabilities */
@@ -196,12 +197,25 @@ static void hpet_pre_save(void *opaque)
s-hpet_counter = hpet_get_ticks(s);
}
+static int hpet_pre_load(void *opaque)
+{
+HPETState *s = opaque;
+
+/* version 1 only supports 3, later versions will load the actual value */
+s-num_timers = HPET_MIN_TIMERS;
+return 0;
+}
+
static int hpet_post_load(void *opaque, int version_id)
{
HPETState *s = opaque;
/* Recalculate the offset between the main counter and guest time */
s-hpet_offset = ticks_to_ns(s-hpet_counter) - qemu_get_clock(vm_clock);
+
+/* Push number of timers into capability returned via HPET_ID */
+s-capability = ~HPET_ID_NUM_TIM_MASK;
+s-capability |= (s-num_timers - 1) HPET_ID_NUM_TIM_SHIFT;
return 0;
}
@@ -224,17 +238,19 @@ static const VMStateDescription vmstate_hpet_timer = {
static const VMStateDescription vmstate_hpet = {
.name = hpet,
-.version_id = 1,
+.version_id = 2,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
.pre_save = hpet_pre_save,
+.pre_load = hpet_pre_load,
.post_load = hpet_post_load,
.fields = (VMStateField []) {
VMSTATE_UINT64(config, HPETState),
VMSTATE_UINT64(isr, HPETState),
VMSTATE_UINT64(hpet_counter, HPETState),
-VMSTATE_STRUCT_ARRAY(timer, HPETState, HPET_NUM_TIMERS, 0,
- vmstate_hpet_timer, HPETTimer),
+VMSTATE_UINT8_V(num_timers, HPETState, 2),
+VMSTATE_STRUCT_VARRAY_UINT8(timer, HPETState, num_timers, 0,
+vmstate_hpet_timer, HPETTimer),
VMSTATE_END_OF_LIST()
}
};
@@ -330,7 +346,7 @@ static uint32_t hpet_ram_readl(void *opaque,
target_phys_addr_t addr)
uint8_t timer_id = (addr - 0x100) / 0x20;
HPETTimer *timer = s-timer[timer_id];
-if (timer_id HPET_NUM_TIMERS - 1) {
+if (timer_id s-num_timers) {
DPRINTF(qemu: timer id out of range\n);
return 0;
}
@@ -421,7 +437,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
HPETTimer *timer = s-timer[timer_id];
DPRINTF(qemu: hpet_ram_writel timer_id = %#x \n, timer_id);
-if (timer_id HPET_NUM_TIMERS - 1) {
+if (timer_id s-num_timers) {
DPRINTF(qemu: timer id out of range\n);
return;
}
@@ -504,7 +520,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
/* Enable main counter and interrupt generation. */
s-hpet_offset =
ticks_to_ns(s-hpet_counter) - qemu_get_clock(vm_clock);
-for (i = 0; i HPET_NUM_TIMERS; i++) {
+for (i = 0; i s-num_timers; i++) {
if ((s-timer[i])-cmp != ~0ULL) {
hpet_set_timer(s-timer[i]);
}
@@ -512,7 +528,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
} else if (deactivating_bit(old_val, new_val, HPET_CFG_ENABLE)) {
/* Halt main counter and disable interrupt generation. */
s-hpet_counter = hpet_get_ticks(s);
-for (i = 0; i HPET_NUM_TIMERS; i++) {
+for (i = 0; i s-num_timers; i++) {
hpet_del_timer(s-timer[i]);
}
}
@@ -530,7 +546,7 @@ static void hpet_ram_writel(void *opaque,
target_phys_addr_t addr,
break;
case HPET_STATUS:
val = new_val s-isr;
-for (i = 0; i HPET_NUM_TIMERS; i++) {
+for (i = 0; i s-num_timers; i++) {
if (val (1 i)) {
update_irq(s-timer[i], 0);
}
@@ -589,7 +605,7 @@ static void hpet_reset(DeviceState *d)
int i;
static int count = 0;
-for (i = 0; i HPET_NUM_TIMERS; i++) {
+for (i = 0; i s-num_timers; i++) {
HPETTimer *timer = s-timer[i];
hpet_del_timer(timer);
@@ -603,8 +619,9 @@ static
Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest
Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui: Please email the patch to qemu-devel@nongnu.org via git-send-email. Isn't the following post enough? What's incomplete on this? http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html That is still not a proper git-format-patch patch, it is missing among others the From: and Subject: lines and, likely, a more detailled description of what it does and why, for maintainers to be able to apply it with the git-am tool. But first it needs to be reviewed and ack'ed by people knowing that part of the code, and such review is done by inline patches on qemu- devel mailing list, not by HTTP links to bugtrackers (there are simply too many patches). The git-send-email tool assures that the format is not damaged by your favorite mail agent. Hope that explains, Andreas
Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM onNetBSD guest
Please email the patch to qemu-devel@nongnu.org via git-send-email. Isn't the following post enough? What's incomplete on this? http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html That is still not a proper git-format-patch patch, it is missing among others the From: and Subject: lines and, likely, a more detailled description of what it does and why, for maintainers to be able to apply it with the git-am tool. Whole description is in the bug report itself. git-format-patch is strictly required even in such case? If so, is there any proper documents how to submit patches for QEMU? --- Izumi Tsutsui -- Can't read e1000 NIC EEPROM on NetBSD guest https://bugs.launchpad.net/bugs/581737 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: Incomplete Bug description: QEMU Version: qemu-0.12.4 Host OS: NetBSD/i386 5.0.2 Guest OS: NetBSD/i386 5.1_RC1 On this environment, guest NetBSD tries to attach e1000 NIC using its own wm(4) driver but fails to read EEPROM as the following: --- NetBSD 5.1_RC1 (GENERIC) #0: Sat Apr 24 23:26:09 UTC 2010 bui...@b7.netbsd.org:/home/builds/ab/netbsd-5-1-RC1/i386/201004250032Z-obj/home/builds/ab/ netbsd-5-1-RC1/src/sys/arch/i386/compile/GENERIC total memory = 127 MB avail memory = 113 MB Bochs Bochs : drm at vga1 not configured wm0 at pci0 dev 3 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 3 wm0: interrupting at irq 11 wm0: unable to read Ethernet address isa0 at pcib0 : --- You can reproduce this with NetBSD/i386 install CD image: ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.1_RC1/iso/i386cd-5.1_RC1.iso % qemu -cdrom i386cd-5.1_RC1.iso -boot d ---in QEMU window--- [type ^C to quit installer] # dmesg | grep wm0 -- Per DBGOUT(EEPROM) messages, it show too large eecd_state.bitnum values, i.e. EEPROM state is not reset properly. The set_eecd() function in e1000.c clears EEPROM internal state values on SK rising edge during CS==L. But according to FM93C06 EEPROM (which is MicroWire compatible) data sheet, EEPROM internal status should be cleared on CS rise edge regardless of SK input: ... a rising edge on this signal is required to reset the internal state-machine to accept a new cycle .. Intel's em driver seems to explicitly raise and lower SK output after CS is negated in em_standby_eeprom() so many other OSes that use Intel's driver don't have this problem with current e1000.c implementation, but I can't find articles that say the MICROWIRE or EEPROM spec requires such sequence. With the attached patch, NetBSD guest properly gets MAC address from e1000 NIC EEPROM.
Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest
On Sun, Jun 13, 2010 at 02:21:21PM +0200, Andreas Färber wrote: Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui: Please email the patch to qemu-devel@nongnu.org via git-send-email. Isn't the following post enough? What's incomplete on this? http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html That is still not a proper git-format-patch patch, it is missing among others the From: and Subject: lines and, likely, a more detailled description of what it does and why, for maintainers to be able to apply it with the git-am tool. But first it needs to be reviewed and ack'ed by people knowing that part of the code, and such review is done by inline patches on qemu- devel mailing list, not by HTTP links to bugtrackers (there are simply too many patches). The git-send-email tool assures that the format is not damaged by your favorite mail agent. Can you imagine how frustrating this is to someone who's just trying to get a simple bug fix fed upstream? I find it quite unreasonable that one should be forced through this many hoops just to get a trivial patch even considered. Jonathan Kollasch
[Qemu-devel] Re: [PATCH v4 00/13] HPET cleanups, fixes, enhancements
Thanks, applied all. On Sun, Jun 13, 2010 at 12:15 PM, Jan Kiszka jan.kis...@web.de wrote: As the discussion around how to extend the IRQ framework /wrt de-coalescing or message passing support still hasn't settled yet, this series now skips the related changes, just focusing on the HPET. No further changes compared to v3. Please merge. Jan Kiszka (13): hpet: Catch out-of-bounds timer access hpet: Coding style cleanups and some refactorings hpet: Silence warning on write to running main counter hpet: Move static timer field initialization hpet: Convert to qdev hpet: Start/stop timer when HPET_TN_ENABLE is modified hpet/rtc: Rework RTC IRQ replacement by HPET hpet: Drop static state hpet: Add support for level-triggered interrupts vmstate: Add VMSTATE_STRUCT_VARRAY_UINT8 hpet: Make number of timers configurable hpet: Add MSI support monitor/QMP: Drop info hpet / query-hpet QMP/vm-info | 2 +- hw/hpet.c | 580 + hw/hpet_emul.h | 46 + hw/hw.h | 10 + hw/mc146818rtc.c | 49 ++ hw/mc146818rtc.h | 4 +- hw/mips_jazz.c | 2 +- hw/mips_malta.c | 2 +- hw/mips_r4k.c | 2 +- hw/pc.c | 15 +- hw/ppc_prep.c | 2 +- monitor.c | 22 -- qemu-monitor.hx | 21 -- 13 files changed, 415 insertions(+), 342 deletions(-)
Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest
Am 13.06.2010 um 15:10 schrieb Jonathan A. Kollasch: On Sun, Jun 13, 2010 at 02:21:21PM +0200, Andreas Färber wrote: Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui: Please email the patch to qemu-devel@nongnu.org via git-send-email. Isn't the following post enough? What's incomplete on this? http://lists.nongnu.org/archive/html/qemu-devel/2010-06/ msg00449.html That is still not a proper git-format-patch patch, it is missing among others the From: and Subject: lines and, likely, a more detailled description of what it does and why, for maintainers to be able to apply it with the git-am tool. But first it needs to be reviewed and ack'ed by people knowing that part of the code, and such review is done by inline patches on qemu- devel mailing list, not by HTTP links to bugtrackers (there are simply too many patches). The git-send-email tool assures that the format is not damaged by your favorite mail agent. Can you imagine how frustrating this is to someone who's just trying to get a simple bug fix fed upstream? Yes. Can you imagine what it's like having 3480 unread qemu-devel messages and an estimated average of 50 patches per day? I find it quite unreasonable that one should be forced through this many hoops just to get a trivial patch even considered. I've been through those hoops myself. I learned Git for this project and am now voluntarily using it for at least three other projects, too. It's definitely a good time investment! In this particular case the reporter apparently went through the hoop of *deleting* regular git-format-patch output before uploading it and did not even leave a one-line summary. I didn't make the rules though, and if Anthony or someone wants to spend the time of refining such bug patches themselves that's fine with me. Ryan and I were just trying to help. Andreas
Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM onNetBSD guest
Am 13.06.2010 um 14:50 schrieb Izumi Tsutsui: Please email the patch to qemu-devel@nongnu.org via git-send-email. Isn't the following post enough? What's incomplete on this? http://lists.nongnu.org/archive/html/qemu-devel/2010-06/ msg00449.html That is still not a proper git-format-patch patch, it is missing among others the From: and Subject: lines and, likely, a more detailled description of what it does and why, for maintainers to be able to apply it with the git-am tool. Whole description is in the bug report itself. git-format-patch is strictly required even in such case? A self-contained description is required for the commit in the (distributed) Git repository. http://www.spheredev.org/wiki/Git_for_the_lazy#Writing_good_commit_messages http://git.qemu.org/qemu.git/log/ If so, is there any proper documents how to submit patches for QEMU? http://wiki.qemu.org/Contribute/StartHere http://git.qemu.org/qemu.git/plain/CODING_STYLE http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_patch_workflow It's not too QEMU-specific, so any Git tutorial should do. HTH, Andreas
[Qemu-devel] [PATCH] pass info about hpets to seabios.
Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios no longer uses hard coded hpet configuration. Proposed
interface supports up to 256 hpets. This is the number defined by hpet
spec.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/hw/hpet.c b/hw/hpet.c
index 93fc399..f2a4514 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -73,6 +73,8 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
+struct hpet_fw_config hpet_cfg = {.valid = 1};
+
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
return s-config HPET_CFG_LEGACY;
@@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d)
*/
hpet_pit_enable();
}
+hpet_cfg.count = 1;
+hpet_cfg.hpet.event_timer_block_id = (uint32_t)s-capability;
+hpet_cfg.hpet.address = sysbus_from_qdev(d)-mmio[0].addr;
count = 1;
}
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index d7bc102..5cf5463 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -53,4 +53,20 @@
#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
+struct hpet_fw_entry
+{
+uint32_t event_timer_block_id;
+uint64_t address;
+uint16_t min_tick;
+uint8_t page_prot;
+} __attribute__ ((packed));
+
+struct hpet_fw_config
+{
+uint8_t valid;
+uint8_t count;
+struct hpet_fw_entry hpet;
+} __attribute__ ((packed));
+
+extern struct hpet_fw_config hpet_cfg;
#endif
diff --git a/hw/pc.c b/hw/pc.c
index 1491129..d14d657 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -61,6 +61,7 @@
#define FW_CFG_SMBIOS_ENTRIES (FW_CFG_ARCH_LOCAL + 1)
#define FW_CFG_IRQ0_OVERRIDE (FW_CFG_ARCH_LOCAL + 2)
#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
+#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
#define E820_NR_ENTRIES16
@@ -484,6 +485,8 @@ static void *bochs_bios_init(void)
fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE, (uint8_t *)e820_table,
sizeof(struct e820_table));
+fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, (uint8_t *)hpet_cfg,
+ sizeof(struct hpet_fw_config));
/* allocate memory for the NUMA channel: one (64bit) word for the number
* of nodes, one word for each VCPU-node and one word for each node to
* hold the amount of memory.
--
Gleb.
[Qemu-devel] [PATCH] load hpet info for HPET ACPI table from qemu
Load hpet info for HPET ACPI table from qemu instead of using hardcoded
values. Use hardcoded values anyway if old qemu is detected.
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/src/acpi.c b/src/acpi.c
index 0559443..eeecca1 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -469,7 +469,7 @@ build_ssdt(void)
#define HPET_SIGNATURE 0x54455048 //HPET
static void*
-build_hpet(void)
+build_hpet(struct hpet_fw_entry *e, u8 id)
{
struct acpi_20_hpet *hpet = malloc_high(sizeof(*hpet));
if (!hpet) {
@@ -478,11 +478,11 @@ build_hpet(void)
}
memset(hpet, 0, sizeof(*hpet));
-/* Note timer_block_id value must be kept in sync with value advertised by
- * emulated hpet
- */
-hpet-timer_block_id = cpu_to_le32(0x8086a201);
-hpet-addr.address = cpu_to_le32(ACPI_HPET_ADDRESS);
+hpet-timer_block_id = cpu_to_le32(e-event_timer_block_id);
+hpet-addr.address = cpu_to_le32(e-address);
+hpet-min_tick = cpu_to_le32(e-min_tick);
+hpet-hpet_number = id;
+hpet-page_protect = e-page_prot;
build_header((void*)hpet, HPET_SIGNATURE, sizeof(*hpet), 1);
return hpet;
@@ -637,9 +637,28 @@ acpi_bios_init(void)
ACPI_INIT_TABLE(build_fadt(bdf));
ACPI_INIT_TABLE(build_ssdt());
ACPI_INIT_TABLE(build_madt());
-ACPI_INIT_TABLE(build_hpet());
ACPI_INIT_TABLE(build_srat());
+u8 hpet_id = 0;
+u32 c = qemu_cfg_hpet_entries();
+struct hpet_fw_entry e;
+
+if (c == ~0) {
+/* qemu do not provide hpet description */
+e.event_timer_block_id = 0x8086a201;
+e.address = ACPI_HPET_ADDRESS;
+e.min_tick = 0;
+c = 1;
+} else if (c != 0)
+qemu_cfg_hpet_load_next(e);
+
+while (c--) {
+ACPI_INIT_TABLE(build_hpet(e, hpet_id++));
+if (c)
+qemu_cfg_hpet_load_next(e);
+}
+
+
u16 i, external_tables = qemu_cfg_acpi_additional_tables();
for(i = 0; i external_tables; i++) {
diff --git a/src/paravirt.c b/src/paravirt.c
index 5c77b5c..13a4916 100644
--- a/src/paravirt.c
+++ b/src/paravirt.c
@@ -149,6 +149,26 @@ void* qemu_cfg_e820_load_next(void *addr)
return addr;
}
+u32 qemu_cfg_hpet_entries(void)
+{
+u8 cnt;
+
+if (!qemu_cfg_present)
+return 0;
+
+/* read valid flags */
+qemu_cfg_read_entry(cnt, QEMU_CFG_HPET, sizeof(cnt));
+if (!cnt)
+return ~0;
+qemu_cfg_read(cnt, sizeof(cnt));
+return cnt;
+}
+
+void qemu_cfg_hpet_load_next(struct hpet_fw_entry *e)
+{
+qemu_cfg_read((u8*)e, sizeof(*e));
+}
+
struct smbios_header {
u16 length;
u8 type;
diff --git a/src/paravirt.h b/src/paravirt.h
index c46418f..2fd98cc 100644
--- a/src/paravirt.h
+++ b/src/paravirt.h
@@ -37,6 +37,7 @@ static inline int kvm_para_available(void)
#define QEMU_CFG_SMBIOS_ENTRIES(QEMU_CFG_ARCH_LOCAL + 1)
#define QEMU_CFG_IRQ0_OVERRIDE (QEMU_CFG_ARCH_LOCAL + 2)
#define QEMU_CFG_E820_TABLE(QEMU_CFG_ARCH_LOCAL + 3)
+#define QEMU_CFG_HPET (QEMU_CFG_ARCH_LOCAL + 4)
extern int qemu_cfg_present;
@@ -68,10 +69,20 @@ struct e820_reservation {
u32 type;
};
+struct hpet_fw_entry
+{
+u32 event_timer_block_id;
+u64 address;
+u16 min_tick;
+u8 page_prot;
+} __attribute__ ((packed));
+
u16 qemu_cfg_first_file(QemuCfgFile *entry);
u16 qemu_cfg_next_file(QemuCfgFile *entry);
u32 qemu_cfg_read_file(QemuCfgFile *entry, void *dst, u32 maxlen);
u32 qemu_cfg_e820_entries(void);
void* qemu_cfg_e820_load_next(void *addr);
+u32 qemu_cfg_hpet_entries(void);
+void qemu_cfg_hpet_load_next(struct hpet_fw_entry *e);
#endif
--
Gleb.
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
I think we could solve all problems (well, maybe not world peace, yet) by switching to message based system for all of DMA and IRQs. Each device would have a message input port and way to output messages. Examples: Zero copy memory access from device D1 to D2 to host memory (D3) with access broken to page length units and errors occurring on the last byte: D1 send_msg(ID, MSG_MEM_WRITE, DMA address, length) - D2 ... IRQ delivery chain D1-D2-D3 with coalescing, messages, delivery reporting and EOI: D1 send_msg(ID, MSG_IRQ_RAISE, payload) - D2 This feels like a terrible idea to me. It introduces an unnecessary RPC indirection layer without actually solving any of the problems. It just makes it harder (if not impossible) for the compiler to verify any of the interfaces between objects. If we need a mechanism for a device to query the state of its outgoing IRQ lines (which is what I mentioned previously), then we can just add that. I still maintain that qemu_irq is *not* a message passing interface, and that this absence is a good thing. Maybe if I make the qemu_irq code actively suppress redundant level change notices that would make things clearer. Paul
Re: [Qemu-devel] [PATCH 15/35] tcg-s390: Query instruction extensions that are installed.
On 06/13/2010 03:49 AM, Aurelien Jarno wrote: Also, what era is that second machine without highgprs? Is it running an old kernel, or a 32-bit kernel? I have very few infos about it, it's an IBM System z10 machine running a 64-bit 2.6.26 kernel. Ah, I see it now: ea2a4d3a3a929ef494952bba57a0ef1a8a877881 [S390] 64-bit register support for 31-bit processes which adds a mechanism to pass the high parts of the gprs in the ucontext to the 31-bit signal handler, and adds a spot for them in the 31-bit core dump. It doesn't change the actual saving of registers within the kernel. Since we take asynchronous signals and return from them (as opposed to always longjmping out), we cannot use the full 64-bit register within a 31-bit process without having that bit set in HWCAP. Something to remember if we ever implement TCG for 31-bit mode. At the moment we only allow KVM in 31-bit mode. r~
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
TBH I preferred the original system whereby the source can query the state of the sink (i.e are you ignoring this line?). Note that conceptually this should be *querying* state, not responding to an event. People are still pushing qemu_irq as an message passing interface, so I'm going to expand a bit more on how I think this could be avoided. Start with the assumption that qemu irq represents a single bit of information. The current implementation is stateless, but in principle it could remember its state and ignore redundant calls to qemu_set_irq. In order to workaround the periodic timer issue, we need some way of for the source device to interrogate the target device state relating to this link. The suggestions so far are along the lines of what happened when I made this change. This makes me unhappy, because it's overlaying event semantics on top of a state based system. Instead I suggest that we should be describing what the target state associated with this input is. Suitable return values could be: * normal: This input effects the state of the target device. Note that this need not imply that changing the input actually effects the output at this time. e.g. if an interrupt controller is already processing a higher priority input, the low priority inputs should still return normal - the input will be processed once the unrelated high priority input is finished. * latched: This input has already effected target device state, and will be ignored until reset by some external event. Typically means an interrupt controller latches its inputs, and this input has already been latched. * masked: This input is ignored. In practice these should give approximately the same information as event based delivered/coalesced/dropped responses. The difference is that they are consistent with the state based nature of qemu_irq. Paul
Re: [Qemu-devel] [PATCH 15/35] tcg-s390: Query instruction extensions that are installed.
On Sun, Jun 13, 2010 at 09:02:40AM -0700, Richard Henderson wrote: On 06/13/2010 03:49 AM, Aurelien Jarno wrote: Also, what era is that second machine without highgprs? Is it running an old kernel, or a 32-bit kernel? I have very few infos about it, it's an IBM System z10 machine running a 64-bit 2.6.26 kernel. Ah, I see it now: ea2a4d3a3a929ef494952bba57a0ef1a8a877881 [S390] 64-bit register support for 31-bit processes which adds a mechanism to pass the high parts of the gprs in the ucontext to the 31-bit signal handler, and adds a spot for them in the 31-bit core dump. It doesn't change the actual saving of registers within the kernel. Since we take asynchronous signals and return from them (as opposed to always longjmping out), we cannot use the full 64-bit register within a 31-bit process without having that bit set in HWCAP. Something to remember if we ever implement TCG for 31-bit mode. At the moment we only allow KVM in 31-bit mode. Is KVM in 31-bit mode actually functional? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
Gleb Natapov wrote:
Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios no longer uses hard coded hpet configuration. Proposed
interface supports up to 256 hpets. This is the number defined by hpet
spec.
Nice, this lays the ground for adding hpets via -device.
(But I think I read there can only be 8 hpets with a total sum of 256
timers.)
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/hw/hpet.c b/hw/hpet.c
index 93fc399..f2a4514 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -73,6 +73,8 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
+struct hpet_fw_config hpet_cfg = {.valid = 1};
+
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
return s-config HPET_CFG_LEGACY;
@@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d)
*/
hpet_pit_enable();
}
+hpet_cfg.count = 1;
+hpet_cfg.hpet.event_timer_block_id = (uint32_t)s-capability;
The number of timers, thus the content of capability can change on
vmload. So you need to update hpet_cfg there as well.
And I think we can move the capability setup into init. But this is not
directly related to this patch, would just avoid adding this hunk to
hpet_reset.
+hpet_cfg.hpet.address = sysbus_from_qdev(d)-mmio[0].addr;
count = 1;
}
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index d7bc102..5cf5463 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -53,4 +53,20 @@
#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
+struct hpet_fw_entry
+{
+uint32_t event_timer_block_id;
+uint64_t address;
+uint16_t min_tick;
+uint8_t page_prot;
+} __attribute__ ((packed));
+
+struct hpet_fw_config
+{
+uint8_t valid;
+uint8_t count;
+struct hpet_fw_entry hpet;
Why not already struct hpet_fw_entry hpet[8]? Once the bios bits are
merge, we can quickly remove the single hpet limitation on qemu side.
+} __attribute__ ((packed));
+
+extern struct hpet_fw_config hpet_cfg;
#endif
diff --git a/hw/pc.c b/hw/pc.c
index 1491129..d14d657 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -61,6 +61,7 @@
#define FW_CFG_SMBIOS_ENTRIES (FW_CFG_ARCH_LOCAL + 1)
#define FW_CFG_IRQ0_OVERRIDE (FW_CFG_ARCH_LOCAL + 2)
#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
+#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
#define E820_NR_ENTRIES 16
@@ -484,6 +485,8 @@ static void *bochs_bios_init(void)
fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE, (uint8_t *)e820_table,
sizeof(struct e820_table));
+fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, (uint8_t *)hpet_cfg,
+ sizeof(struct hpet_fw_config));
/* allocate memory for the NUMA channel: one (64bit) word for the number
* of nodes, one word for each VCPU-node and one word for each node to
* hold the amount of memory.
--
Gleb.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] Re: [PATCH v2 0/7] APIC/IOAPIC cleanup
Am 13.06.2010 um 18:56 schrieb Jan Kiszka: Blue Swirl wrote: Clean up APIC and IOAPIC. Convert both devices to qdev. Wanted to give this a try, but patches are line-wrapped. Please fix. Threading the patches would also be appreciated. Git's default changed at some point, this can be overridden in .gitconfig. Andreas
[Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios no longer uses hard coded hpet configuration. Proposed
interface supports up to 256 hpets. This is the number defined by hpet
spec.
Nice, this lays the ground for adding hpets via -device.
(But I think I read there can only be 8 hpets with a total sum of 256
timers.)
Ah, correct. I thought to myself 256 hpets should be to much :)
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/hw/hpet.c b/hw/hpet.c
index 93fc399..f2a4514 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -73,6 +73,8 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
+struct hpet_fw_config hpet_cfg = {.valid = 1};
+
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
return s-config HPET_CFG_LEGACY;
@@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d)
*/
hpet_pit_enable();
}
+hpet_cfg.count = 1;
+hpet_cfg.hpet.event_timer_block_id = (uint32_t)s-capability;
The number of timers, thus the content of capability can change on
vmload. So you need to update hpet_cfg there as well.
How it can change? User is required to run the same command line on src
and dst, no?
And I think we can move the capability setup into init. But this is not
directly related to this patch, would just avoid adding this hunk to
hpet_reset.
I actually did that initially and tried to init hpet_cfg there too, but
then noticed that mmio[0].addr below is not initialized at init time yet.
+hpet_cfg.hpet.address = sysbus_from_qdev(d)-mmio[0].addr;
count = 1;
}
diff --git a/hw/hpet_emul.h b/hw/hpet_emul.h
index d7bc102..5cf5463 100644
--- a/hw/hpet_emul.h
+++ b/hw/hpet_emul.h
@@ -53,4 +53,20 @@
#define HPET_TN_INT_ROUTE_CAP_SHIFT 32
#define HPET_TN_CFG_BITS_READONLY_OR_RESERVED 0x80b1U
+struct hpet_fw_entry
+{
+uint32_t event_timer_block_id;
+uint64_t address;
+uint16_t min_tick;
+uint8_t page_prot;
+} __attribute__ ((packed));
+
+struct hpet_fw_config
+{
+uint8_t valid;
+uint8_t count;
+struct hpet_fw_entry hpet;
Why not already struct hpet_fw_entry hpet[8]? Once the bios bits are
merge, we can quickly remove the single hpet limitation on qemu side.
Number 256 somehow stuck in my head. 8 hpets is Ok to do from the start.
+} __attribute__ ((packed));
+
+extern struct hpet_fw_config hpet_cfg;
#endif
diff --git a/hw/pc.c b/hw/pc.c
index 1491129..d14d657 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -61,6 +61,7 @@
#define FW_CFG_SMBIOS_ENTRIES (FW_CFG_ARCH_LOCAL + 1)
#define FW_CFG_IRQ0_OVERRIDE (FW_CFG_ARCH_LOCAL + 2)
#define FW_CFG_E820_TABLE (FW_CFG_ARCH_LOCAL + 3)
+#define FW_CFG_HPET (FW_CFG_ARCH_LOCAL + 4)
#define E820_NR_ENTRIES16
@@ -484,6 +485,8 @@ static void *bochs_bios_init(void)
fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE, (uint8_t *)e820_table,
sizeof(struct e820_table));
+fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, (uint8_t *)hpet_cfg,
+ sizeof(struct hpet_fw_config));
/* allocate memory for the NUMA channel: one (64bit) word for the
number
* of nodes, one word for each VCPU-node and one word for each node to
* hold the amount of memory.
--
Gleb.
Jan
--
Gleb.
[Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
Gleb Natapov wrote:
On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios no longer uses hard coded hpet configuration. Proposed
interface supports up to 256 hpets. This is the number defined by hpet
spec.
Nice, this lays the ground for adding hpets via -device.
(But I think I read there can only be 8 hpets with a total sum of 256
timers.)
Ah, correct. I thought to myself 256 hpets should be to much :)
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/hw/hpet.c b/hw/hpet.c
index 93fc399..f2a4514 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -73,6 +73,8 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
+struct hpet_fw_config hpet_cfg = {.valid = 1};
+
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
return s-config HPET_CFG_LEGACY;
@@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d)
*/
hpet_pit_enable();
}
+hpet_cfg.count = 1;
+hpet_cfg.hpet.event_timer_block_id = (uint32_t)s-capability;
The number of timers, thus the content of capability can change on
vmload. So you need to update hpet_cfg there as well.
How it can change? User is required to run the same command line on src
and dst, no?
Generally, yes. But there is no technical need to match the hpet props
so far, they are included in the vmstate (implicitly).
And I think we can move the capability setup into init. But this is not
directly related to this patch, would just avoid adding this hunk to
hpet_reset.
I actually did that initially and tried to init hpet_cfg there too, but
then noticed that mmio[0].addr below is not initialized at init time yet.
Indeed.
You may try sysbus_init_mmio_cb instead for a callback to be invoked
once the address was set. That handler could also be called on vmload.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH v2 0/7] APIC/IOAPIC cleanup
On Sun, Jun 13, 2010 at 4:56 PM, Jan Kiszka jan.kis...@web.de wrote: Blue Swirl wrote: Clean up APIC and IOAPIC. Convert both devices to qdev. Wanted to give this a try, but patches are line-wrapped. Please fix. I've pushed the patches here: git://repo.or.cz/qemu/blueswirl.git http://repo.or.cz/w/qemu/blueswirl.git
Re: [Qemu-devel] Re: [PATCH v2 0/7] APIC/IOAPIC cleanup
On Sun, Jun 13, 2010 at 5:03 PM, Andreas Färber andreas.faer...@web.de wrote: Am 13.06.2010 um 18:56 schrieb Jan Kiszka: Blue Swirl wrote: Clean up APIC and IOAPIC. Convert both devices to qdev. Wanted to give this a try, but patches are line-wrapped. Please fix. Threading the patches would also be appreciated. Git's default changed at some point, this can be overridden in .gitconfig. I have these lines in $HOME/.gitconfig [format] thread = true I'm also using --thread flag in git-format-patch command line. git --version git version 1.7.1
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
On Sun, Jun 13, 2010 at 4:34 PM, Paul Brook p...@codesourcery.com wrote: TBH I preferred the original system whereby the source can query the state of the sink (i.e are you ignoring this line?). Note that conceptually this should be *querying* state, not responding to an event. People are still pushing qemu_irq as an message passing interface, so I'm going to expand a bit more on how I think this could be avoided. Start with the assumption that qemu irq represents a single bit of information. The current implementation is stateless, but in principle it could remember its state and ignore redundant calls to qemu_set_irq. In order to workaround the periodic timer issue, we need some way of for the source device to interrogate the target device state relating to this link. The suggestions so far are along the lines of what happened when I made this change. This makes me unhappy, because it's overlaying event semantics on top of a state based system. Instead I suggest that we should be describing what the target state associated with this input is. Suitable return values could be: * normal: This input effects the state of the target device. Note that this need not imply that changing the input actually effects the output at this time. e.g. if an interrupt controller is already processing a higher priority input, the low priority inputs should still return normal - the input will be processed once the unrelated high priority input is finished. * latched: This input has already effected target device state, and will be ignored until reset by some external event. Typically means an interrupt controller latches its inputs, and this input has already been latched. * masked: This input is ignored. In practice these should give approximately the same information as event based delivered/coalesced/dropped responses. The difference is that they are consistent with the state based nature of qemu_irq. I agree this would be enough for the current RTC/APIC case. This doesn't help in EOI handling or message passing in any way, but we can make completely separate systems for those later when the need arises.
[Qemu-devel] [PATCH,applied] Move stdbool.h
Move inclusion of stdbool.h to common header files, instead of including
in an ad-hoc manner.
Signed-off-by: Paul Brook p...@codesourcery.com
---
block/blkdebug.c |2 --
check-qjson.c|1 -
dyngen-exec.h|1 +
hw/9p.h |2 --
hw/eepro100.c|1 -
hw/hw.h |1 -
hw/virtio-serial.h |1 -
hw/xenfb.c |1 -
json-parser.c|1 -
kvm.h|1 -
nbd.h|1 -
net.h|1 -
qemu-common.h|1 +
vnc-encoding-tight.c |2 --
14 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index 8325f75..98fed94 100644
--- a/block/blkdebug.c
+++ b/block/blkdebug.c
@@ -26,8 +26,6 @@
#include block_int.h
#include module.h
-#include stdbool.h
-
typedef struct BlkdebugVars {
int state;
diff --git a/check-qjson.c b/check-qjson.c
index 109e777..86e780c 100644
--- a/check-qjson.c
+++ b/check-qjson.c
@@ -9,7 +9,6 @@
*
*/
#include check.h
-#include stdbool.h
#include qstring.h
#include qint.h
diff --git a/dyngen-exec.h b/dyngen-exec.h
index 0700a2d..5bfef3f 100644
--- a/dyngen-exec.h
+++ b/dyngen-exec.h
@@ -31,6 +31,7 @@
host headers do not allow that. */
#include stddef.h
#include stdint.h
+#include stdbool.h
#ifdef __OpenBSD__
#include sys/types.h
diff --git a/hw/9p.h b/hw/9p.h
index 5fdd770..d9951d6 100644
--- a/hw/9p.h
+++ b/hw/9p.h
@@ -14,8 +14,6 @@
#ifndef QEMU_9P_H
#define QEMU_9P_H
-#include stdbool.h
-
typedef struct V9fsConf
{
/* tag name for the device */
diff --git a/hw/eepro100.c b/hw/eepro100.c
index a74d834..97afa2c 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -41,7 +41,6 @@
* * Wake-on-LAN is not implemented.
*/
-#include stdbool.h/* bool */
#include stddef.h /* offsetof */
#include hw.h
#include pci.h
diff --git a/hw/hw.h b/hw/hw.h
index 36be0be..a49d866 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -8,7 +8,6 @@
#include cpu-common.h
#endif
-#include stdbool.h
#include ioport.h
#include irq.h
diff --git a/hw/virtio-serial.h b/hw/virtio-serial.h
index a93b545..ff08c40 100644
--- a/hw/virtio-serial.h
+++ b/hw/virtio-serial.h
@@ -15,7 +15,6 @@
#ifndef _QEMU_VIRTIO_SERIAL_H
#define _QEMU_VIRTIO_SERIAL_H
-#include stdbool.h
#include qdev.h
#include virtio.h
diff --git a/hw/xenfb.c b/hw/xenfb.c
index 422cd53..da5297b 100644
--- a/hw/xenfb.c
+++ b/hw/xenfb.c
@@ -29,7 +29,6 @@
#include sys/types.h
#include fcntl.h
#include unistd.h
-#include stdbool.h
#include sys/mman.h
#include errno.h
#include stdio.h
diff --git a/json-parser.c b/json-parser.c
index b55d763..1c88ed8 100644
--- a/json-parser.c
+++ b/json-parser.c
@@ -11,7 +11,6 @@
*
*/
-#include stdbool.h
#include stdarg.h
#include qemu-common.h
diff --git a/kvm.h b/kvm.h
index a28e7aa..a30529c 100644
--- a/kvm.h
+++ b/kvm.h
@@ -14,7 +14,6 @@
#ifndef QEMU_KVM_H
#define QEMU_KVM_H
-#include stdbool.h
#include errno.h
#include config-host.h
#include qemu-queue.h
diff --git a/nbd.h b/nbd.h
index 5deac29..5a1fbdf 100644
--- a/nbd.h
+++ b/nbd.h
@@ -20,7 +20,6 @@
#define NBD_H
#include sys/types.h
-#include stdbool.h
#include qemu-common.h
#include block_int.h
diff --git a/net.h b/net.h
index b83f615..518cf9c 100644
--- a/net.h
+++ b/net.h
@@ -1,7 +1,6 @@
#ifndef QEMU_NET_H
#define QEMU_NET_H
-#include stdbool.h
#include qemu-queue.h
#include qemu-common.h
#include qdict.h
diff --git a/qemu-common.h b/qemu-common.h
index a4888e5..d133f35 100644
--- a/qemu-common.h
+++ b/qemu-common.h
@@ -26,6 +26,7 @@ typedef struct QEMUBH QEMUBH;
#include stdlib.h
#include stdio.h
#include stdarg.h
+#include stdbool.h
#include string.h
#include strings.h
#include inttypes.h
diff --git a/vnc-encoding-tight.c b/vnc-encoding-tight.c
index e8604a8..faba483 100644
--- a/vnc-encoding-tight.c
+++ b/vnc-encoding-tight.c
@@ -26,8 +26,6 @@
* THE SOFTWARE.
*/
-#include stdbool.h
-
#include qdict.h
#include qint.h
#include vnc.h
--
1.7.1
Re: [Qemu-devel] Re: [PATCH v2 0/7] APIC/IOAPIC cleanup
Hi, Am 13.06.2010 um 19:53 schrieb Blue Swirl: On Sun, Jun 13, 2010 at 5:03 PM, Andreas Färber andreas.faer...@web.de wrote: Am 13.06.2010 um 18:56 schrieb Jan Kiszka: Blue Swirl wrote: Clean up APIC and IOAPIC. Convert both devices to qdev. Wanted to give this a try, but patches are line-wrapped. Please fix. Threading the patches would also be appreciated. Git's default changed at some point, this can be overridden in .gitconfig. I have these lines in $HOME/.gitconfig [format] thread = true I'm also using --thread flag in git-format-patch command line. git-send-email has --thread and --chain-reply-to options too: http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html I've been using --chain-reply-to with no .gitconfig settings successfully in 1.7.0.4. Andreas
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook p...@codesourcery.com wrote: I think we could solve all problems (well, maybe not world peace, yet) by switching to message based system for all of DMA and IRQs. Each device would have a message input port and way to output messages. Examples: Zero copy memory access from device D1 to D2 to host memory (D3) with access broken to page length units and errors occurring on the last byte: D1 send_msg(ID, MSG_MEM_WRITE, DMA address, length) - D2 ... IRQ delivery chain D1-D2-D3 with coalescing, messages, delivery reporting and EOI: D1 send_msg(ID, MSG_IRQ_RAISE, payload) - D2 This feels like a terrible idea to me. It introduces an unnecessary RPC indirection layer without actually solving any of the problems. It just makes it harder (if not impossible) for the compiler to verify any of the interfaces between objects. For the memory access case, in practice the interface could be sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr, target_phys_addr_t size) in place of send_msg() and sysbus_memory_rw_cb(DeviceState *dev, void *ptr, size_t size, int status) in place of send_replymsg() so we'd have compiler type checks.
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
On Sun, Jun 13, 2010 at 6:39 PM, Paul Brook p...@codesourcery.com wrote: On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook p...@codesourcery.com wrote: I think we could solve all problems (well, maybe not world peace, yet) by switching to message based system for all of DMA and IRQs. Each device would have a message input port and way to output messages. Examples: Zero copy memory access from device D1 to D2 to host memory (D3) with access broken to page length units and errors occurring on the last byte: D1 send_msg(ID, MSG_MEM_WRITE, DMA address, length) - D2 ... IRQ delivery chain D1-D2-D3 with coalescing, messages, delivery reporting and EOI: D1 send_msg(ID, MSG_IRQ_RAISE, payload) - D2 This feels like a terrible idea to me. It introduces an unnecessary RPC indirection layer without actually solving any of the problems. It just makes it harder (if not impossible) for the compiler to verify any of the interfaces between objects. For the memory access case, in practice the interface could be sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr, target_phys_addr_t size) Why parent? Parent device or bus host bridge device. Alternatively there could be a bus handle. in place of send_msg() and sysbus_memory_rw_cb(DeviceState *dev, void *ptr, size_t size, int status) in place of send_replymsg() so we'd have compiler type checks. I don't see any point point trying to squeeze this through a common message passing API. We *could* do that if we really wanted, but It's a lot of hassle. If devices are going to end up using wrappers that look a lot like a straight API then what's the point? Without IRQ and other messages, I agree that at this point it would not make much sense. Do you think this API as straight implementation would work? Compared to previous attempts for Generic DMA, we'd avoid any IO vector splitting/reallocations etc.
[Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
On Sun, Jun 13, 2010 at 07:41:14PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
Gleb Natapov wrote:
Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios no longer uses hard coded hpet configuration. Proposed
interface supports up to 256 hpets. This is the number defined by hpet
spec.
Nice, this lays the ground for adding hpets via -device.
(But I think I read there can only be 8 hpets with a total sum of 256
timers.)
Ah, correct. I thought to myself 256 hpets should be to much :)
Signed-off-by: Gleb Natapov g...@redhat.com
diff --git a/hw/hpet.c b/hw/hpet.c
index 93fc399..f2a4514 100644
--- a/hw/hpet.c
+++ b/hw/hpet.c
@@ -73,6 +73,8 @@ typedef struct HPETState {
uint64_t hpet_counter; /* main counter */
} HPETState;
+struct hpet_fw_config hpet_cfg = {.valid = 1};
+
static uint32_t hpet_in_legacy_mode(HPETState *s)
{
return s-config HPET_CFG_LEGACY;
@@ -661,6 +663,9 @@ static void hpet_reset(DeviceState *d)
*/
hpet_pit_enable();
}
+hpet_cfg.count = 1;
+hpet_cfg.hpet.event_timer_block_id = (uint32_t)s-capability;
The number of timers, thus the content of capability can change on
vmload. So you need to update hpet_cfg there as well.
How it can change? User is required to run the same command line on src
and dst, no?
Generally, yes. But there is no technical need to match the hpet props
so far, they are included in the vmstate (implicitly).
Assumption that config at src and dst are identical is everywhere in the
code and in the future we should be able to pass actual config as part
of the migration protocol. Better fail migration if we can detect that
configs are different then trying to fix some things, but not others.
And I think we can move the capability setup into init. But this is not
directly related to this patch, would just avoid adding this hunk to
hpet_reset.
I actually did that initially and tried to init hpet_cfg there too, but
then noticed that mmio[0].addr below is not initialized at init time yet.
Indeed.
You may try sysbus_init_mmio_cb instead for a callback to be invoked
once the address was set. That handler could also be called on vmload.
sysbus_init_mmio_cb calls callback instead of
cpu_register_physical_memory(). Looks like unneeded complication. Doing
it at reset should be fine as far as I see.
--
Gleb.
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
For the memory access case, in practice the interface could be sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr, target_phys_addr_t size) Why parent? Parent device or bus host bridge device. Alternatively there could be a bus handle. A device has no way of knowing where that bust host bridge is, and this may be the wrong device anyway. The access may be directed at another device on the same bus. A bus handle is trivial to derive this from the device itself. I don't see any point point trying to squeeze this through a common message passing API. We *could* do that if we really wanted, but It's a lot of hassle. If devices are going to end up using wrappers that look a lot like a straight API then what's the point? Without IRQ and other messages, I agree that at this point it would not make much sense. Do you think this API as straight implementation would work? Compared to previous attempts for Generic DMA, we'd avoid any IO vector splitting/reallocations etc. We have already merged a generic DMA infrastructure (cpu_physical_memory_map). See also dma-helpers.c for code that uses this to implement zero-copy transfers to/from block devices. This is missing code to allow manipulation by intermediate bus/bridges, but I believe the basic API is fairly sound. Addition of a device handle or error reporting should be possible without requiring major changes to the device code. Paul
Re: [Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
And I think we can move the capability setup into init. But this is not directly related to this patch, would just avoid adding this hunk to hpet_reset. I actually did that initially and tried to init hpet_cfg there too, but then noticed that mmio[0].addr below is not initialized at init time yet. +hpet_cfg.hpet.address = sysbus_from_qdev(d)-mmio[0].addr; This is one of the reasons that you're not supposed to be messing with DeviceState contents directly. Paul
Re: [Qemu-devel] [PATCH 15/35] tcg-s390: Query instruction extensions that are installed.
On 13.06.2010, at 18:44, Aurelien Jarno wrote: On Sun, Jun 13, 2010 at 09:02:40AM -0700, Richard Henderson wrote: On 06/13/2010 03:49 AM, Aurelien Jarno wrote: Also, what era is that second machine without highgprs? Is it running an old kernel, or a 32-bit kernel? I have very few infos about it, it's an IBM System z10 machine running a 64-bit 2.6.26 kernel. Ah, I see it now: ea2a4d3a3a929ef494952bba57a0ef1a8a877881 [S390] 64-bit register support for 31-bit processes which adds a mechanism to pass the high parts of the gprs in the ucontext to the 31-bit signal handler, and adds a spot for them in the 31-bit core dump. It doesn't change the actual saving of registers within the kernel. Since we take asynchronous signals and return from them (as opposed to always longjmping out), we cannot use the full 64-bit register within a 31-bit process without having that bit set in HWCAP. Something to remember if we ever implement TCG for 31-bit mode. At the moment we only allow KVM in 31-bit mode. Is KVM in 31-bit mode actually functional? I'm not aware of anything preventing it to be. But I honestly haven't tried. As long as all hypercall parameters stay within the first 32/31 bits, things should be safe. Alex
Re: [Qemu-devel] [PATCH 16/35] tcg-s390: Re-implement tcg_out_movi.
On Fri, Jun 04, 2010 at 12:14:24PM -0700, Richard Henderson wrote:
Make better use of the LOAD HALFWORD IMMEDIATE, LOAD IMMEDIATE,
and INSERT IMMEDIATE instruction groups.
Signed-off-by: Richard Henderson r...@twiddle.net
---
tcg/s390/tcg-target.c | 129
+++--
1 files changed, 113 insertions(+), 16 deletions(-)
diff --git a/tcg/s390/tcg-target.c b/tcg/s390/tcg-target.c
index d99bb5c..71e017a 100644
--- a/tcg/s390/tcg-target.c
+++ b/tcg/s390/tcg-target.c
@@ -52,12 +52,23 @@ typedef enum S390Opcode {
RIL_BRASL = 0xc005,
RIL_BRCL= 0xc004,
RIL_LARL= 0xc000,
+RIL_IIHF= 0xc008,
+RIL_IILF= 0xc009,
+RIL_LGFI= 0xc001,
+RIL_LLIHF = 0xc00e,
+RIL_LLILF = 0xc00f,
RI_AGHI = 0xa70b,
RI_AHI = 0xa70a,
RI_BRC = 0xa704,
+RI_IIHH = 0xa500,
+RI_IIHL = 0xa501,
RI_IILH = 0xa502,
+RI_IILL = 0xa503,
RI_LGHI = 0xa709,
+RI_LLIHH= 0xa50c,
+RI_LLIHL= 0xa50d,
+RI_LLILH= 0xa50e,
RI_LLILL= 0xa50f,
RRE_AGR = 0xb908,
@@ -382,24 +393,110 @@ static inline void tcg_out_mov(TCGContext *s, int ret,
int arg)
}
/* load a register with an immediate value */
-static inline void tcg_out_movi(TCGContext *s, TCGType type,
-int ret, tcg_target_long arg)
+static void tcg_out_movi(TCGContext *s, TCGType type,
+ TCGReg ret, tcg_target_long sval)
{
-if (arg = -0x8000 arg 0x8000) { /* signed immediate load */
-tcg_out_insn(s, RI, LGHI, ret, arg);
-} else if (!(arg 0xUL)) {
-tcg_out_insn(s, RI, LLILL, ret, arg);
-} else if (!(arg 0xUL) || type == TCG_TYPE_I32) {
-tcg_out_insn(s, RI, LLILL, ret, arg);
-tcg_out_insn(s, RI, IILH, ret, arg 16);
+static const S390Opcode lli_insns[4] = {
+RI_LLILL, RI_LLILH, RI_LLIHL, RI_LLIHH
+};
+
+tcg_target_ulong uval = sval;
+int i;
+
+if (type == TCG_TYPE_I32) {
+uval = (uint32_t)sval;
+sval = (int32_t)sval;
+}
+
+/* Try all 32-bit insns that can load it in one go. */
+if (sval = -0x8000 sval 0x8000) {
+tcg_out_insn(s, RI, LGHI, ret, sval);
+return;
+}
+
+for (i = 0; i 4; i++) {
+tcg_target_long mask = 0xull i*16;
+if ((uval mask) != 0 (uval ~mask) == 0) {
Wouldn't it be simpler to use (uval mask) == uval ?
+tcg_out_insn_RI(s, lli_insns[i], ret, uval i*16);
+return;
+}
+}
+
+/* Try all 48-bit insns that can load it in one go. */
+if (facilities FACILITY_EXT_IMM) {
+if (sval == (int32_t)sval) {
+tcg_out_insn(s, RIL, LGFI, ret, sval);
+return;
+}
+if (uval = 0x) {
+tcg_out_insn(s, RIL, LLILF, ret, uval);
+return;
+}
+if ((uval 0x) == 0) {
+tcg_out_insn(s, RIL, LLIHF, ret, uval 32);
+return;
+}
+}
+
+/* Try for PC-relative address load. */
+if ((sval 1) == 0) {
+intptr_t off = (sval - (intptr_t)s-code_ptr) 1;
+if (off == (int32_t)off) {
+tcg_out_insn(s, RIL, LARL, ret, off);
+return;
+}
+}
Is this part used in practice? There was such a trick on the ARM
backend, but it was actually never used.
+
+/* If extended immediates are not present, then we may have to issue
+ several instructions to load the low 32 bits. */
+if (!(facilities FACILITY_EXT_IMM)) {
+/* A 32-bit unsigned value can be loaded in 2 insns. And given
+ that the lli_insns loop above did not succeed, we know that
+ both insns are required. */
+if (uval = 0x) {
+tcg_out_insn(s, RI, LLILL, ret, uval);
+tcg_out_insn(s, RI, IILH, ret, uval 16);
+return;
+}
+
+/* If all high bits are set, the value can be loaded in 2 or 3 insns.
+ We first want to make sure that all the high bits get set. With
+ luck the low 16-bits can be considered negative to perform that
for
+ free, otherwise we load an explicit -1. */
+if (sval 32 == -1) {
+if (uval 0x8000) {
+tcg_out_insn(s, RI, LGHI, ret, uval);
+} else {
+tcg_out_insn(s, RI, LGHI, ret, -1);
+tcg_out_insn(s, RI, IILL, ret, uval);
+}
+tcg_out_insn(s, RI, IILH, ret, uval 16);
+return;
+}
+}
+
+/* If we get here, both the high and low parts have non-zero bits. */
+
+/* Recurse to load the lower 32-bits. */
+tcg_out_movi(s, TCG_TYPE_I32, ret, sval);
+
+/* Insert data into the high 32-bits. */
+
Re: [Qemu-devel] [PATCH 16/35] tcg-s390: Re-implement tcg_out_movi.
On 06/12/2010 05:04 AM, Aurelien Jarno wrote:
+for (i = 0; i 4; i++) {
+tcg_target_long mask = 0xull i*16;
+if ((uval mask) != 0 (uval ~mask) == 0) {
Wouldn't it be simpler to use (uval mask) == uval ?
Doh.
+/* Try for PC-relative address load. */
+if ((sval 1) == 0) {
+intptr_t off = (sval - (intptr_t)s-code_ptr) 1;
+if (off == (int32_t)off) {
+tcg_out_insn(s, RIL, LARL, ret, off);
+return;
+}
+}
Is this part used in practice? There was such a trick on the ARM
backend, but it was actually never used.
Yes. The difference here is we have a +- 4GB displacement.
This is primarily used when the extended-immediate facility is not present;
we can generate all even 32-bit constants from LARL, given the placement of
the code_gen_buffer.
r~
[Qemu-devel] I want to implement our own architecture in QEMU, you have any idea?
Hello, all! As my project, I want to implement our own architecture in QEMU(like arm, sparc, ect) , but unfortunately I am new to this area. I just want to know whether I can fix or revise QEMU, and it is possible to use revised QEMU as a emulator. First, I downloaded qemu-0.12.4 and I notice that there are several architecture dependant area like target-arm, target-i386, ect. If I make a target, can I use it? Plz, help me!! Thanks in advance. Young
[Qemu-devel] about qemu monitor
Hi I created a full virtualized DOM-U by XEN which is emulated by qemu-dm, and I dont know hot to monitor it's disk and network in DOM-0. I know I can press CTRL-ALT-2 to access the monitor, but it should be done in dom-U. Is there any solution to get the disk and network information of dom-U in dom-0? If I can output the monitoring result to a file is better Thanks.
Re: [Qemu-devel] Re: [PATCH] pass info about hpets to seabios.
On Sun, Jun 13, 2010 at 08:55:23PM +0100, Paul Brook wrote: And I think we can move the capability setup into init. But this is not directly related to this patch, would just avoid adding this hunk to hpet_reset. I actually did that initially and tried to init hpet_cfg there too, but then noticed that mmio[0].addr below is not initialized at init time yet. +hpet_cfg.hpet.address = sysbus_from_qdev(d)-mmio[0].addr; This is one of the reasons that you're not supposed to be messing with DeviceState contents directly. Alternatives? -- Gleb.
Re: [Qemu-devel] [PATCH 09/16] Enable message delivery via IRQs
On Sun, Jun 13, 2010 at 05:34:24PM +0100, Paul Brook wrote: TBH I preferred the original system whereby the source can query the state of the sink (i.e are you ignoring this line?). Note that conceptually this should be *querying* state, not responding to an event. People are still pushing qemu_irq as an message passing interface, so I'm going to expand a bit more on how I think this could be avoided. Please, please, please write code and show how it solves existing problems. Code talks much better then words. Start with the assumption that qemu irq represents a single bit of information. The current implementation is stateless, but in principle it could remember its state and ignore redundant calls to qemu_set_irq. And I don't see why it will affect proposed implementation. Device should not call qemu_set_irq() with the same state twice anyway. Some device's implementations are lazy so they don't track previous state, but this is just implementation detail. In order to workaround the periodic timer issue, we need some way of for the source device to interrogate the target device state relating to this link. The suggestions so far are along the lines of what happened when I made this change. This makes me unhappy, because it's overlaying event semantics on top of a state based system. Instead I suggest that we should be describing what the target state associated with this input is. Suitable return values could be: * normal: This input effects the state of the target device. Note that this need not imply that changing the input actually effects the output at this time. e.g. if an interrupt controller is already processing a higher priority input, the low priority inputs should still return normal - the input will be processed once the unrelated high priority input is finished. * latched: This input has already effected target device state, and will be ignored until reset by some external event. Typically means an interrupt controller latches its inputs, and this input has already been latched. * masked: This input is ignored. In practice these should give approximately the same information as event based delivered/coalesced/dropped responses. The difference is that they are consistent with the state based nature of qemu_irq. You just described what was proposed by Jan, you just not agree that it should be done on top of qemu_irq without proposing any alternatives. The problem is that device doesn't know what its target is and it can have multiple targets (that is why hack that exist today works only for one particular configuration as Blue Swirl found out the hard way). qemu_irq traverses the dynamic chain of links that connects source and its destinations, and thus device itself doesn't need to know what its destinations are. -- Gleb.
[Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string
This is a follow-up to my ramblock overhaul RFC series. In trying to come up with a useful name to give to a ramblock, we seemed to be leaning towards something that represents the existing qdev hierarchy rather than creating an arbitrary new namespace. I had some pointers that I should use the savevm name/instance in the interim, but that has a number of issues (private to savevm, typically setup too late, inconsistent). So, I decided to look at what should the savevm string be, with hopes that if we could figure that out, we can then stuff the resulting string into both the savevm list and the ramblocks. This is a stab at doing that. My premise with this attempt is that we walk the hierarchy and use the names to create the base of the path. As we get to the device, particularly to the parent bus of the device, we need to start looking at properties to ensure uniqueness. However, we don't want to use all the properties or else any properties added or removed from a device will cause migration failures. For now, the only properties I've tagged as path properties are PCI bus addresses and MAC addresses. It turns out the MAC isn't needed in most cases since they're typically PCI based, but I left it in in case someone figures out how to make multiple instances of ne2k_isa work (or non-PCI based NICs on other archs). In any case, these seem like they should be stable properties for a device. I've compiled all the archs, but I've only actually run x86_64-system. For a well populated VM, here's what got used as id strings in the savevm_handlers list: timer slirp slirp slirp slirp slirp block ram cpu_common cpu apic fw_cfg i8259 i8259 ioapic PCIBUS /main-system-bus/pci.0,addr=00.0/i440FX/I440FX /main-system-bus/pci.0,addr=01.0/PIIX3/PIIX3 /main-system-bus/pci.0,addr=02.0/cirrus-vga/cirrus_vga /main-system-bus/pci.0/isa.0/mc146818rtc/mc146818rtc i8254 hpet /main-system-bus/pci.0/isa.0/isa-serial/serial ps2kbd ps2mouse /main-system-bus/pci.0/isa.0/i8042/pckbd vmmouse dma dma /main-system-bus/pci.0/isa.0/isa-fdc/fdc /main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/eeprom /main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/i82551 /main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57/virtio-net /main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58/e1000 /main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59/rtl8139 /main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a/pcnet /main-system-bus/pci.0,addr=01.1/piix3-ide/ide i2c_bus /main-system-bus/pci.0,addr=01.3/PIIX4_PM/piix4_pm /main-system-bus/pci.0,addr=08.0/lsi53c895a/lsiscsi /main-system-bus/pci.0,addr=09.0/virtio-blk-pci/virtio-blk Let me know what you think. Thanks, Alex --- Alex Williamson (5): virtio-net: Incorporate a DeviceState pointer and let savevm track instances eepro100: Add a dev field to eeprom new/free functions savevm: Make use of the new DeviceState param savevm: Add DeviceState param qdev: Create qdev_get_dev_path() audio/audio.c |2 - block-migration.c |2 - exec.c |4 +- hw/adb.c |4 +- hw/ads7846.c |2 - hw/apic.c |2 - hw/arm_gic.c |2 - hw/arm_timer.c |4 +- hw/armv7m_nvic.c |2 - hw/cirrus_vga.c|2 - hw/cuda.c |2 - hw/dma.c |4 +- hw/eepro100.c |8 ++-- hw/eeprom93xx.c|8 ++-- hw/eeprom93xx.h|4 +- hw/fw_cfg.c|2 - hw/g364fb.c|2 - hw/grackle_pci.c |4 +- hw/gt64xxx.c |3 + hw/heathrow_pic.c |2 - hw/hpet.c |2 - hw/hw.h| 18 +--- hw/i2c.c |2 - hw/i8254.c |2 - hw/i8259.c |2 - hw/ide/cmd646.c|2 - hw/ide/isa.c |2 - hw/ide/macio.c |2 - hw/ide/microdrive.c|2 - hw/ide/mmio.c |2 - hw/ide/piix.c |2 - hw/ioapic.c|2 - hw/m48t59.c|2 - hw/mac_dbdma.c |2 - hw/mac_nvram.c |2 - hw/max111x.c |3 + hw/mipsnet.c |4 +- hw/mst_fpga.c |2 - hw/nand.c |2 - hw/openpic.c |5 +- hw/pci.c |2 - hw/pckbd.c |2 - hw/piix4.c |2 - hw/pl011.c |2 - hw/pl022.c |2 - hw/pl061.c |2 - hw/ppc4xx_pci.c|4 +- hw/ppce500_pci.c |4 +- hw/ps2.c |4 +- hw/pxa2xx.c| 24 +-- hw/pxa2xx_dma.c|2 - hw/pxa2xx_gpio.c |2 - hw/pxa2xx_keypad.c |2 - hw/pxa2xx_lcd.c|2 - hw/pxa2xx_mmci.c |2 - hw/pxa2xx_pic.c|2 - hw/pxa2xx_timer.c |2 - hw/qdev-properties.c |2 +
[Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
qdev_get_dev_path() is intended to be the canonical utility for creating
a string representing the qdev hierarchy of a device. The path consists
of bus and device names as well as identified properties of the immediate
parent bus and device. This results in strings like:
/main-system-bus/pci.0,addr=00.0/i440FX
/main-system-bus/pci.0,addr=01.0/PIIX3
/main-system-bus/pci.0,addr=02.0/cirrus-vga
/main-system-bus/pci.0/isa.0/mc146818rtc
/main-system-bus/pci.0/isa.0/isa-serial
/main-system-bus/pci.0/isa.0/i8042
/main-system-bus/pci.0/isa.0/isa-fdc
/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56
/main-system-bus/pci.0,addr=04.0/virtio-net-pci,mac=52:54:00:12:34:57
/main-system-bus/pci.0,addr=05.0/e1000,mac=52:54:00:12:34:58
/main-system-bus/pci.0,addr=06.0/rtl8139,mac=52:54:00:12:34:59
/main-system-bus/pci.0,addr=07.0/pcnet,mac=52:54:00:12:34:5a
/main-system-bus/pci.0,addr=01.1/piix3-ide
/main-system-bus/pci.0,addr=01.3/PIIX4_PM
/main-system-bus/pci.0,addr=08.0/lsi53c895a
/main-system-bus/pci.0,addr=09.0/virtio-blk-pci
There are two primary targets for these strings. The first is vmsave, where
we currently use a device provided string plus instance number to track
SaveStateEntries. This fails when we introduce device hotplug, particularly
in a case were we have gaps in the instance numbers that cannot easily be
reproduced on a migration target. The second is for naming RAMBlocks. For
these, we would like a string that matches the vmstate string.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/qdev-properties.c |2 ++
hw/qdev.c| 57 ++
hw/qdev.h|5
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
index 9ffdba7..e30df88 100644
--- a/hw/qdev-properties.c
+++ b/hw/qdev-properties.c
@@ -453,6 +453,7 @@ PropertyInfo qdev_prop_macaddr = {
.name = macaddr,
.type = PROP_TYPE_MACADDR,
.size = sizeof(MACAddr),
+.flags = PROP_FLAG_PATH,
.parse = parse_mac,
.print = print_mac,
};
@@ -496,6 +497,7 @@ PropertyInfo qdev_prop_pci_devfn = {
.name = pci-devfn,
.type = PROP_TYPE_UINT32,
.size = sizeof(uint32_t),
+.flags = PROP_FLAG_PATH,
.parse = parse_pci_devfn,
.print = print_pci_devfn,
};
diff --git a/hw/qdev.c b/hw/qdev.c
index 36f29ea..dea44fe 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -120,6 +120,63 @@ DeviceState *qdev_create(BusState *bus, const char *name)
return qdev_create_from_info(bus, info);
}
+static int qdev_strprint_parent_path(DeviceState *dev, char *buf, size_t len)
+{
+int offset = 0;
+
+if (dev-parent_bus dev-parent_bus-parent)
+offset = qdev_strprint_parent_path(dev-parent_bus-parent, buf, len);
+
+offset += snprintf(buf + offset, len - offset,
+/%s, dev-parent_bus-name);
+return offset;
+}
+
+static int qdev_strprint_path_props(DeviceState *dev, Property *props,
+char *buf, size_t len)
+{
+int offset = 0;
+char pbuf[64];
+
+if (!props)
+return 0;
+
+while (props-name) {
+if (props-info-flags PROP_FLAG_PATH) {
+if (props-info-print) {
+props-info-print(dev, props, pbuf, sizeof(pbuf));
+offset += snprintf(buf + offset, len - offset, ,%s=%s,
+ props-name, pbuf);
+}
+}
+props++;
+}
+return offset;
+}
+
+char *qdev_get_dev_path(DeviceState *dev)
+{
+char buf[256] = ;
+int offset;
+
+if (!dev)
+return NULL;
+
+offset = qdev_strprint_parent_path(dev, buf, sizeof(buf));
+
+offset += qdev_strprint_path_props(dev, dev-parent_bus-info-props,
+ buf + offset, sizeof(buf) - offset);
+
+offset += snprintf(buf + offset, sizeof(buf) - offset, /%s,
+ dev-info-name);
+if (dev-id)
+offset += snprintf(buf + offset, sizeof(buf) - offset, -%s, dev-id);
+
+offset += qdev_strprint_path_props(dev, dev-info-props,
+ buf + offset, sizeof(buf) - offset);
+return qemu_strdup(buf);
+}
+
static void qdev_print_devinfo(DeviceInfo *info)
{
error_printf(name \%s\, bus %s,
diff --git a/hw/qdev.h b/hw/qdev.h
index a44060e..2702384 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -96,6 +96,7 @@ struct PropertyInfo {
const char *name;
size_t size;
enum PropertyType type;
+int flags;
int (*parse)(DeviceState *dev, Property *prop, const char *str);
int (*print)(DeviceState *dev, Property *prop, char *dest, size_t len);
};
@@ -201,6 +202,8 @@ extern PropertyInfo qdev_prop_netdev;
extern PropertyInfo qdev_prop_vlan;
extern PropertyInfo qdev_prop_pci_devfn;
+#define PROP_FLAG_PATH(10)
+
#define DEFINE_PROP(_name, _state, _field, _prop, _type) { \
.name = (_name),
[Qemu-devel] [RFC PATCH 3/5] savevm: Make use of the new DeviceState param
Use the now passed in DeviceState along with qdev_get_dev_path() to
create meaningful id strings for the SaveStateEntry. We append the
driver provided string so we can differentiate multiple savevm
handlers per device:
/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/eeprom
/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/i82551
We also introduce compatibility fields so that we can attempt to
import savevm data from an older VM. These should be deprecated and
removed at some point.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
savevm.c | 83 +-
1 files changed, 76 insertions(+), 7 deletions(-)
diff --git a/savevm.c b/savevm.c
index 81d544f..4cc542b 100644
--- a/savevm.c
+++ b/savevm.c
@@ -1002,6 +1002,8 @@ typedef struct SaveStateEntry {
LoadStateHandler *load_state;
const VMStateDescription *vmsd;
void *opaque;
+char compat_idstr[256];
+int compat_instance_id;
} SaveStateEntry;
@@ -1023,6 +1025,20 @@ static int calculate_new_instance_id(const char *idstr)
return instance_id;
}
+static int calculate_new_compat_instance_id(const char *idstr)
+{
+SaveStateEntry *se;
+int instance_id = 0;
+
+QTAILQ_FOREACH(se, savevm_handlers, entry) {
+if (strcmp(idstr, se-compat_idstr) == 0
+ instance_id = se-compat_instance_id) {
+instance_id = se-compat_instance_id + 1;
+}
+}
+return instance_id;
+}
+
/* TODO: Individual devices generally have very little idea about the rest
of the system, so instance_id should be removed/replaced.
Meanwhile pass -1 as instance_id if you do not already have a clearly
@@ -1040,7 +1056,16 @@ int register_savevm_live(DeviceState *dev,
SaveStateEntry *se;
se = qemu_mallocz(sizeof(SaveStateEntry));
-pstrcpy(se-idstr, sizeof(se-idstr), idstr);
+
+if (dev) {
+char *path = qdev_get_dev_path(dev);
+pstrcpy(se-idstr, sizeof(se-idstr), path);
+pstrcat(se-idstr, sizeof(se-idstr), /);
+pstrcat(se-idstr, sizeof(se-idstr), idstr);
+qemu_free(path);
+} else {
+pstrcpy(se-idstr, sizeof(se-idstr), idstr);
+}
se-version_id = version_id;
se-section_id = global_section_id++;
se-set_params = set_params;
@@ -1050,11 +1075,19 @@ int register_savevm_live(DeviceState *dev,
se-opaque = opaque;
se-vmsd = NULL;
+pstrcpy(se-compat_idstr, sizeof(se-idstr), idstr);
if (instance_id == -1) {
-se-instance_id = calculate_new_instance_id(idstr);
+se-instance_id = calculate_new_instance_id(se-idstr);
+se-compat_instance_id = calculate_new_compat_instance_id(idstr);
} else {
-se-instance_id = instance_id;
+se-instance_id = se-compat_instance_id = instance_id;
+}
+
+if (dev instance_id == -1 se-instance_id != 0) {
+fprintf(stderr, %s: Failed to create unqiue path \%s\\n,
+__FUNCTION__, se-idstr);
}
+
/* add at the end of list */
QTAILQ_INSERT_TAIL(savevm_handlers, se, entry);
return 0;
@@ -1075,13 +1108,25 @@ int register_savevm(DeviceState *dev,
void unregister_savevm(DeviceState *dev, const char *idstr, void *opaque)
{
SaveStateEntry *se, *new_se;
+char *path;
+
+if (dev) {
+int len;
+path = qdev_get_dev_path(dev);
+len = strlen(path);
+path = qemu_realloc(path, len + strlen(idstr) + 2);
+sprintf(path + len, /%s, idstr);
+} else {
+path = qemu_strdup(idstr);
+}
QTAILQ_FOREACH_SAFE(se, savevm_handlers, entry, new_se) {
-if (strcmp(se-idstr, idstr) == 0 se-opaque == opaque) {
+if (strcmp(se-idstr, path) == 0 se-opaque == opaque) {
QTAILQ_REMOVE(savevm_handlers, se, entry);
qemu_free(se);
}
}
+qemu_free(path);
}
int vmstate_register_with_alias_id(DeviceState *dev, int instance_id,
@@ -1095,7 +1140,16 @@ int vmstate_register_with_alias_id(DeviceState *dev, int
instance_id,
assert(alias_id == -1 || required_for_version = vmsd-minimum_version_id);
se = qemu_mallocz(sizeof(SaveStateEntry));
-pstrcpy(se-idstr, sizeof(se-idstr), vmsd-name);
+
+if (dev) {
+char *path = qdev_get_dev_path(dev);
+pstrcpy(se-idstr, sizeof(se-idstr), path);
+pstrcat(se-idstr, sizeof(se-idstr), /);
+pstrcat(se-idstr, sizeof(se-idstr), vmsd-name);
+qemu_free(path);
+} else {
+pstrcpy(se-idstr, sizeof(se-idstr), vmsd-name);
+}
se-version_id = vmsd-version_id;
se-section_id = global_section_id++;
se-save_live_state = NULL;
@@ -1105,11 +1159,19 @@ int vmstate_register_with_alias_id(DeviceState *dev,
int instance_id,
se-vmsd = vmsd;
se-alias_id = alias_id;
+pstrcpy(se-compat_idstr, sizeof(se-idstr), vmsd-name);
if (instance_id == -1) {
-se-instance_id =
