[Qemu-devel] Re: [PATCH 09/26] dec_pci: simplify dec_pci.c by using pci_p2pbr
On Wed, Mar 16, 2011 at 11:29 AM, Isaku Yamahata yamah...@valinux.co.jp wrote:
apply pci_p2pbr for dec_pci.c.
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/dec_pci.c | 49 ++---
1 files changed, 14 insertions(+), 35 deletions(-)
diff --git a/hw/dec_pci.c b/hw/dec_pci.c
index 3cc4f04..fbd1363 100644
--- a/hw/dec_pci.c
+++ b/hw/dec_pci.c
@@ -29,6 +29,7 @@
#include pci_host.h
#include pci_bridge.h
#include pci_internals.h
+#include pci_p2pbr.h
/* debug DEC */
//#define DEBUG_DEC
@@ -50,42 +51,21 @@ static int dec_map_irq(void *opaque, PCIDevice *pci_dev,
int irq_num)
return irq_num;
}
-static int dec_21154_initfn(PCIDevice *dev)
-{
- int rc;
-
- rc = pci_bridge_initfn(dev);
- if (rc 0) {
- return rc;
- }
-
- pci_config_set_vendor_id(dev-config, PCI_VENDOR_ID_DEC);
- pci_config_set_device_id(dev-config, PCI_DEVICE_ID_DEC_21154);
- return 0;
-}
-
-static PCIDeviceInfo dec_21154_pci_bridge_info = {
- .qdev.name = dec-21154-p2p-bridge,
- .qdev.desc = DEC 21154 PCI-PCI bridge,
- .qdev.size = sizeof(PCIBridge),
- .qdev.vmsd = vmstate_pci_device,
- .qdev.reset = pci_bridge_reset,
- .init = dec_21154_initfn,
- .exit = pci_bridge_exitfn,
- .config_write = pci_bridge_write_config,
- .is_bridge = 1,
-};
-
PCIBus *pci_dec_21154_init(PCIBus *parent_bus, int devfn)
{
- PCIDevice *dev;
- PCIBridge *br;
-
- dev = pci_create_multifunction(parent_bus, devfn, false,
- dec-21154-p2p-bridge);
- br = DO_UPCAST(PCIBridge, dev, dev);
- pci_bridge_map_irq(br, DEC 21154 PCI-PCI bridge, dec_map_irq);
- qdev_init_nofail(dev-qdev);
+ const PCIP2PBridgeInit init = {
+ .bus = parent_bus,
+ .devfn = devfn,
+ .multifunction = false,
+
+ .bus_name = DEC 21154 PCI-PCI bridge,
+ .map_irq = dec_map_irq,
+ };
+ const PCIP2PBridgeProp prop = {
+ .vendor_id = PCI_VENDOR_ID_DEC,
+ .device_id = PCI_DEVICE_ID_DEC_21154,
+ };
I'd make the above structures static.
+ PCIBridge *br = pci_p2pbr_create_simple(init, prop);
return pci_bridge_get_sec_bus(br);
}
@@ -127,7 +107,6 @@ static void dec_register_devices(void)
sysbus_register_dev(dec-21154, sizeof(DECState),
pci_dec_21154_init_device);
pci_qdev_register(dec_21154_pci_host_info);
- pci_qdev_register(dec_21154_pci_bridge_info);
}
device_init(dec_register_devices)
--
1.7.1.1
[Qemu-devel] Re: [PATCH 08/26] apb_pci: simplify apb_pci.c by using pci_p2pbr
On Wed, Mar 16, 2011 at 11:29 AM, Isaku Yamahata yamah...@valinux.co.jp wrote:
apply pci_p2pbr for apb_pci.c.
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/apb_pci.c | 63 -
1 files changed, 27 insertions(+), 36 deletions(-)
diff --git a/hw/apb_pci.c b/hw/apb_pci.c
index c56ea9a..c9f2a6b 100644
--- a/hw/apb_pci.c
+++ b/hw/apb_pci.c
@@ -31,6 +31,7 @@
#include pci_host.h
#include pci_bridge.h
#include pci_internals.h
+#include pci_p2pbr.h
#include rwhandler.h
#include apb_pci.h
#include sysemu.h
@@ -297,16 +298,6 @@ static void pci_apb_set_irq(void *opaque, int irq_num,
int level)
static int apb_pci_bridge_initfn(PCIDevice *dev)
{
- int rc;
-
- rc = pci_bridge_initfn(dev);
- if (rc 0) {
- return rc;
- }
-
- pci_config_set_vendor_id(dev-config, PCI_VENDOR_ID_SUN);
- pci_config_set_device_id(dev-config, PCI_DEVICE_ID_SUN_SIMBA);
-
/*
* command register:
* According to PCI bridge spec, after reset
@@ -321,10 +312,31 @@ static int apb_pci_bridge_initfn(PCIDevice *dev)
pci_set_word(dev-config + PCI_STATUS,
PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ |
PCI_STATUS_DEVSEL_MEDIUM);
- pci_set_byte(dev-config + PCI_REVISION_ID, 0x11);
return 0;
}
+static PCIBridge *apb_pci_bridge_init(PCIBus *bus,
+ uint8_t devfn, const char *bus_name)
+{
+ const PCIP2PBridgeInit init = {
+ .bus = bus,
+ .devfn = devfn,
+ .multifunction = true,
+
+ .bus_name = bus_name,
+ .map_irq = pci_apb_map_irq,
+
+ .initfn = apb_pci_bridge_initfn,
+ };
+ const PCIP2PBridgeProp prop = {
+ .vendor_id = PCI_VENDOR_ID_SUN,
+ .device_id = PCI_DEVICE_ID_SUN_SIMBA,
+ .revision_id = 0x11,
+ };
'static' again.
Re: [Qemu-devel] [PATCH 13/26] usb/uhci: add ich9 usb uhci id's device
On Wed, Mar 16, 2011 at 11:29 AM, Isaku Yamahata yamah...@valinux.co.jp wrote:
add uhci device which has ich9 device id.
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/pci_ids.h | 2 ++
hw/usb-uhci.c | 8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index ea3418c..9daea23 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -108,3 +108,5 @@
#define PCI_DEVICE_ID_INTEL_82371AB 0x7111
#define PCI_DEVICE_ID_INTEL_82371AB_2 0x7112
#define PCI_DEVICE_ID_INTEL_82371AB_3 0x7113
+
+#define PCI_DEVICE_ID_INTEL_ICH9_UCHI1 0x2934
s/UCHI/UHCI/g
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 2fb2a85..247f1bf 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1193,6 +1193,14 @@ static UHCIDeviceInfo uhci_info[] = {
.device_id = PCI_DEVICE_ID_INTEL_82371AB_2,
.revision_id = 0x01,
},{
+ .pci.qdev.name = ich9-usb-uhci1,
+ .pci.qdev.size = sizeof(UHCIState),
+ .pci.qdev.vmsd = vmstate_uhci,
+ .pci.init = usb_uhci_common_initfn,
+ .vendor_id = PCI_VENDOR_ID_INTEL,
+ .device_id = PCI_DEVICE_ID_INTEL_ICH9_UCHI1,
+ .revision_id = 0x03,
+ },{
.pci.qdev.name = vt82c686b-usb-uhci,
.pci.qdev.size = sizeof(UHCIState),
.pci.qdev.vmsd = vmstate_uhci,
--
1.7.1.1
Re: [Qemu-devel] [PATCH 21/26] acpi, acpi_piix: factor out PM_TMR logic
On Wed, Mar 16, 2011 at 11:29 AM, Isaku Yamahata yamah...@valinux.co.jp wrote: factor out PM_TMR logic. Later This will be used by ich9 acpi. Please also refactor vt82c686.c.
Re: [Qemu-devel] [PATCH 22/26] acpi, acpi_piix: factor out PM1a EVT logic
On Wed, Mar 16, 2011 at 11:29 AM, Isaku Yamahata yamah...@valinux.co.jp wrote: factor out ACPI PM1a EVT logic. Later this will be used by ich9 acpi. Also this logic is duplicated in vt82c686.c.
Re: [Qemu-devel] [PATCH 2/4] block: add a helper to change writeback mode on the fly
On Thu, Mar 17, 2011 at 6:44 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
On Thu, Mar 17, 2011 at 3:11 PM, Kevin Wolf kw...@redhat.com wrote:
Am 17.03.2011 15:44, schrieb Daniel P. Berrange:
On Tue, Mar 15, 2011 at 03:11:32PM +0100, Christoph Hellwig wrote:
Add a new bdrv_change_cache that can set/clear the writeback flag
at runtime by stopping all I/O and closing/reopening the image file.
All code is based on a patch from Prerna Saxena pre...@linux.vnet.ibm.com
with minimal refactoring.
Signed-off-by: Christoph Hellwig h...@lst.de
+static int bdrv_reopen(BlockDriverState *bs, int bdrv_flags)
+{
+ BlockDriver *drv = bs-drv;
+ int ret;
+
+ if (bdrv_flags == bs-open_flags) {
+ return 0;
+ }
+
+ /* Quiesce IO for the given block device */
+ qemu_aio_flush();
+ bdrv_flush(bs);
+
+ bdrv_close(bs);
+ ret = bdrv_open(bs, bs-filename, bdrv_flags, drv);
+
+ /*
+ * A failed attempt to reopen the image file must lead to 'abort()'
+ */
+ if (ret != 0) {
+ abort();
+ }
+
+ return ret;
+}
+
+int bdrv_change_cache(BlockDriverState *bs, bool enable)
+{
+ int bdrv_flags = 0;
+
+ bdrv_flags = bs-open_flags ~BDRV_O_CACHE_WB;
+ if (enable) {
+ bdrv_flags |= BDRV_O_CACHE_WB;
+ }
+
+ return bdrv_reopen(bs, bdrv_flags);
+}
Is there any way we can manage todo this *without* closing and
re-opening the file descriptor ?
One of the things we're considering for the future is to enable
QEMU to be passed open FD(s) for its drives, from the management
system, instead of having QEMU open the files itself.
What about cache mode, read-only flags etc. that are set with the right
flags during the open? Must qemu just assume that the management has
done the right thing?
And what about things like backing files or other information that
depends on the content of the image file?
If QEMU expects to close+reopen any of its disks at any time the
guest requests, this will complicate life somewhat
It does expect this. For example for making backing files temporarily
read-write during a 'commit' monitor command, we already reopen the
image. (Let's hope nobody uses -snapshot, live snapshots and commit, he
would lose his disk...)
I think we need to use the most robust solution possible. We don't
want to get into a situation that can be avoided. Especially in cases
where human errors can (==will) be made.
I suggested using /proc/$pid/fd to reopen an existing file descriptor.
That interface is only available on Linux and possibly some of
{Solaris, *BSD, OSX}. So there needs to be a fallback, but in this
situation it feels right to take advantage of whatever means are
provided by the host OS to make safe transitions between image files.
No need for such hacks. There could be an explicit reopen method,
which could be implemented differently for each backing file type
(file descriptor, file, socket, CDROM devices etc).
[Qemu-devel] Re: [PATCH] i8254: Fix migration from older versions
Thanks, applied. On Fri, Mar 18, 2011 at 12:48 PM, Jan Kiszka jan.kis...@web.de wrote: On 2011-03-06 16:09, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com qdev conversion broke migration as the previous version used vmstate instance IDs derived from the iobase. Fix it by registering a legacy alias. Signed-off-by: Jan Kiszka jan.kis...@siemens.com --- hw/i8254.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/i8254.c b/hw/i8254.c index eaf5d3e..47c9d73 100644 --- a/hw/i8254.c +++ b/hw/i8254.c @@ -520,6 +520,8 @@ static int pit_initfn(ISADevice *dev) register_ioport_read(pit-iobase, 3, 1, pit_ioport_read, pit); isa_init_ioport(dev, pit-iobase); + qdev_set_legacy_instance_id(dev-qdev, pit-iobase, 2); + return 0; } This bug is still open. Jan
[Qemu-devel] Re: [PATCH] w32: Add missing functions qemu_mutex_destroy, qemu_cond_destroy
Thanks, applied.
On Sat, Mar 19, 2011 at 12:39 AM, Stefan Weil w...@mail.berlios.de wrote:
Am 13.03.2011 19:00, schrieb Stefan Weil:
These functions were missing in commit
9257d46d55f1fe4e8209be9a6870e339ac3266fe.
Both functions are needed for compilations with
configuration --enable-vnc-thread.
Cc: Paolo Bonzini pbonz...@redhat.com
Cc: Blue Swirl blauwir...@gmail.com
Signed-off-by: Stefan Weil w...@mail.berlios.de
---
qemu-thread-win32.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/qemu-thread-win32.c b/qemu-thread-win32.c
index 2edcb1a..2d2d5ab 100644
--- a/qemu-thread-win32.c
+++ b/qemu-thread-win32.c
@@ -33,6 +33,12 @@ void qemu_mutex_init(QemuMutex *mutex)
InitializeCriticalSection(mutex-lock);
}
+void qemu_mutex_destroy(QemuMutex *mutex)
+{
+ assert(mutex-owner == 0);
+ DeleteCriticalSection(mutex-lock);
+}
+
void qemu_mutex_lock(QemuMutex *mutex)
{
EnterCriticalSection(mutex-lock);
@@ -80,6 +86,21 @@ void qemu_cond_init(QemuCond *cond)
}
}
+void qemu_cond_destroy(QemuCond *cond)
+{
+ BOOL result;
+ result = CloseHandle(cond-continue_event);
+ if (!result) {
+ error_exit(GetLastError(), __func__);
+ }
+ cond-continue_event = 0;
+ result = CloseHandle(cond-sema);
+ if (!result) {
+ error_exit(GetLastError(), __func__);
+ }
+ cond-sema = 0;
+}
+
void qemu_cond_signal(QemuCond *cond)
{
DWORD result;
No comments? Why is is so difficult to get compilation problems fixed?
Re: [Qemu-devel] OSX build issues
On Tue, Mar 15, 2011 at 11:03 PM, Blue Swirl blauwir...@gmail.com wrote: On Mon, Mar 14, 2011 at 11:21 PM, François Revol re...@free.fr wrote: The OSX build has been broken for some time now... * qemu-thread-posix.c: both qemu_mutex_timedlock and qemu_cond_timedwait make use of clock_gettime() and CLOCK_REALTIME, which OSX doesn't have. It seems like both functions are nowhere found. Can they be removed then ? This patch should fix the problem. I applied the patch.
[Qemu-devel] [PATCH] petalogix_ml605_mmu: remove unused variable
Remove a write-only variable, spotted by GCC 4.6.0:
/src/qemu/hw/petalogix_ml605_mmu.c: In function 'petalogix_ml605_init':
/src/qemu/hw/petalogix_ml605_mmu.c:153:11: error: variable 'serial'
set but not used [-Werror=unused-but-set-variable]
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
hw/petalogix_ml605_mmu.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
index ca0986a..8213902 100644
--- a/hw/petalogix_ml605_mmu.c
+++ b/hw/petalogix_ml605_mmu.c
@@ -150,7 +150,6 @@ petalogix_ml605_init(ram_addr_t ram_size,
ram_addr_t phys_ram;
ram_addr_t phys_flash;
qemu_irq irq[32], *cpu_irq;
-void *serial = NULL;
/* init CPUs */
if (cpu_model == NULL) {
@@ -185,8 +184,8 @@ petalogix_ml605_init(ram_addr_t ram_size,
irq[i] = qdev_get_gpio_in(dev, i);
}
-serial = serial_mm_init(UART16550_BASEADDR + 0x1000, 2, irq[5],
-115200, serial_hds[0], 1, 0);
+serial_mm_init(UART16550_BASEADDR + 0x1000, 2, irq[5], 115200,
+ serial_hds[0], 1, 0);
/* 2 timers at irq 2 @ 100 Mhz. */
xilinx_timer_create(TIMER_BASEADDR, irq[2], 2, 100 * 100);
--
1.6.2.4
[Qemu-devel] Re: [PATCH 3/3] alleviate time drift with HPET periodic timers
On 2011-03-18 16:55, Ulrich Obergfell wrote: Part 3 of the patch implements the following options for the 'configure' script. --disable-hpet-driftfix --enable-hpet-driftfix I see no benefit in this configurability. Just make the driftfix unconditionally available, runtime-disabled by default for now until it matured and there is no downside in enabling it all the time. Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Re: [PATCH 1/3] alleviate time drift with HPET periodic timers
On 2011-03-18 16:54, Ulrich Obergfell wrote: Part 1 of the patch implements the following QEMU command line option. -hpet [device=none|present][,driftfix=none|slew] Just define driftfix as property of the hpet device. That way it can be controlled both globally (-global hpet.driftfix=...) and per hpet block (once we support instantiating 1 of them). Jan signature.asc Description: OpenPGP digital signature
[Qemu-devel] Does any version of QEMU support EFI?
Hi, I want to know which version of QEMU support EFI? I don't find any code to do with the EFI in the QEMU source code. So, is it that QEMU doesn't support EFI? Any help will be appreciated. Thank you. Yours Sincerely, Bei Guan
[Qemu-devel] Re: vcpu hotplug status
On Wed, Mar 16, 2011 at 11:17 AM, William Dauchy wdau...@gmail.com wrote: I wanted to test vcpu hotplug. When adding a cpu I'm getting qdev_create_from_info: Assertion `bus-allow_hotplug' failed. I went through a discussion about the subject here http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00999.html To make sure whether it was working, I hard-coded allow_hotplug = 1; the guest is now able to have more vpcus without any trouble (removing vcpus did not seem to work though). Since it definitively not a solution, I wanted to have a status about the subject or if I was missing something in my configuration since it works with a dirty workaround. I would be also pleased to get some tips to fix the code. Any thoughts? Or perhaps my message was lost among patches... -- William
[Qemu-devel] [PATCH v3 2/3] piix_pci: eliminate PIIX3State::pci_irq_levels
PIIX3State::pci_irq_levels are redundant which is already tracked by
PCIBus layer. So eliminate them.
Cc: Juan Quintela quint...@redhat.com
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Changes v2 - v3:
- rename member s/dummy_for_save_load_compat/pci_irq_levels_vmstate/g
---
hw/piix_pci.c | 33 +++--
1 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index 358da58..e88df43 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -39,8 +39,10 @@ typedef PCIHostState I440FXState;
typedef struct PIIX3State {
PCIDevice dev;
-int pci_irq_levels[4];
qemu_irq *pic;
+
+/* This member isn't used. Just for save/load compatibility */
+int32_t pci_irq_levels_vmstate[4];
} PIIX3State;
struct PCII440FXState {
@@ -162,9 +164,11 @@ static int i440fx_load_old(QEMUFile* f, void *opaque, int
version_id)
i440fx_update_memory_mappings(d);
qemu_get_8s(f, d-smm_enabled);
-if (version_id == 2)
-for (i = 0; i 4; i++)
-d-piix3-pci_irq_levels[i] = qemu_get_be32(f);
+if (version_id == 2) {
+for (i = 0; i 4; i++) {
+qemu_get_be32(f); /* dummy load for compatibility */
+}
+}
return 0;
}
@@ -256,8 +260,6 @@ static void piix3_set_irq(void *opaque, int irq_num, int
level)
int i, pic_irq, pic_level;
PIIX3State *piix3 = opaque;
-piix3-pci_irq_levels[irq_num] = level;
-
/* now we change the pic irq level according to the piix irq mappings */
/* XXX: optimize */
pic_irq = piix3-dev.config[0x60 + irq_num];
@@ -266,8 +268,9 @@ static void piix3_set_irq(void *opaque, int irq_num, int
level)
to it */
pic_level = 0;
for (i = 0; i 4; i++) {
-if (pic_irq == piix3-dev.config[0x60 + i])
-pic_level |= piix3-pci_irq_levels[i];
+if (pic_irq == piix3-dev.config[0x60 + i]) {
+pic_level |= pci_bus_get_irq_level(piix3-dev.bus, i);
+}
}
qemu_set_irq(piix3-pic[pic_irq], pic_level);
}
@@ -309,8 +312,17 @@ static void piix3_reset(void *opaque)
pci_conf[0xab] = 0x00;
pci_conf[0xac] = 0x00;
pci_conf[0xae] = 0x00;
+}
-memset(d-pci_irq_levels, 0, sizeof(d-pci_irq_levels));
+static void piix3_pre_save(void *opaque)
+{
+int i;
+PIIX3State *piix3 = opaque;
+
+for (i = 0; i ARRAY_SIZE(piix3-pci_irq_levels_vmstate); i++) {
+piix3-pci_irq_levels_vmstate[i] =
+pci_bus_get_irq_level(piix3-dev.bus, i);
+}
}
static const VMStateDescription vmstate_piix3 = {
@@ -318,9 +330,10 @@ static const VMStateDescription vmstate_piix3 = {
.version_id = 3,
.minimum_version_id = 2,
.minimum_version_id_old = 2,
+.pre_save = piix3_pre_save,
.fields = (VMStateField []) {
VMSTATE_PCI_DEVICE(dev, PIIX3State),
-VMSTATE_INT32_ARRAY_V(pci_irq_levels, PIIX3State, 4, 3),
+VMSTATE_INT32_ARRAY_V(pci_irq_levels_vmstate, PIIX3State, 4, 3),
VMSTATE_END_OF_LIST()
}
};
--
1.7.1.1
[Qemu-devel] [PATCH v3 3/3] piix_pci: optimize set irq path
optimize irq routing in piix_pic.c which has been a TODO.
So far piix3 tracks each pirq level and checks whether a given pic pins is
asserted by seeing if each pirq is mapped into the pic pin.
This is independent on irq routing, but data path is on slow path.
Given that irq routing is rarely changed and asserting pic pins is on
data path, the path that asserts pic pins should be optimized and
chainging irq routing should be on slow path.
The new behavior with this patch series is to use bitmap which is addressed
by pirq and pic pins with a given irq routing.
When pirq is asserted, the bitmap is set and see if the pic pins is
asserted by checking the bitmaps.
When irq routing is changed, rebuild the bitmap and re-assert pic pins.
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
Changes v1 - v2:
- some minor clean ups
- commit log message
---
hw/piix_pci.c | 94 +
1 files changed, 81 insertions(+), 13 deletions(-)
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index e88df43..f07e19d 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -37,8 +37,27 @@
typedef PCIHostState I440FXState;
+#define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
+#define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
+#define PIIX_PIRQC 0x60
+
typedef struct PIIX3State {
PCIDevice dev;
+
+/*
+ * bitmap to track pic levels.
+ * The pic level is the logical OR of all the PCI irqs mapped to it
+ * So one PIC level is tracked by PIIX_NUM_PIRQS bits.
+ *
+ * PIRQ is mapped to PIC pins, we track it by
+ * PIIX_NUM_PIRQS * PIIX_NUM_PIC_IRQS = 64 bits with
+ * pic_irq * PIIX_NUM_PIRQS + pirq
+ */
+#if PIIX_NUM_PIC_IRQS * PIIX_NUM_PIRQS 64
+#error unable to encode pic state in 64bit in pic_levels.
+#endif
+uint64_t pic_levels;
+
qemu_irq *pic;
/* This member isn't used. Just for save/load compatibility */
@@ -254,25 +273,63 @@ PCIBus *i440fx_init(PCII440FXState **pi440fx_state, int
*piix3_devfn, qemu_irq *
}
/* PIIX3 PCI to ISA bridge */
+static void piix3_set_irq_pic(PIIX3State *piix3, int pic_irq)
+{
+qemu_set_irq(piix3-pic[pic_irq],
+ !!(piix3-pic_levels
+((PIIX_NUM_PIRQS - 1) (pic_irq * PIIX_NUM_PIRQS;
+}
+
+static void piix3_set_irq_level(PIIX3State *piix3, int irq_num, int level,
+bool propagate)
+{
+int pic_irq;
+uint64_t mask;
+
+pic_irq = piix3-dev.config[PIIX_PIRQC + irq_num];
+if (pic_irq = PIIX_NUM_PIC_IRQS) {
+return;
+}
+
+mask = 1ULL ((pic_irq * PIIX_NUM_PIRQS) + irq_num);
+piix3-pic_levels = ~mask;
+piix3-pic_levels |= mask * !!level;
+
+if (propagate) {
+piix3_set_irq_pic(piix3, pic_irq);
+}
+}
static void piix3_set_irq(void *opaque, int irq_num, int level)
{
-int i, pic_irq, pic_level;
PIIX3State *piix3 = opaque;
+piix3_set_irq_level(piix3, irq_num, level, true);
+}
-/* now we change the pic irq level according to the piix irq mappings */
-/* XXX: optimize */
-pic_irq = piix3-dev.config[0x60 + irq_num];
-if (pic_irq 16) {
-/* The pic level is the logical OR of all the PCI irqs mapped
- to it */
-pic_level = 0;
-for (i = 0; i 4; i++) {
-if (pic_irq == piix3-dev.config[0x60 + i]) {
-pic_level |= pci_bus_get_irq_level(piix3-dev.bus, i);
-}
+/* irq routing is changed. so rebuild bitmap */
+static void piix3_update_irq_levels(PIIX3State *piix3)
+{
+int pirq;
+
+piix3-pic_levels = 0;
+for (pirq = 0; pirq PIIX_NUM_PIRQS; pirq++) {
+piix3_set_irq_level(piix3, pirq,
+pci_bus_get_irq_level(piix3-dev.bus, pirq),
+false);
+}
+}
+
+static void piix3_write_config(PCIDevice *dev,
+ uint32_t address, uint32_t val, int len)
+{
+pci_default_write_config(dev, address, val, len);
+if (ranges_overlap(address, len, PIIX_PIRQC, 4)) {
+PIIX3State *piix3 = DO_UPCAST(PIIX3State, dev, dev);
+int pic_irq;
+piix3_update_irq_levels(piix3);
+for (pic_irq = 0; pic_irq PIIX_NUM_PIC_IRQS; pic_irq++) {
+piix3_set_irq_pic(piix3, pic_irq);
}
-qemu_set_irq(piix3-pic[pic_irq], pic_level);
}
}
@@ -312,6 +369,15 @@ static void piix3_reset(void *opaque)
pci_conf[0xab] = 0x00;
pci_conf[0xac] = 0x00;
pci_conf[0xae] = 0x00;
+
+d-pic_levels = 0;
+}
+
+static int piix3_post_load(void *opaque, int version_id)
+{
+PIIX3State *piix3 = opaque;
+piix3_update_irq_levels(piix3);
+return 0;
}
static void piix3_pre_save(void *opaque)
@@ -330,6 +396,7 @@ static const VMStateDescription vmstate_piix3 = {
.version_id = 3,
.minimum_version_id = 2,
.minimum_version_id_old = 2,
+.post_load = piix3_post_load,
[Qemu-devel] [PATCH v3 0/3] piix_pci: optimize irq data path
This patch series optimizes irq data path of piix_pci. So far piix3 tracks each pirq level and checks whether a given pic pins is asserted by seeing if each pirq is mapped into the pic pin. This is independent on irq routing, but data path is on slow path. Given that irq routing is rarely changed and asserting pic pins is on data path, the path that asserts pic pins should be optimized and chainging irq routing should be on slow path. The new behavior with this patch series is to use bitmap which is addressed by pirq and pic pins with a given irq routing. When pirq is asserted, the bitmap is set and see if the pic pins is asserted by checking the bitmaps. When irq routing is changed, rebuild the bitmap and re-assert pic pins. Changes v2 - v3: - s/dummy_for_save_load_compat/pci_irq_levels_vmstate/g - move down unused member of pci_irq_levels_vmstate in the structure for cache efficiency Changes v1 - v2: - addressed review comments. Isaku Yamahata (3): pci: add accessor function to get irq levels piix_pci: eliminate PIIX3State::pci_irq_levels piix_pci: optimize set irq path hw/pci.c |7 +++ hw/pci.h |1 + hw/piix_pci.c | 119 +++- 3 files changed, 108 insertions(+), 19 deletions(-)
[Qemu-devel] [PATCH v3 1/3] pci: add accessor function to get irq levels
Introduce accessor function to know INTx levels.
It will be used later by q35.
Although piix_pci tracks the intx line levels, it can be eliminated
by this helper function.
Cc: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Isaku Yamahata yamah...@valinux.co.jp
---
hw/pci.c |7 +++
hw/pci.h |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 8b76cea..6ad3f10 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -126,6 +126,13 @@ static void pci_change_irq_level(PCIDevice *pci_dev, int
irq_num, int change)
bus-set_irq(bus-irq_opaque, irq_num, bus-irq_count[irq_num] != 0);
}
+int pci_bus_get_irq_level(PCIBus *bus, int irq_num)
+{
+assert(irq_num = 0);
+assert(irq_num bus-nirq);
+return !!bus-irq_count[irq_num];
+}
+
/* Update interrupt status bit in config space on interrupt
* state change. */
static void pci_update_irq_status(PCIDevice *dev)
diff --git a/hw/pci.h b/hw/pci.h
index 113e556..092a463 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -233,6 +233,7 @@ void pci_bus_new_inplace(PCIBus *bus, DeviceState *parent,
PCIBus *pci_bus_new(DeviceState *parent, const char *name, int devfn_min);
void pci_bus_irqs(PCIBus *bus, pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
void *irq_opaque, int nirq);
+int pci_bus_get_irq_level(PCIBus *bus, int irq_num);
void pci_bus_hotplug(PCIBus *bus, pci_hotplug_fn hotplug, DeviceState *dev);
PCIBus *pci_register_bus(DeviceState *parent, const char *name,
pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
--
1.7.1.1
Re: [Qemu-devel] [PATCH] cocoa: do not create a spurious window for -version
Hello Tristan,
Am 15.03.2011 um 14:18 schrieb Tristan Gingold:
When invoked with -version, qemu will exit just after displaying the
version,
so there is no need to create a window.
Also handles --XXX options.
Signed-off-by: Tristan Gingold ging...@adacore.com
Looks good to me except for the qemu_main() indentation. Should I fix
it and enqueue it on my cocoa branch for the next pull?
Just wondering, since when do we support -- options?
Andreas
---
ui/cocoa.m | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index 20f91bc..1ff1ac6 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -865,10 +865,19 @@ int main (int argc, const char * argv[]) {
/* In case we don't need to display a window, let's not do that */
for (i = 1; i argc; i++) {
-if (!strcmp(argv[i], -vnc) ||
-!strcmp(argv[i], -nographic) ||
-!strcmp(argv[i], -curses)) {
+const char *opt = argv[i];
+
+if (opt[0] == '-') {
+/* Treat --foo the same as -foo. */
+if (opt[1] == '-') {
+opt++;
+}
+if (!strcmp(opt, -vnc) ||
+!strcmp(opt, -nographic) ||
+!strcmp(opt, -version) ||
+!strcmp(opt, -curses)) {
return qemu_main(gArgc, gArgv);
+}
}
}
--
1.7.3.GIT
Re: [Qemu-devel] Does any version of QEMU support EFI?
On Sat, Mar 19, 2011 at 9:53 AM, Bei Guan gbtj...@gmail.com wrote: I want to know which version of QEMU support EFI? I don't find any code to do with the EFI in the QEMU source code. So, is it that QEMU doesn't support EFI? QEMU does not ship with EFI firmware. Here is a project which provides a UEFI implementation for QEMU/KVM: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF Stefan
Re: [Qemu-devel] Re: vcpu hotplug status
On Sat, Mar 19, 2011 at 12:25:38PM +0100, William Dauchy wrote: On Wed, Mar 16, 2011 at 11:17 AM, William Dauchy wdau...@gmail.com wrote: I wanted to test vcpu hotplug. When adding a cpu I'm getting qdev_create_from_info: Assertion `bus-allow_hotplug' failed. I went through a discussion about the subject here http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00999.html To make sure whether it was working, I hard-coded allow_hotplug = 1; the guest is now able to have more vpcus without any trouble (removing vcpus did not seem to work though). Since it definitively not a solution, I wanted to have a status about the subject or if I was missing something in my configuration since it works with a dirty workaround. I would be also pleased to get some tips to fix the code. Any thoughts? Or perhaps my message was lost among patches... Even patches are lost among patches those days. The problem you describe is known. Both of them actually (non working vcpu remove is the second one). I am not aware of any effort to fix them. I am more concern about second problem though. bus-allow_hotplug is not fixed because of laziness on developers part, but non working vcpu remove is caused by us not understanding how cpu hot-plug works in Linux on x86. -- Gleb.
Re: [Qemu-devel] Does any version of QEMU support EFI?
Does QEMU have the plan to ship with EFI firmware? Xen community will probably have a project for GSoC2011 to write an EFI firmware for Xen VMs. And the EFI firmware need to be acceptable to QEMU code, which is in the Xen source code. This project is EFI in HVM guests + Xen on EFI Hardware at http://wiki.xen.org/xenwiki/GSoC_2011_ideas So, does QEMU have any design for the EFI firmware? Is there any advice to this Xen project? Thank you very much. 2011/3/19 Stefan Hajnoczi stefa...@gmail.com On Sat, Mar 19, 2011 at 9:53 AM, Bei Guan gbtj...@gmail.com wrote: I want to know which version of QEMU support EFI? I don't find any code to do with the EFI in the QEMU source code. So, is it that QEMU doesn't support EFI? QEMU does not ship with EFI firmware. Here is a project which provides a UEFI implementation for QEMU/KVM: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF Stefan
Re: [Qemu-devel] Does any version of QEMU support EFI?
On Sat, Mar 19, 2011 at 08:36, Bei Guan gbtj...@gmail.com wrote: Does QEMU have the plan to ship with EFI firmware? Hi. I work on the OVMF project which Stefan mentioned. I definitely can't speak for the qemu/kvm project, but I'll give my impressions from my OVMF perspective. I think qemu/kvm has some interest in supporting UEFI, but they are (understandably) concerned about losing legacy bios compatibility. Additionally, they do not want the user to have to choose between a legacy boot rom and a UEFI boot rom before starting the VM. Xen community will probably have a project for GSoC2011 to write an EFI firmware for Xen VMs. And the EFI firmware need to be acceptable to QEMU code, which is in the Xen source code. This project is EFI in HVM guests + Xen on EFI Hardware at http://wiki.xen.org/xenwiki/GSoC_2011_ideas So, does QEMU have any design for the EFI firmware? Is there any advice to this Xen project? We would also like to support Xen in our OVMF project. (EFI in HVM guests) So, if this project is interested in leveraging our OVMF project, then we could try to help support this task. Thanks, -Jordan
Re: [Qemu-devel] Does any version of QEMU support EFI?
On 03/19/2011 02:50 PM, Jordan Justen wrote: On Sat, Mar 19, 2011 at 08:36, Bei Guangbtj...@gmail.com wrote: Does QEMU have the plan to ship with EFI firmware? Hi. I work on the OVMF project which Stefan mentioned. I definitely can't speak for the qemu/kvm project, but I'll give my impressions from my OVMF perspective. I think qemu/kvm has some interest in supporting UEFI, but they are (understandably) concerned about losing legacy bios compatibility. Additionally, they do not want the user to have to choose between a legacy boot rom and a UEFI boot rom before starting the VM. It's not just whether the user has to choose. It's the testing associated with having two different firmware paths in the tree. If we had UEFI as a secondary option, 99% of users would never use it so it would bit rot very quickly. With a CSM, UEFI can become part of the standard path such that 100% of users are actually testing UEFI. That's really what our goal is. Regards, Anthony Liguori
[Qemu-devel] [PATCH master, stable] virtio-pci: fix bus master work around on load
Commit c81131db15dd1844d0db1d51f3cd7a105cfd2cf3
detects old guests by comparing virtio and
PCI status. It attempts to do this on load,
as well, but load_config callback in a binding
is invoked too early and so the virtio status
isn't set yet.
We could add yet another callback to the
binding, to invoke after load, but it
seems easier to reuse the existing vmstate
callback.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
Cc: Alexander Graf ag...@suse.de
---
hw/virtio-pci.c | 13 ++---
hw/virtio.h |1 +
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 3911b09..d40ac23 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -160,13 +160,6 @@ static int virtio_pci_load_config(void * opaque, QEMUFile
*f)
if (proxy-vdev-config_vector != VIRTIO_NO_VECTOR) {
return msix_vector_use(proxy-pci_dev, proxy-vdev-config_vector);
}
-
-/* Try to find out if the guest has bus master disabled, but is
- in ready state. Then we have a buggy guest OS. */
-if ((proxy-vdev-status VIRTIO_CONFIG_S_DRIVER_OK)
-!(proxy-pci_dev.config[PCI_COMMAND] PCI_COMMAND_MASTER)) {
-proxy-flags |= VIRTIO_PCI_FLAG_BUS_MASTER_BUG;
-}
return 0;
}
@@ -651,6 +644,12 @@ static void virtio_pci_vmstate_change(void *opaque, bool
running)
VirtIOPCIProxy *proxy = opaque;
if (running) {
+/* Try to find out if the guest has bus master disabled, but is
+ in ready state. Then we have a buggy guest OS. */
+if ((proxy-vdev-status VIRTIO_CONFIG_S_DRIVER_OK)
+!(proxy-pci_dev.config[PCI_COMMAND] PCI_COMMAND_MASTER)) {
+proxy-flags |= VIRTIO_PCI_FLAG_BUS_MASTER_BUG;
+}
virtio_pci_start_ioeventfd(proxy);
} else {
virtio_pci_stop_ioeventfd(proxy);
--
1.7.3.2.91.g446ac
[Qemu-devel] Re: [PATCH] petalogix_ml605_mmu: remove unused variable
On Sat, Mar 19, 2011 at 10:45:34AM +0200, Blue Swirl wrote:
Remove a write-only variable, spotted by GCC 4.6.0:
/src/qemu/hw/petalogix_ml605_mmu.c: In function 'petalogix_ml605_init':
/src/qemu/hw/petalogix_ml605_mmu.c:153:11: error: variable 'serial'
set but not used [-Werror=unused-but-set-variable]
Thanks, feel free to apply.
Cheers
Signed-off-by: Blue Swirl blauwir...@gmail.com
---
hw/petalogix_ml605_mmu.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/hw/petalogix_ml605_mmu.c b/hw/petalogix_ml605_mmu.c
index ca0986a..8213902 100644
--- a/hw/petalogix_ml605_mmu.c
+++ b/hw/petalogix_ml605_mmu.c
@@ -150,7 +150,6 @@ petalogix_ml605_init(ram_addr_t ram_size,
ram_addr_t phys_ram;
ram_addr_t phys_flash;
qemu_irq irq[32], *cpu_irq;
-void *serial = NULL;
/* init CPUs */
if (cpu_model == NULL) {
@@ -185,8 +184,8 @@ petalogix_ml605_init(ram_addr_t ram_size,
irq[i] = qdev_get_gpio_in(dev, i);
}
-serial = serial_mm_init(UART16550_BASEADDR + 0x1000, 2, irq[5],
-115200, serial_hds[0], 1, 0);
+serial_mm_init(UART16550_BASEADDR + 0x1000, 2, irq[5], 115200,
+ serial_hds[0], 1, 0);
/* 2 timers at irq 2 @ 100 Mhz. */
xilinx_timer_create(TIMER_BASEADDR, irq[2], 2, 100 * 100);
--
1.6.2.4
