[Qemu-devel] Hard freeze for 1.2 today
Hi, Today is the hard freeze for 1.2. If you have any pull requests and/or patches targetted for the hard freeze, please send them by 3pm US/Central time today and clearly mark them "for-1.2". If there are existing patches and/or pull requests on the mailing list that you think should be in 1.2, please respond to the email with a pointer to the mail. Regards, Anthony Liguori
[Qemu-devel] FYI: Delaying 1.2 release to Sept. 5th.
I cannot provide additional details so please don't ask. There's a issue in the 1.2 release being investigated. We need to delay the release by a few days to ensure the fix can be in the release. I've updated the wiki appropriately. Regards, Anthony Liguori
[Qemu-devel] [ANNOUNCE] QEMU 1.2.0-rc3 release
Hi, On behalf of the QEMU Team, I'd like to announce the availability of the first release candidate for the QEMU 1.2 release. This release is meant for testing purposes and should not be used in a production environment. http://wiki.qemu.org/download/qemu-1.2.0-rc1.tar.bz2 You can help improve the quality of the QEMU 1.2 release by testing this release and reporting bugs on Launchpad: https://bugs.launchpad.net/qemu/ The release plan for the 1.2 release is available at: http://wiki.qemu.org/Planning/1.2 And a detailed change log is available at: http://wiki.qemu.org/ChangeLog/Next Known Issues: - There is a potential for a SEGV during usb_del, this will be fixed in -rc2 - References are not completely released during device removal which may lead to internal memory leaks. Changelog since -rc0: - Update version for 1.2.0-rc1 release (Anthony Liguori) - qapi: add 'query-target' command to return target arch (Daniel P. Berrange) - pci: Tidy up PCI host bridges (Andreas Färber) - pci: Derive PCI host bridges from TYPE_PCI_HOST_BRIDGE (Andreas Färber) - pci_host: Turn into SysBus-derived QOM type (Andreas Färber) - unin_pci: QOM'ify UniNorth PCI host bridges (Andreas Färber) - spapr_pci: QOM'ify sPAPR PCI host bridge (Andreas Färber) - prep_pci: QOM'ify Raven PCI host bridge (Andreas Färber) - ppce500_pci: QOM'ify e500 PCI host bridge (Andreas Färber) - ppc4xx_pci: QOM'ify ppc4xx PCI host bridge (Andreas Färber) - gt64xxx: QOM'ify GT64120 PCI host bridge (Andreas Färber) - grackle_pci: QOM'ify Grackle PCI host bridge (Andreas Färber) - dec_pci: QOM'ify DEC 21154 PCI-PCI bridge (Andreas Färber) - bonito: QOM'ify Bonito PCI host bridge (Andreas Färber) - alpha_typhoon: QOM'ify Typhoon PCI host bridge (Andreas Färber) - pci: Make host bridge TypeInfos const (Andreas Färber) - virtio-blk: hide VIRTIO_BLK_F_CONFIG_WCE from old machine types (Stefan Hajnoczi) - softmmu-semi: fix lock_user* functions not to deref NULL upon OOM (Jim Meyering) - arm-semi: don't leak 1KB user string lock buffer upon TARGET_SYS_OPEN (Jim Meyering) - sheepdog: don't leak socket file descriptor upon connection failure (Jim Meyering) - linux-user: do_msgrcv: don't leak host_mb upon TARGET_EFAULT failure (Jim Meyering) - qemu-ga: don't leak a file descriptor upon failed lockf (Jim Meyering) - xen-all.c: fix multiply issue for int and uint types (Dongxiao Xu) - Fix invalidate if memory requested was not bucket aligned (Frediano Ziglio) - i82378: Remove bogus MMIO coalescing (Jan Kiszka) - eventfd: making it thread safe (Alexey Kardashevskiy) - migration: move total_time from ram stats to migration info (Juan Quintela) - monitor: avoid declaring unused variables (Blue Swirl) - qapi: Fix memory leak (Stefan Weil) - virtio-scsi: add backwards-compatibility properties for 1.1 and earlier machines (Paolo Bonzini) - iscsi: fix races between task completion and abort (Paolo Bonzini) - iscsi: simplify iscsi_schedule_bh (Paolo Bonzini) - iscsi: move iscsi_schedule_bh and iscsi_readv_writev_bh_cb (Paolo Bonzini) - Revert "iscsi: Fix NULL dereferences / races between task completion and abort" (Paolo Bonzini) - Update OpenBIOS images (Blue Swirl) - pc: Fix RTC CMOS info on RAM for ram_size < 1MiB (Markus Armbruster) - vl: Round argument of -m up to multiple of 8KiB (Markus Armbruster) - scsi: fix warning (Gerd Hoffmann) - Avoid asprintf() which is not available on mingw (Gerd Hoffmann) - virtio-blk: hide VIRTIO_BLK_F_CONFIG_WCE from old machine types (Stefan Hajnoczi) - Documentation: Warn against qemu-img on active image (Kevin Wolf) - vmdk: Read footer for streamOptimized images (Kevin Wolf) - vmdk: Fix header structure (Kevin Wolf) - ehci: Fix setting of halt bit from usbcmd register updates (Hans de Goede) - ehci: fix Interrupt Threshold Control implementation (Gerd Hoffmann) - usb: update uas product id (Gerd Hoffmann) - usb: async control xfer fixup (Gerd Hoffmann) Regards, Anthony Liguori
[Qemu-devel] [ANNOUNCE] 1.3 development is now open!
I've updated the release plan on the wiki: http://wiki.qemu.org/Planning/1.3 No surprises, same format/timeline as 1.2. Happy hacking! Regards, Anthony Liguori
[Qemu-devel] [ATTENTION] You must run git submodule update --init on latest master!
There is now a pixman module that is used if you don't have pixman development packages installed locally. Regards, Anthony Liguori
[Qemu-devel] qemu.org DNS status
Hi, I wanted to update everyone on the qemu.org DNS status. This morning it was reported that the two nameservers that qemu.org is configured to use are down. I do not have access to the DNS records for qemu.org as they are graciously donated by a third party. I've contacted the owner of the records who has been fairly responsive in the past. In the interim, I've setup an alternative hostname, qemu-project.org, that can be used as an alternative to qemu.org. This hostname will remain active even when qemu.org is restored. Sorry for the inconvenience. Regards, Anthony Liguori
[Qemu-devel] [ANNOUNCE] QEMU 1.3.0-rc0 is out!
Hi, On behalf of the QEMU Team, I'd like to announce the availability of the first release candidate for the QEMU 1.3 release. This release is meant for testing purposes and should not be used in a production environment. http://wiki.qemu.org/download/qemu-1.3.0-rc0.tar.bz2 You can help improve the quality of the QEMU 1.3 release by testing this release and reporting bugs on Launchpad: https://bugs.launchpad.net/qemu/ The release plan for the 1.3 release is available at: http://wiki.qemu.org/Planning/1.3 And a detailed change log is available at: http://wiki.qemu.org/ChangeLog/Next Regards, Anthony Liguori
[Qemu-devel] [ANNOUNCE] QEMU 1.3.0-rc1 is out!
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the
second release candidate for the QEMU 1.3 release. This release is meant
for testing purposes and should not be used in a production environment.
http://wiki.qemu.org/download/qemu-1.3.0-rc1.tar.bz2
You can help improve the quality of the QEMU 1.3 release by testing this
release and reporting bugs on Launchpad:
https://bugs.launchpad.net/qemu/
The release plan for the 1.3 release is available at:
http://wiki.qemu.org/Planning/1.3
And a detailed change log is available at:
http://wiki.qemu.org/ChangeLog/Next
The changes since -rc0 are below:
- virtio-rng: fix typos, comments (Amit Shah)
- virtio-rng: disable timer on device removal (Amit Shah)
- virtio-rng: remove extra request for entropy (Amit Shah)
- virtio-rng: use virtqueue_get_avail_bytes, fix migration (Amit Shah)
- i8259: Fix PIC_COMMON() macro (Andreas Färber)
- qapi: handle visitor->type_size() in QapiDeallocVisitor (Stefan Hajnoczi)
- target-i386: cpu: add missing flags to Haswell CPU model (Eduardo Habkost)
- vl.c: Fix broken -usb option (Peter Maydell)
- qom: make object_finalize static (Paolo Bonzini)
- qdev: simplify (de)allocation of buses (Paolo Bonzini)
- qom: make object_delete usable for statically-allocated objects (Paolo
Bonzini)
- qdev: move bus removal to object_unparent (Paolo Bonzini)
- qom: fix refcount of non-heap-allocated objects (Paolo Bonzini)
- hmp: do not crash on invalid SCSI hotplug (Paolo Bonzini)
- qom: dynamic_cast of NULL is always NULL (Paolo Bonzini)
- tests: add thread pool unit tests (Paolo Bonzini)
- tests: add AioContext unit tests (Paolo Bonzini)
- aio: avoid livelock behavior for Win32 (Paolo Bonzini)
- q35: Add kvmclock support (Jan Kiszka)
- q35: Fix non-PCI IRQ processing in ich9_lpc_update_apic (Jan Kiszka)
- q35: Suppress SMM BIOS initialization under KVM (Jan Kiszka)
- ich9: Add i82801b11 dmi-to-pci bridge (Jason Baron)
- q35: Introduce q35 pc based chipset emulator (Isaku Yamahata)
- ich9: Add smbus (Jason Baron)
- ich9: Add the lpc chip (Jason Baron)
- ich9: Add acpi support and definitions (Jason Baron)
- pc/piix_pci: factor out smram/pam logic (Isaku Yamahata)
- pc_piix: Move kvm irq routing functions out of pc_piix.c (Jason Baron)
- pc: Move ioapic_init() from pc_piix.c to pc.c (Jason Baron)
- pc, pc_piix: split out pc nic initialization (Isaku Yamahata)
- vnc: fix option misspelling ("non-adapative" -> "non-adaptive") (Catalin
Patulea)
- chardev: Use real-time clock for open timer (Jan Kiszka)
- Build system fix distclean error for pixman (Wenchao Xia)
- block: Fix regression for MinGW (assertion caused by short string) (Stefan
Weil)
- tci: Fix type of tci_read_label (Richard Henderson)
- target-mips: remove POOL48A from the microMIPS decoding (Aurelien Jarno)
- tcg: mark local temps as MEM in dead_temp() (Aurelien Jarno)
- target-mips: Clean up microMIPS32 major opcode (陳韋任 (Wei-Ren Chen))
- target-mips: Add comments on POOL32Axf encoding (陳韋任 (Wei-Ren Chen))
- target-openrisc: remove conflicting definitions from cpu.h (Aurelien Jarno)
- tcg/arm: fix cross-endian qemu_st16 (Aurelien Jarno)
- tcg/arm: fix TLB access in qemu-ld/st ops (Aurelien Jarno)
- Legacy qemu-kvm options have no argument (Bruce Rogers)
- usb-redir: Don't handle interrupt output packets async (Hans de Goede)
- usb-redir: Split usb_handle_interrupt_data into separate in/out functions
(Hans de Goede)
- usb-smartcard-reader: Properly NAK interrupt eps when we've no events (Hans
de Goede)
- usb-bt: Return NAK instead of STALL when interrupt ep has no data (Hans de
Goede)
- uhci: Fix double unlink (Hans de Goede)
- uhci: Don't allow the guest to set port-enabled when there is no dev
connected (Hans de Goede)
- uhci: Add a completions_only flag for async completions (Hans de Goede)
- spice: add new spice-server callbacks to ui/spice-display.c (Gerd Hoffmann)
- Fix the inconsistency in x509-dh-key-file parameter (Lei Li)
- ide: Fix status register after short PRDs (Kevin Wolf)
- ide: Fix crash with too long PRD (Kevin Wolf)
- use int64_t for return values from rbd instead of int (Stefan Priebe)
- vdi: don't override libuuid symbols (Stefan Hajnoczi)
- block: add bdrv_reopen() support for raw hdev, floppy, and cdrom (Jeff Cody)
- qemu-sockets: Fix parsing of the inet option 'to'. (Anthony PERARD)
- tcg/ppc: Fix !softmmu case (malc)
- tap: reset vnet header size on open (Michael S. Tsirkin)
Regards,
Anthony Liguori
[Qemu-devel] Plan for error handling in QMP
Hi, We had a violent^Wheated discussion on IRC about how to move forward with Luiz's proposed error series. I think we reached consensus. This note attempts to outline that. Principles -- 1. Errors should be free formed strings with a class code 2. There should be a small number of class codes (10-15) added strictly when there are specific users of a code. 3. The class code should be expressed as an enum data type in the normal QMP schema. Other than this, errors should have no structure in the schema.[*] 4. We should drop all dictionary arguments in the current error mechanisms beyond 'class' and 'desc'. 5. The following errors are used by libvirt: - CommandNotFound: QMP parsing - DeviceNotActive/KVMMissingCap: ballooning - DeviceNotFound: drive_del - MigrationExpected: cont 6. We need to make sure that these errors are preserved while other errors should be consolidated. - We need to state very clear for 1.2 which errors are going away. 7. We need to make sure that anything we expose in 1.2 stays that way. If we're dropping 'InvalidParameterType' as a class code, it should be dropped in 1.2. This could be achieved by making all existing codes except for those in (5) report 'UnknownError' or something.[*] [*] I took a little bit of license with these. Hopefully it's not controversial. Regards, Anthony Liguori
[PULL 1/3] hw/xen: detect when running inside stubdomain
From: Marek Marczykowski-Górecki
Introduce global xen_is_stubdomain variable when qemu is running inside
a stubdomain instead of dom0. This will be relevant for subsequent
patches, as few things like accessing PCI config space need to be done
differently.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Anthony PERARD
Message-Id:
Signed-off-by: Anthony PERARD
---
hw/i386/xen/xen-hvm.c | 22 ++
include/hw/xen/xen.h | 1 +
system/globals.c | 1 +
3 files changed, 24 insertions(+)
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index 006d219ad5..4f6446600c 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -584,6 +584,26 @@ static void xen_wakeup_notifier(Notifier *notifier, void
*data)
xc_set_hvm_param(xen_xc, xen_domid, HVM_PARAM_ACPI_S_STATE, 0);
}
+static bool xen_check_stubdomain(struct xs_handle *xsh)
+{
+char *dm_path = g_strdup_printf(
+"/local/domain/%d/image/device-model-domid", xen_domid);
+char *val;
+int32_t dm_domid;
+bool is_stubdom = false;
+
+val = xs_read(xsh, 0, dm_path, NULL);
+if (val) {
+if (sscanf(val, "%d", &dm_domid) == 1) {
+is_stubdom = dm_domid != 0;
+}
+free(val);
+}
+
+g_free(dm_path);
+return is_stubdom;
+}
+
void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion **ram_memory)
{
MachineState *ms = MACHINE(pcms);
@@ -596,6 +616,8 @@ void xen_hvm_init_pc(PCMachineState *pcms, MemoryRegion
**ram_memory)
xen_register_ioreq(state, max_cpus, &xen_memory_listener);
+xen_is_stubdomain = xen_check_stubdomain(state->xenstore);
+
QLIST_INIT(&xen_physmap);
xen_read_physmap(state);
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 37ecc91fc3..ecb89ecfc1 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -36,6 +36,7 @@ enum xen_mode {
extern uint32_t xen_domid;
extern enum xen_mode xen_mode;
extern bool xen_domid_restrict;
+extern bool xen_is_stubdomain;
int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num);
int xen_set_pci_link_route(uint8_t link, uint8_t irq);
diff --git a/system/globals.c b/system/globals.c
index e353584201..d602a04fa2 100644
--- a/system/globals.c
+++ b/system/globals.c
@@ -60,6 +60,7 @@ bool qemu_uuid_set;
uint32_t xen_domid;
enum xen_mode xen_mode = XEN_DISABLED;
bool xen_domid_restrict;
+bool xen_is_stubdomain;
struct evtchn_backend_ops *xen_evtchn_ops;
struct gnttab_backend_ops *xen_gnttab_ops;
struct foreignmem_backend_ops *xen_foreignmem_ops;
--
Anthony PERARD
[PULL 0/3] xen queue 2024-07-01
From: Anthony PERARD The following changes since commit b6d32a06fc0984e537091cba08f2e1ed9f775d74: Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging (2024-06-30 16:12:24 -0700) are available in the Git repository at: https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git tags/pull-xen-20240701 for you to fetch changes up to 410b4d560dfa3b38a11ad19cf00180238651d9b7: xen-hvm: Avoid livelock while handling buffered ioreqs (2024-07-01 14:57:18 +0200) Xen queue: * Improvement for running QEMU in a stubdomain. * Improve handling of buffered ioreqs. Marek Marczykowski-Górecki (2): hw/xen: detect when running inside stubdomain xen: fix stubdom PCI addr Ross Lagerwall (1): xen-hvm: Avoid livelock while handling buffered ioreqs hw/i386/xen/xen-hvm.c| 22 + hw/xen/xen-host-pci-device.c | 76 +++- hw/xen/xen-host-pci-device.h | 6 hw/xen/xen-hvm-common.c | 26 +-- include/hw/xen/xen.h | 1 + system/globals.c | 1 + 6 files changed, 122 insertions(+), 10 deletions(-)
[PULL 3/3] xen-hvm: Avoid livelock while handling buffered ioreqs
From: Ross Lagerwall
A malicious or buggy guest may generated buffered ioreqs faster than
QEMU can process them in handle_buffered_iopage(). The result is a
livelock - QEMU continuously processes ioreqs on the main thread without
iterating through the main loop which prevents handling other events,
processing timers, etc. Without QEMU handling other events, it often
results in the guest becoming unsable and makes it difficult to stop the
source of buffered ioreqs.
To avoid this, if we process a full page of buffered ioreqs, stop and
reschedule an immediate timer to continue processing them. This lets
QEMU go back to the main loop and catch up.
Signed-off-by: Ross Lagerwall
Reviewed-by: Paul Durrant
Message-Id: <20240404140833.1557953-1-ross.lagerw...@citrix.com>
Signed-off-by: Anthony PERARD
---
hw/xen/xen-hvm-common.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/hw/xen/xen-hvm-common.c b/hw/xen/xen-hvm-common.c
index b8ace1c368..3a9d6f981b 100644
--- a/hw/xen/xen-hvm-common.c
+++ b/hw/xen/xen-hvm-common.c
@@ -475,11 +475,11 @@ static void handle_ioreq(XenIOState *state, ioreq_t *req)
}
}
-static bool handle_buffered_iopage(XenIOState *state)
+static unsigned int handle_buffered_iopage(XenIOState *state)
{
buffered_iopage_t *buf_page = state->buffered_io_page;
buf_ioreq_t *buf_req = NULL;
-bool handled_ioreq = false;
+unsigned int handled = 0;
ioreq_t req;
int qw;
@@ -492,7 +492,7 @@ static bool handle_buffered_iopage(XenIOState *state)
req.count = 1;
req.dir = IOREQ_WRITE;
-for (;;) {
+do {
uint32_t rdptr = buf_page->read_pointer, wrptr;
xen_rmb();
@@ -533,22 +533,30 @@ static bool handle_buffered_iopage(XenIOState *state)
assert(!req.data_is_ptr);
qatomic_add(&buf_page->read_pointer, qw + 1);
-handled_ioreq = true;
-}
+handled += qw + 1;
+} while (handled < IOREQ_BUFFER_SLOT_NUM);
-return handled_ioreq;
+return handled;
}
static void handle_buffered_io(void *opaque)
{
+unsigned int handled;
XenIOState *state = opaque;
-if (handle_buffered_iopage(state)) {
+handled = handle_buffered_iopage(state);
+if (handled >= IOREQ_BUFFER_SLOT_NUM) {
+/* We handled a full page of ioreqs. Schedule a timer to continue
+ * processing while giving other stuff a chance to run.
+ */
timer_mod(state->buffered_io_timer,
-BUFFER_IO_MAX_DELAY + qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
-} else {
+qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
+} else if (handled == 0) {
timer_del(state->buffered_io_timer);
qemu_xen_evtchn_unmask(state->xce_handle, state->bufioreq_local_port);
+} else {
+timer_mod(state->buffered_io_timer,
+BUFFER_IO_MAX_DELAY + qemu_clock_get_ms(QEMU_CLOCK_REALTIME));
}
}
--
Anthony PERARD
[PULL 2/3] xen: fix stubdom PCI addr
From: Marek Marczykowski-Górecki
When running in a stubdomain, the config space access via sysfs needs to
use BDF as seen inside stubdomain (connected via xen-pcifront), which is
different from the real BDF. For other purposes (hypercall parameters
etc), the real BDF needs to be used.
Get the in-stubdomain BDF by looking up relevant PV PCI xenstore
entries.
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Anthony PERARD
Message-Id:
<35049e99da634a74578a1ff2cb3ae4cc436ede33.1711506237.git-series.marma...@invisiblethingslab.com>
Signed-off-by: Anthony PERARD
---
hw/xen/xen-host-pci-device.c | 76 +++-
hw/xen/xen-host-pci-device.h | 6 +++
2 files changed, 81 insertions(+), 1 deletion(-)
diff --git a/hw/xen/xen-host-pci-device.c b/hw/xen/xen-host-pci-device.c
index 8c6e9a1716..eaf32f2710 100644
--- a/hw/xen/xen-host-pci-device.c
+++ b/hw/xen/xen-host-pci-device.c
@@ -9,6 +9,8 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qemu/cutils.h"
+#include "hw/xen/xen-legacy-backend.h"
+#include "hw/xen/xen-bus-helper.h"
#include "xen-host-pci-device.h"
#define XEN_HOST_PCI_MAX_EXT_CAP \
@@ -33,13 +35,73 @@
#define IORESOURCE_PREFETCH 0x1000 /* No side effects */
#define IORESOURCE_MEM_64 0x0010
+/*
+ * Non-passthrough (dom0) accesses are local PCI devices and use the given BDF
+ * Passthough (stubdom) accesses are through PV frontend PCI device. Those
+ * either have a BDF identical to the backend's BDF (xen-backend.passthrough=1)
+ * or a local virtual BDF (xen-backend.passthrough=0)
+ *
+ * We are always given the backend's BDF and need to lookup the appropriate
+ * local BDF for sysfs access.
+ */
+static void xen_host_pci_fill_local_addr(XenHostPCIDevice *d, Error **errp)
+{
+unsigned int num_devs, len, i;
+unsigned int domain, bus, dev, func;
+char *be_path = NULL;
+char path[16];
+
+be_path = qemu_xen_xs_read(xenstore, 0, "device/pci/0/backend", &len);
+if (!be_path) {
+error_setg(errp, "Failed to read device/pci/0/backend");
+goto out;
+}
+
+if (xs_node_scanf(xenstore, 0, be_path, "num_devs", NULL,
+ "%d", &num_devs) != 1) {
+error_setg(errp, "Failed to read or parse %s/num_devs", be_path);
+goto out;
+}
+
+for (i = 0; i < num_devs; i++) {
+snprintf(path, sizeof(path), "dev-%d", i);
+if (xs_node_scanf(xenstore, 0, be_path, path, NULL,
+ "%x:%x:%x.%x", &domain, &bus, &dev, &func) != 4) {
+error_setg(errp, "Failed to read or parse %s/%s", be_path, path);
+goto out;
+}
+if (domain != d->domain ||
+bus != d->bus ||
+dev != d->dev ||
+func != d->func)
+continue;
+snprintf(path, sizeof(path), "vdev-%d", i);
+if (xs_node_scanf(xenstore, 0, be_path, path, NULL,
+ "%x:%x:%x.%x", &domain, &bus, &dev, &func) != 4) {
+error_setg(errp, "Failed to read or parse %s/%s", be_path, path);
+goto out;
+}
+d->local_domain = domain;
+d->local_bus = bus;
+d->local_dev = dev;
+d->local_func = func;
+goto out;
+}
+error_setg(errp, "Failed to find PCI device %x:%x:%x.%x in xenstore",
+ d->domain, d->bus, d->dev, d->func);
+
+out:
+free(be_path);
+}
+
static void xen_host_pci_sysfs_path(const XenHostPCIDevice *d,
const char *name, char *buf, ssize_t size)
{
int rc;
rc = snprintf(buf, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
- d->domain, d->bus, d->dev, d->func, name);
+ d->local_domain, d->local_bus, d->local_dev, d->local_func,
+ name);
assert(rc >= 0 && rc < size);
}
@@ -342,6 +404,18 @@ void xen_host_pci_device_get(XenHostPCIDevice *d, uint16_t
domain,
d->dev = dev;
d->func = func;
+if (xen_is_stubdomain) {
+xen_host_pci_fill_local_addr(d, errp);
+if (*errp) {
+goto error;
+}
+} else {
+d->local_domain = d->domain;
+d->local_bus = d->bus;
+d->local_dev = d->dev;
+d->local_func = d->func;
+}
+
xen_host_pci_config_open(d, errp);
if (*errp) {
goto error;
diff --git a/hw/xen/xen-host-pci-device.h b/hw/xen/xen-host-pci-device.h
index 4d8d34ecb0..270dcb27f7 100644
--- a/hw/xen/xen-host-pci-device.h
+++ b/hw/xen/xen-host-pci-device.h
@@ -23,6 +23,12 @@ typedef struct XenHostPCIDevice {
uint8_t dev;
uint8_t func;
+/* different from the above in case of stubdomain */
+uint16_t local_domain;
+uint8_t local_bus;
+uint8_t local_dev;
+uint8_t local_func;
+
uint16_t vendor_id;
uint16_t device_id;
uint32_t class_code;
--
Anthony PERARD
Re: [Qemu-devel] Cirrus bugs vs endian: how two bugs cancel each other out
Gerd Hoffmann writes: > Hi, > >> QXL has a lot of short comings. Here's a short list: >> >> - It's 100% PC centric. It requires PCI and is completely oblivious to >> endianness. > > No. The endianess is actually clearly defined. It's little endian for > both guest/host interface (aka qxl) and the network protocol. Right, because it was designed without regard to endianness and then declared as little endian since it was written that's what x86 happens to be :-) One of the nice properties of virtio is that the ring is defined to be in guest-endian. This does make access a bit faster. > So it is "only" the libspice code which needs fixing. Should be not as > bad as it sounds. There is a code generator for writing/parsing the > network protocol, winding up native endian <=> little endian handling > there shouldn't be that hard. Likewise there is a piece of code > translating qxl device structs into internal spice-server structs > (applying sanity checks along the way). There we can hook up the > byteswapping for the guest/host interface. I have no doubt that it's fixable and ought to be fixed. > >> - It's all-or-nothing with respect to Spice support. libspice is a big >> external dependency. It cannot be mandated as a QEMU requirement >> because it's not portable enough. This means we can never make qxl >> the default device because we can't guarantee it's there. > > Indeed. > >> But there's a lot of value in a new graphics interface that uses virtio >> and negotiates support for the Spice protocol. That way, if QEMU >> doesn't have Spice support, the feature won't be exposed to the guest >> and you can still have a legacy VGA interface. > > What does it buy us? A single guest driver/configuration that works whether or not libspice is available on the host. A single graphics driver configuration which means that users can stop worry about what graphics card type is specified. > Even with -vga std-which-might-have-spice-over-virtio-support you still > have to figure whenever qemu has spice support and pass / don't pass > -spice $opts accordingly. If you want to configure a Spice server, yes. If you're just doing local graphics, it shouldn't matter, right? >> Then we can change the default. Basic 2d commands (like blit and solid >> fill) can be done without going through libspice. > > We can create a set of basic 2d accel commands and implement them in > both stdvga and qxl, where qxl would translate them into spice ops of > course. > >> Then we can stop messing around with having multiple display types. >> It would be a huge usability improvement and would allow us to focus on >> a single graphics adapter for all architectures. > > Improving stdvga to support basic 2d accel isn't that much effort. I > think it is worth doing it, even when it is obsoleted by a redesigned / > rewritten qxl2 some day. I think we're pretty much in agreement here. I think if we improve stdvga by making it a virtio device, then it becomes pretty easy to eventually make it qxl2. Regards, Anthony Liguori > > cheers, > Gerd
Re: [Qemu-devel] [PATCH] virtio: fix vhost handling
Paolo Bonzini writes:
> Commit b1f416aa8d870fab71030abc9401cfc77b948e8e breaks vhost_net
> because it always registers the virtio_pci_host_notifier_read() handler
> function on the ioeventfd, even when vhost_net.ko is using the ioeventfd.
> The result is both QEMU and vhost_net.ko polling on the same eventfd
> and the virtio_net.ko guest driver seeing inconsistent results:
>
> # ifconfig eth0 192.168.0.1 netmask 255.255.255.0
> virtio_net virtio0: output:id 0 is not a head!
>
> To fix this, proceed the same as we do for irqfd: add a parameter to
> virtio_queue_set_host_notifier_fd_handler and in that case only set
> the notifier, not the handler.
>
> Cc: Stefan Hajnoczi
> Signed-off-by: Paolo Bonzini
Applied. Thanks.
Regards,
Anthony Liguori
> ---
> hw/virtio-pci.c | 14 +++---
> hw/virtio.c | 7 +--
> hw/virtio.h | 3 ++-
> 3 file modificati, 14 inserzioni(+), 10 rimozioni(-)
>
> diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
> index 3ab9747..6133626 100644
> --- a/hw/virtio-pci.c
> +++ b/hw/virtio-pci.c
> @@ -160,7 +160,7 @@ static int virtio_pci_load_queue(void * opaque, int n,
> QEMUFile *f)
> }
>
> static int virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy,
> - int n, bool assign)
> + int n, bool assign, bool
> set_handler)
> {
> VirtQueue *vq = virtio_get_queue(proxy->vdev, n);
> EventNotifier *notifier = virtio_queue_get_host_notifier(vq);
> @@ -173,13 +173,13 @@ static int
> virtio_pci_set_host_notifier_internal(VirtIOPCIProxy *proxy,
> __func__, r);
> return r;
> }
> -virtio_queue_set_host_notifier_fd_handler(vq, true);
> +virtio_queue_set_host_notifier_fd_handler(vq, true, set_handler);
> memory_region_add_eventfd(&proxy->bar, VIRTIO_PCI_QUEUE_NOTIFY, 2,
>true, n, notifier);
> } else {
> memory_region_del_eventfd(&proxy->bar, VIRTIO_PCI_QUEUE_NOTIFY, 2,
>true, n, notifier);
> -virtio_queue_set_host_notifier_fd_handler(vq, false);
> +virtio_queue_set_host_notifier_fd_handler(vq, false, false);
> event_notifier_cleanup(notifier);
> }
> return r;
> @@ -200,7 +200,7 @@ static void virtio_pci_start_ioeventfd(VirtIOPCIProxy
> *proxy)
> continue;
> }
>
> -r = virtio_pci_set_host_notifier_internal(proxy, n, true);
> +r = virtio_pci_set_host_notifier_internal(proxy, n, true, true);
> if (r < 0) {
> goto assign_error;
> }
> @@ -214,7 +214,7 @@ assign_error:
> continue;
> }
>
> -r = virtio_pci_set_host_notifier_internal(proxy, n, false);
> +r = virtio_pci_set_host_notifier_internal(proxy, n, false, false);
> assert(r >= 0);
> }
> proxy->ioeventfd_started = false;
> @@ -235,7 +235,7 @@ static void virtio_pci_stop_ioeventfd(VirtIOPCIProxy
> *proxy)
> continue;
> }
>
> -r = virtio_pci_set_host_notifier_internal(proxy, n, false);
> +r = virtio_pci_set_host_notifier_internal(proxy, n, false, false);
> assert(r >= 0);
> }
> proxy->ioeventfd_started = false;
> @@ -683,7 +683,7 @@ static int virtio_pci_set_host_notifier(void *opaque, int
> n, bool assign)
> * currently only stops on status change away from ok,
> * reset, vmstop and such. If we do add code to start here,
> * need to check vmstate, device state etc. */
> -return virtio_pci_set_host_notifier_internal(proxy, n, assign);
> +return virtio_pci_set_host_notifier_internal(proxy, n, assign, false);
> }
>
> static void virtio_pci_vmstate_change(void *opaque, bool running)
> diff --git a/hw/virtio.c b/hw/virtio.c
> index d146f86..89e6d6f 100644
> --- a/hw/virtio.c
> +++ b/hw/virtio.c
> @@ -1021,13 +1021,16 @@ static void
> virtio_queue_host_notifier_read(EventNotifier *n)
> }
> }
>
> -void virtio_queue_set_host_notifier_fd_handler(VirtQueue *vq, bool assign)
> +void virtio_queue_set_host_notifier_fd_handler(VirtQueue *vq, bool assign,
> + bool set_handler)
> {
> -if (assign) {
> +if (assign && set_handler) {
> event_notifier_set_handler(&vq->host_notifier,
> virtio_queue_host_notifier_read);
> } else {
> event_notifier_set_handler(&vq->host_notifier, NULL);
> +}
> +if (!assi
[Qemu-devel] [PATCH] slirp: fix build on mingw32
in_addr_t isn't available on mingw32. Just use an unsigned long instead. I
considered typedef'ing in_addr_t on mingw32 but this would potentially be
brittle if mingw32 did introduce the type.
Cc: Jan Kiszka
Signed-off-by: Anthony Liguori
---
slirp/main.h |2 +-
slirp/slirp.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/slirp/main.h b/slirp/main.h
index bf601e2..1f3b84d 100644
--- a/slirp/main.h
+++ b/slirp/main.h
@@ -31,7 +31,7 @@ extern char *exec_shell;
extern u_int curtime;
extern fd_set *global_readfds, *global_writefds, *global_xfds;
extern struct in_addr loopback_addr;
-extern in_addr_t loopback_mask;
+extern unsigned long loopback_mask;
extern char *username;
extern char *socket_path;
extern int towrite_max;
diff --git a/slirp/slirp.c b/slirp/slirp.c
index 9787104..38e0a21 100644
--- a/slirp/slirp.c
+++ b/slirp/slirp.c
@@ -30,7 +30,7 @@
/* host loopback address */
struct in_addr loopback_addr;
/* host loopback network mask */
-in_addr_t loopback_mask;
+unsigned long loopback_mask;
/* emulated hosts use the MAC addr 52:55:IP:IP:IP:IP */
static const uint8_t special_ethaddr[ETH_ALEN] = {
--
1.7.5.4
Re: [Qemu-devel] [PULL 00/12] Block patches
Kevin Wolf writes: > The following changes since commit 26b9b5fe17cc1b6be2e8bf8b9d16094f420bb8ad: > > virtio: fix vhost handling (2012-08-06 14:01:44 -0500) > > are available in the git repository at: > http://repo.or.cz/r/qemu/kevin.git for-anthony Pulled. Thanks. Regards, Anthony Liguori > > Dong Xu Wang (1): > qemu-img: use QemuOpts instead of QEMUOptionParameter in resize function > > Kevin Wolf (1): > qemu-iotests: Be more flexible with image creation options > > Markus Armbruster (1): > ide scsi: Mess with geometry only for hard disk devices > > Paolo Bonzini (1): > qapi: generalize documentation of streaming commands > > Stefan Hajnoczi (8): > qemu-iotests: add qed.py image manipulation utility > docs: add dirty bit to qcow2 specification > qcow2: introduce dirty bit > docs: add lazy refcounts bit to qcow2 specification > qemu-iotests: ignore qemu-img create lazy_refcounts output > qcow2: implement lazy refcounts > qemu-io: add "abort" command to simulate program crash > qemu-iotests: add 039 qcow2 lazy refcounts test > > block/qcow2-cluster.c|5 +- > block/qcow2.c| 123 +-- > block/qcow2.h| 21 > block_int.h | 26 +++-- > docs/specs/qcow2.txt | 14 ++- > hmp-commands.hx |2 +- > hw/ide/qdev.c|3 +- > hw/scsi-disk.c |3 +- > qapi-schema.json | 17 ++-- > qemu-img.c | 28 +++-- > qemu-io.c| 12 ++ > tests/qemu-iotests/031.out | 20 ++-- > tests/qemu-iotests/036.out |4 +- > tests/qemu-iotests/039 | 136 > tests/qemu-iotests/039.out | 53 ++ > tests/qemu-iotests/common.rc |7 +- > tests/qemu-iotests/group |1 + > tests/qemu-iotests/qed.py| 235 > ++ > 18 files changed, 650 insertions(+), 60 deletions(-) > create mode 100755 tests/qemu-iotests/039 > create mode 100644 tests/qemu-iotests/039.out > create mode 100755 tests/qemu-iotests/qed.py
Re: [Qemu-devel] [PULL 0/2] usb patch queue
Gerd Hoffmann writes: > Hi, > > This is the usb patch queue, pretty small this time, > carrying a little fix for usb-storage. > > please pull, > Gerd Pulled. Thanks. Regards, Anthony Liguori > > Gerd Hoffmann (2): > usb-storage: improve debug logging > usb-storage: fix SYNCHRONIZE_CACHE > > hw/usb/dev-storage.c | 11 +-- > 1 files changed, 9 insertions(+), 2 deletions(-) > > The following changes since commit 0b8db8fe15d17a529a5ea90614c11e9f031dfee8: > > slirp: fix build on mingw32 (2012-08-06 19:31:55 -0500) > > are available in the git repository at: > git://git.kraxel.org/qemu usb.58 > > Gerd Hoffmann (2): > usb-storage: improve debug logging > usb-storage: fix SYNCHRONIZE_CACHE > > hw/usb/dev-storage.c | 11 +-- > 1 files changed, 9 insertions(+), 2 deletions(-)
Re: [Qemu-devel] [PATCH 4/6] migration: remove iohandlers before closing the file
Paolo Bonzini writes:
> This will be needed as soon as process_incoming_migration will set
> handlers on the file. The patch may be removed if
...?
Regards,
Anthony Liguori
>
> Signed-off-by: Paolo Bonzini
> ---
> savevm.c | 3 +++
> 1 file modificato, 3 inserzioni(+)
>
> diff --git a/savevm.c b/savevm.c
> index 57cae52..8f075e5 100644
> --- a/savevm.c
> +++ b/savevm.c
> @@ -210,6 +210,7 @@ static int socket_get_buffer(void *opaque, uint8_t *buf,
> int64_t pos, int size)
> static int socket_close(void *opaque)
> {
> QEMUFileSocket *s = opaque;
> +qemu_set_fd_handler(s->fd, NULL, NULL, NULL);
> close(s->fd);
> g_free(s);
> return 0;
> @@ -238,6 +239,7 @@ static int stdio_pclose(void *opaque)
> {
> QEMUFileStdio *s = opaque;
> int ret;
> +qemu_set_fd_handler(fileno(s->stdio_file), NULL, NULL, NULL);
> ret = pclose(s->stdio_file);
> if (ret == -1) {
> ret = -errno;
> @@ -250,6 +252,7 @@ static int stdio_fclose(void *opaque)
> {
> QEMUFileStdio *s = opaque;
> int ret = 0;
> +qemu_set_fd_handler(fileno(s->stdio_file), NULL, NULL, NULL);
> if (fclose(s->stdio_file) == EOF) {
> ret = -errno;
> }
> --
> 1.7.11.2
Re: [Qemu-devel] For all targets and machine types: "start to monitor" smoke test
Markus Armbruster writes:
> Very basic smoke test: start QEMU with -monitor stdio, quit immediately.
> Wouldn't it be nice if that worked for all targets and machine types?
>
> Many targets have mandatory options (fun oxymoron), such as -kernel or
> -pflash. Can't stop me, I just try a bunch until something works.
>
> Many targets expect various files to be present, and some of them need
> to have the right size. Can't stop me, I hack up the file loaders until
> it works (silly patch appended). To do this right, we'd need the
> required files or suitable mock-ups in-tree.
I attempted something similar in the past and ran into similar results.
>
> Test script:
>
> #!/bin/sh
> for i in ../qemu/bld/*-softmmu/qemu-system-*
> do
> echo "= $i ="
> for m in `$i -M help | sed -n '2,$s/ .*//gp'`
> do
> echo "== $m =="
> for k in "" "-kernel /dev/null" "-pflash /dev/null" "-pflash /dev/null
> -pflash /dev/null -kernel /dev/null"
> do
> echo "=== ${k:-(default)} ==="
> if echo q | QEMU_AUDIO_DRV=none $i -S -vnc :0 -M $m $k -monitor
> stdio | fgrep -q '(qemu)'
> then break
> else false
> fi
> done
> if [ $? -eq 0 ]
> then echo "*** Success $k ***"
> else echo '*** Fail'
> fi
> done
> done
>
> Summary of results:
>
> * Bad unexplained
>
> qemu-system-arm lm3s811evb
> qemu-system-arm lm3s6965evb
> qemu-system-arm: /work/armbru/qemu/hw/qdev.c:310: qdev_get_gpio_in:
> Assertion `n >= 0 && n < dev->num_gpio_in' failed.
>
> qemu-system-ppc64 prep
> qemu: hardware error: Unknown device 'i82378' for bus 'PCI'
>
> qemu-system-ppcemb ref405ep
> qemu-system-ppcemb taihu
> Unable to find PowerPC 405ep CPU definition
>
> qemu-system-ppcemb mac99
> qemu-system-ppcemb g3beige
> qemu-system-ppcemb prep
> Unable to find PowerPC CPU definition
>
> qemu-system-xtensaeb lx60
> qemu-system-xtensaeb lx200
> qemu-system-xtensaeb sim
> Unable to find CPU definition
>
> I'm not saying these are all busted. If you know how to "start to
> monitor" one of these, let us know.
Perhaps we could add a QEMUMachine parameter that indicates that the
machine doesn't start without special options.
At least a handful of these machines cannot be run without the use of
non-free binaries firmware :-(
Regards,
Anthony Liguori
>
> * Not easily testable for me
>
> qemu-system-i386 xenfv
> qemu-system-i386 xenpv
> qemu-system-x86_64 xenfv
> qemu-system-x86_64 xenpv
> failed to initialize Xen: Operation not permitted
> No accelerator found!
>
> * Good
>
> qemu-system-alpha clipper
> qemu-system-arm collie nuri smdkc210 connex verdex highbank
> integratorcp kzm mainstone musicpal n800 n810 sx1 sx1-v1 cheetah
> realview-eb realview-eb-mpcore realview-pb-a8 realview-pbx-a9
> akita spitz borzoi terrier tosa versatilepb versatileab
> vexpress-a9 vexpress-a15 xilinx-zynq-a9 z2
> qemu-system-cris axis-dev88
> qemu-system-i386 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13
> pc-0.12 pc-0.11 pc-0.10 isapc
> qemu-system-lm32 lm32-uclinux lm32-evr milkymist
> qemu-system-m68k an5206 dummy mcf5208evb
> qemu-system-microblaze petalogix-ml605 petalogix-s3adsp1800
> qemu-system-microblazeel petalogix-ml605 petalogix-s3adsp1800
> qemu-system-mips magnum pica61 malta mipssim mips
> qemu-system-mips64 magnum pica61 malta mipssim mips
> qemu-system-mips64el fulong2e magnum pica61 malta mipssim mips
> qemu-system-mipsel magnum pica61 malta mipssim mips
> qemu-system-or32 or32-sim
> qemu-system-ppc ref405ep taihu bamboo mac99 g3beige prep virtex-ml507
> qemu-system-ppc64 ref405ep taihu bamboo mac99 g3beige virtex-ml507
> qemu-system-ppcemb bamboo virtex-ml507
> qemu-system-s390x s390 s390-virtio
> qemu-system-sh4 r2d shix
> qemu-system-sh4eb r2d shix
> qemu-system-sparc leon3_generic SS-5 SS-10 SS-600MP SS-20 Voyager LX
> SS-4 SPARCClassic SPARCbook SS-1000 SS-2000 SS-2
> qemu-system-sparc64 sun4u sun4v Niagara
> qemu-system-x86_64 pc pc-1.2 pc-1.1 pc-1.0 pc-0.15 pc-0.14 pc-0.13
> pc-0.12 pc-0.11 pc-0.10 isapc
> qemu-system-xtensa lx60 lx200 sim
>
>
> diff --git a/hw/loader.c b/hw/loader.c
> index 33acc2f..e23af6c 100644
> --- a/hw/loader.c
> +++ b/hw/loader.c
> @@ -62,7 +62,7 @@ int get_image_size(const char *filename)
> int fd, size;
> fd = open(f
Re: [Qemu-devel] [PATCH 2/2] pseries: Use new hook to correct reset sequence
On Aug 7, 2012 5:32 PM, "Andreas Färber" wrote: > > Am 08.08.2012 00:02, schrieb Benjamin Herrenschmidt: > > On Fri, 2012-08-03 at 17:01 +0200, Andreas Färber wrote: > >> > >> I have posted a suggestion where CPU reset is triggered by "the > >> machine > >> as an abstract concept" (needs a bit of tweaking still, but the > >> general > >> idea is there). > >> Based on that, shouldn't it be rather easy to add a Notifier similar > >> to > >> "machine init done" that lets individual machines do post-reset setup? > >> I.e. not have QEMUMachine trigger and control the reset. > >> > > > > Note that we really want pre and post reset vs the device reset. > > > > That's why the machine should be the one in charge. The top level of the > > reset sequencing is -not- the CPU, it's the machine. All machines (or > > SoCs) have some kind of reset controller and provide facilities for > > resetting individual devices, busses, processor cores the global > > "system" reset (when it exists) itself might have interesting ordering > > or sequencing requirements. > > > > Now, to fix our immediate problem on ppc for 1.2 the hook proposed by > > Anthony for which David sent a patch does the job just fine, it allows > > us to clean out all our iommu tables before the device-reset, meaning > > that in-flights DMA cannot overwrite the various "files" (SLOF image > > etc that are auto-loaded via reset handlers implicitely created by > > load_image_targphys), and we can then do some post-initializations as > > well to get things ready for a restart (rebuild the device-tree, etc...) > > That's all good, except for embedded machines without such implicit > reset handling. It does contradict the "a machine is just a config file, > setting up QOM objects" concept, but I was not the one to push that! :) > I will be without a proper email client for 24 hours so I'll keep this brief for now. What Ben et al are trying to model is something that exists outside of the model of virtual hardware that QOM is designed for. Since they are trying to model something that exists outside the scope of virtual hardware, they need something that exists at a higher level. They need a per machine hook before and after devices are created. This is okay and it turns out it can be handy for other machines too that do similiar could not exist outside of a simulator features. Regards, Anthony Liguori > What I was thinking about however were those mentioned individual cores > being reset using cpu_reset(). If we want to piggy-back some > machine-specific register initialization for individual CPUStates then > QEMUMachine::reset is not going to be enough because it only gets > triggered for complete system reset. My suggestion was thus to just call > cpu_reset() in your QEMUMachine::reset and have cpu_reset() take care of > its initialization wherever called from. Any of these solutions are easy > to implement for 1.2 if agreement is reached what people want. > > What I am missing from Anthony's side is some communication to machine > maintainers on the course to adopt before applying random patches. Right > now x86 and ppc are moving into opposite directions and arm, mips, etc. > maintainers may not even be aware of ongoing changes, and there's a > pending uc32 machine that should be reviewed in this light. > > Cheers, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [SeaBIOS] [PULL 0/1] update qemu seabios / seabios release?
Gerd Hoffmann writes: > Hi, > > This pull updates seabios in qemu to the latest bits from seabios > master, so the upcoming 1.2 qemu release gets all the new shiny > stuff added recently. I'd like to have a new seabios release for > inclusion into qemu 1.2 which is planned for September 1st. > > So how about this plan: > - merge seabios snapshot now (this pull req), so it gets testing > in the qemu testing & release candidates phase > - put seabios into bugfixing freeze too (now or in a few days), > fix any issues poping up in testing. > - roll out seabios release by end of august, so it can be included > into qemu 1.2 We really would need a SeaBIOS release by no later than August 21st to do this. The 1.2 release is on September 1st but we're in hard freeze starting on August 15th. I wouldn't want to make any changes later than the 21st. Regards, Anthony Liguori > > Anthony? Kevin? Fine are you ok with this? > > qemu release schedule is here: http://wiki.qemu.org/Planning/1.2 > > cheers, > Gerd > > Gerd Hoffmann (1): > update seabios to latest master > > pc-bios/bios.bin | Bin 131072 -> 131072 bytes > roms/seabios |2 +- > 2 files changed, 1 insertions(+), 1 deletions(-) > > The following changes since commit 0b8db8fe15d17a529a5ea90614c11e9f031dfee8: > > slirp: fix build on mingw32 (2012-08-06 19:31:55 -0500) > > are available in the git repository at: > git://git.kraxel.org/qemu seabios-5a02306 > > Gerd Hoffmann (1): > update seabios to latest master > > pc-bios/bios.bin | Bin 131072 -> 131072 bytes > roms/seabios |2 +- > 2 files changed, 1 insertions(+), 1 deletions(-) > > ___ > SeaBIOS mailing list > seab...@seabios.org > http://www.seabios.org/mailman/listinfo/seabios
Re: [Qemu-devel] [PATCH v3] Support 'help' as a synonym for '?' in command line options
Eduardo Habkost writes:
> On Thu, Aug 09, 2012 at 10:02:22PM +0100, Peter Maydell wrote:
>> On 9 August 2012 20:25, Eduardo Habkost wrote:
>> > On Fri, Aug 03, 2012 at 03:42:39PM -0500, Anthony Liguori wrote:
>> >> Peter Maydell writes:
>> >> > For command line options which permit '?' meaning 'please list the
>> >> > permitted values', add support for 'help' as a synonym, by abstracting
>> >> > the check out into a helper function.
>>
>> >> Applied. Thanks.
>> >
>> > I just found out that this patch broke "-cpu ?dump", "-cpu ?cpuid", and
>> > "-cpu ?model":
>>
>> These options appear to be completely undocumented. They're also pretty
>> ugly syntax and seem to be x86 specific.
>
> Agreed. I wasn't aware it was completely undocumented, I thought there
> was documentation somewhere.
>
>
>> However we can unbreak them
>> if we must with a patch like this:
>>
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -3215,7 +3215,11 @@ int main(int argc, char **argv, char **envp)
>> */
>> cpudef_init();
>>
>> -if (cpu_model && is_help_option(cpu_model)) {
>> +/* We have to check for "starts with '?' as well as is_help_option
>> + * to support targets which implement various weird help options
>> + * via '?thingy' syntax.
>> + */
>> +if (cpu_model && (is_help_option(cpu_model) || *cpu_model == '?')) {
>> list_cpus(stdout, &fprintf, cpu_model);
>> exit(0);
>> }
>>
>> (will send as a proper patch with commit message and signoff tomorrow).
>>
>> Any suggestions for what the sane syntax for these options would be?
>> (ie the analogous change to having '?' go to 'help').
>
> What about "-cpu help,dump" or "-cpu help=dump"?
Let's just drop the feature. I doubt a user would ever do this.
For 1.3, I'd like to introduce glib option groups and allow for group
specific help options. IOW, --help-cpu
Regards,
Anthony Liguori
>
> --
> Eduardo
Re: [Qemu-devel] [PATCH 1/7] qmp: introduce device-list-properties command
Luiz Capitulino writes:
> On Fri, 27 Jul 2012 08:37:13 -0500
> Anthony Liguori wrote:
>
>> This can be used in conjunction with qom-list-types to determine the
>> supported
>> set of devices and their parameters.
>>
>> Signed-off-by: Anthony Liguori
>> ---
>> qapi-schema.json | 28
>> qmp-commands.hx |7 +++
>> qmp.c| 50 ++
>> 3 files changed, 85 insertions(+), 0 deletions(-)
>>
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index bc55ed2..015a84a 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -1727,6 +1727,34 @@
>>'returns': [ 'ObjectTypeInfo' ] }
>>
>> ##
>> +# @DevicePropertyInfo:
>> +#
>> +# Information about device properties.
>> +#
>> +# @name: the name of the property
>> +# @type: the typename of the property
>> +#
>> +# Since: 1.2
>> +##
>> +{ 'type': 'DevicePropertyInfo',
>> + 'data': { 'name': 'str', 'type': 'str' } }
>> +
>> +##
>> +# @device-list-properties:
>> +#
>> +# List properties associated with a device.
>> +#
>> +# @typename: the type name of a device
>> +#
>> +# Returns: a list of DevicePropertyInfo describing a devices properties
>> +#
>> +# Since: 1.2
>> +##
>> +{ 'command': 'device-list-properties',
>> + 'data': { 'typename': 'str'},
>> + 'returns': [ 'DevicePropertyInfo' ] }
>
> I find it a bit weird that the argument is called typename but everything else
> refers to that same argument as a device.
>
> Maybe we should rename this to device-type-list-properties,
> DeviceTypePropertyInfo
> and typename to name.
I see where you're coming from but I think I'd prefer to leave it
as-is. 'DeviceType' isn't really a concept in QEMU.
Regards,
Anthony Liguori
>
> But that's minor, I won't oppose to it as it's.
>
>> +
>> +##
>> # @migrate
>> #
>> # Migrates the current running guest to another Virtual Machine.
>> diff --git a/qmp-commands.hx b/qmp-commands.hx
>> index e3cf3c5..5c55528 100644
>> --- a/qmp-commands.hx
>> +++ b/qmp-commands.hx
>> @@ -2215,3 +2215,10 @@ EQMP
>> .args_type = "implements:s?,abstract:b?",
>> .mhandler.cmd_new = qmp_marshal_input_qom_list_types,
>> },
>> +
>> +{
>> +.name = "device-list-properties",
>> +.args_type = "typename:s",
>> +.mhandler.cmd_new = qmp_marshal_input_device_list_properties,
>> +},
>> +
>> diff --git a/qmp.c b/qmp.c
>> index fee9fb2..254a32f 100644
>> --- a/qmp.c
>> +++ b/qmp.c
>> @@ -417,3 +417,53 @@ ObjectTypeInfoList *qmp_qom_list_types(bool
>> has_implements,
>>
>> return ret;
>> }
>> +
>> +DevicePropertyInfoList *qmp_device_list_properties(const char *typename,
>> + Error **errp)
>> +{
>> +ObjectClass *klass;
>> +Property *prop;
>> +DevicePropertyInfoList *prop_list = NULL;
>> +
>> +klass = object_class_by_name(typename);
>> +if (klass == NULL) {
>> +error_set(errp, QERR_DEVICE_NOT_FOUND, typename);
>> +return NULL;
>> +}
>> +
>> +klass = object_class_dynamic_cast(klass, TYPE_DEVICE);
>> +if (klass == NULL) {
>> +error_set(errp, QERR_INVALID_PARAMETER_VALUE,
>> + "name", TYPE_DEVICE);
>> +return NULL;
>> +}
>> +
>> +do {
>> +for (prop = DEVICE_CLASS(klass)->props; prop && prop->name; prop++)
>> {
>> +DevicePropertyInfoList *entry;
>> +DevicePropertyInfo *info;
>> +
>> +/*
>> + * TODO Properties without a parser are just for dirty hacks.
>> + * qdev_prop_ptr is the only such PropertyInfo. It's marked
>> + * for removal. This conditional should be removed along with
>> + * it.
>> + */
>> +if (!prop->info->set) {
>> +continue; /* no way to set it, don't show */
>> +}
>> +
>> +info = g_malloc0(sizeof(*info));
>> +info->name = g_strdup(prop->name);
>> +info->type = g_strdup(prop->info->legacy_name ?:
>> prop->info->name);
>> +
>> +entry = g_malloc0(sizeof(*entry));
>> +entry->value = info;
>> +entry->next = prop_list;
>> +prop_list = entry;
>> +}
>> +klass = object_class_get_parent(klass);
>> +} while (klass != object_class_by_name(TYPE_DEVICE));
>> +
>> +return prop_list;
>> +}
Re: [Qemu-devel] [PATCH 2/7] qapi: mark QOM commands stable
Luiz Capitulino writes:
> On Fri, 27 Jul 2012 08:37:14 -0500
> Anthony Liguori wrote:
>
>> We've had a cycle to tweak. It is time to commit to supporting them.
>
> qmp_qom_get() and qpm_qom_set() still use the legacy monitor interface, can't
> we convert it to the qapi?
qapi doesn't have a concept of type passthrough yet. If it was added,
it could be converted.
Regards,
Anthony Liguori
>
>>
>> Signed-off-by: Anthony Liguori
>> ---
>> qapi-schema.json | 19 ---
>> 1 files changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 015a84a..28e9914 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -1360,9 +1360,7 @@
>> #4) A link type in the form 'link' where subtype is a qdev
>> # device type name. Link properties form the device model graph.
>> #
>> -# Since: 1.1
>> -#
>> -# Notes: This type is experimental. Its syntax may change in future
>> releases.
>> +# Since: 1.2
>> ##
>> { 'type': 'ObjectPropertyInfo',
>>'data': { 'name': 'str', 'type': 'str' } }
>> @@ -1379,10 +1377,7 @@
>> # Returns: a list of @ObjectPropertyInfo that describe the properties of the
>> # object.
>> #
>> -# Since: 1.1
>> -#
>> -# Notes: This command is experimental. It's syntax may change in future
>> -#releases.
>> +# Since: 1.2
>> ##
>> { 'command': 'qom-list',
>>'data': { 'path': 'str' },
>> @@ -1418,9 +1413,7 @@
>> # returns as #str pathnames. All integer property types (u8, u16,
>> etc)
>> # are returned as #int.
>> #
>> -# Since: 1.1
>> -#
>> -# Notes: This command is experimental and may change syntax in future
>> releases.
>> +# Since: 1.2
>> ##
>> { 'command': 'qom-get',
>>'data': { 'path': 'str', 'property': 'str' },
>> @@ -1439,9 +1432,7 @@
>> # @value: a value who's type is appropriate for the property type. See
>> @qom-get
>> # for a description of type mapping.
>> #
>> -# Since: 1.1
>> -#
>> -# Notes: This command is experimental and may change syntax in future
>> releases.
>> +# Since: 1.2
>> ##
>> { 'command': 'qom-set',
>>'data': { 'path': 'str', 'property': 'str', 'value': 'visitor' },
>> @@ -1719,8 +1710,6 @@
>> # Returns: a list of @ObjectTypeInfo or an empty list if no results are
>> found
>> #
>> # Since: 1.1
>> -#
>> -# Notes: This command is experimental and may change syntax in future
>> releases.
>> ##
>> { 'command': 'qom-list-types',
>>'data': { '*implements': 'str', '*abstract': 'bool' },
Re: [Qemu-devel] [PATCH 3/7] qapi: add query-machines command
Luiz Capitulino writes:
> On Fri, 27 Jul 2012 08:37:15 -0500
> Anthony Liguori wrote:
>
>> This provides the same output as -M ? but in a structured way.
>>
>> Signed-off-by: Anthony Liguori
>> ---
>> qapi-schema.json | 28
>> qmp-commands.hx |6 ++
>> vl.c | 31 +++
>> 3 files changed, 65 insertions(+), 0 deletions(-)
>>
>> diff --git a/qapi-schema.json b/qapi-schema.json
>> index 28e9914..5b47026 100644
>> --- a/qapi-schema.json
>> +++ b/qapi-schema.json
>> @@ -2200,3 +2200,31 @@
>> # Since: 0.14.0
>> ##
>> { 'command': 'closefd', 'data': {'fdname': 'str'} }
>> +
>> +##
>> +# @MachineInfo:
>> +#
>> +# Information describing a machine.
>> +#
>> +# @name: the name of the machine
>> +#
>> +# @alias: #optional an alias for the machine name
>> +#
>> +# @default: #optional whether the machine is default
>
> Why is default optional?
Brievity.
Regards,
Anthony Liguori
>
>> +#
>> +# Since: 1.2.0
>> +##
>> +{ 'type': 'MachineInfo',
>> + 'data': { 'name': 'str', '*alias': 'str',
>> +'*is-default': 'bool' } }
>> +
>> +##
>> +# @query-machines:
>> +#
>> +# Return a list of supported machines
>> +#
>> +# Returns: a list of MachineInfo
>> +#
>> +# Since: 1.2.0
>> +##
>> +{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
>> diff --git a/qmp-commands.hx b/qmp-commands.hx
>> index 5c55528..a6f82fc 100644
>> --- a/qmp-commands.hx
>> +++ b/qmp-commands.hx
>> @@ -,3 +,9 @@ EQMP
>> .mhandler.cmd_new = qmp_marshal_input_device_list_properties,
>> },
>>
>> +{
>> +.name = "query-machines",
>> +.args_type = "",
>> +.mhandler.cmd_new = qmp_marshal_input_query_machines,
>> +},
>> +
>> diff --git a/vl.c b/vl.c
>> index 8904db1..cd900e0 100644
>> --- a/vl.c
>> +++ b/vl.c
>> @@ -1209,6 +1209,37 @@ QEMUMachine *find_default_machine(void)
>> return NULL;
>> }
>>
>> +MachineInfoList *qmp_query_machines(Error **errp)
>> +{
>> +MachineInfoList *mach_list = NULL;
>> +QEMUMachine *m;
>> +
>> +for (m = first_machine; m; m = m->next) {
>> +MachineInfoList *entry;
>> +MachineInfo *info;
>> +
>> +info = g_malloc0(sizeof(*info));
>> +if (m->is_default) {
>> +info->has_is_default = true;
>> +info->is_default = true;
>> +}
>> +
>> +if (m->alias) {
>> +info->has_alias = true;
>> +info->alias = g_strdup(m->alias);
>> +}
>> +
>> +info->name = g_strdup(m->name);
>> +
>> +entry = g_malloc0(sizeof(*entry));
>> +entry->value = info;
>> +entry->next = mach_list;
>> +mach_list = entry;
>> +}
>> +
>> +return mach_list;
>> +}
>> +
>> /***/
>> /* main execution loop */
>>
Re: [Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpudefs
Eduardo Habkost writes:
> On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
>> Signed-off-by: Anthony Liguori
>> ---
>> target-i386/cpu.c | 22 ++
>> 1 files changed, 22 insertions(+), 0 deletions(-)
>>
>> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> index 6b9659f..b398439 100644
>> --- a/target-i386/cpu.c
>> +++ b/target-i386/cpu.c
>> @@ -28,6 +28,7 @@
>> #include "qemu-config.h"
>>
>> #include "qapi/qapi-visit-core.h"
>> +#include "qmp-commands.h"
>>
>> #include "hyperv.h"
>>
>> @@ -1123,6 +1124,27 @@ void x86_cpu_list(FILE *f, fprintf_function
>> cpu_fprintf, const char *optarg)
>> }
>> }
>>
>> +CpuDefInfoList *qmp_query_cpudefs(Error **errp)
>> +{
>> +CpuDefInfoList *cpu_list = NULL;
>> +x86_def_t *def;
>> +
>> +for (def = x86_defs; def; def = def->next) {
>> +CpuDefInfoList *entry;
>> +CpuDefInfo *info;
>> +
>> +info = g_malloc0(sizeof(*info));
>> +info->name = g_strdup(def->name);
>> +
>> +entry = g_malloc0(sizeof(*entry));
>> +entry->value = info;
>> +entry->next = cpu_list;
>> +cpu_list = entry;
>> +}
>> +
>> +return cpu_list;
>> +}
>
> How would the interface look like once we:
> - let libvirt know which features are available on each CPU model
> (libvirt needs that information[1]); and
I'm not sure I understand why libvirt needs this information. Can you
elaborate?
> - add machine-type-specific cpudef compatibility changes?
I think we've discussed this in IRC. I don't think we need to worry
about this.
> Would the command report different results depending on -machine?
No.
>
> Would the command return the latest cpudef without any machine-type
> hacks, and libvirt would have to query for the cpudef compatibility data
> for each machine-type and combine both pieces of information itself?
I'm not sure what you mean by compatibility data.
Regards,
Anthony Liguori
>
> [1] Note that it doesn't have to be low-level leaf-by-leaf
> register-by-register CPUID bits (I prefer a more high-level
> interface, myself), but it has to at least say "feature FOO is
> enabled/disabled" for a set of features libvirt cares about.
>
> --
> Eduardo
Re: [Qemu-devel] [PATCH 3/7] qapi: add query-machines command
Luiz Capitulino writes:
> On Fri, 10 Aug 2012 09:41:20 -0500
> Anthony Liguori wrote:
>
>> Luiz Capitulino writes:
>>
>> > On Fri, 27 Jul 2012 08:37:15 -0500
>> > Anthony Liguori wrote:
>> >
>> >> This provides the same output as -M ? but in a structured way.
>> >>
>> >> Signed-off-by: Anthony Liguori
>> >> ---
>> >> qapi-schema.json | 28
>> >> qmp-commands.hx |6 ++
>> >> vl.c | 31 +++
>> >> 3 files changed, 65 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/qapi-schema.json b/qapi-schema.json
>> >> index 28e9914..5b47026 100644
>> >> --- a/qapi-schema.json
>> >> +++ b/qapi-schema.json
>> >> @@ -2200,3 +2200,31 @@
>> >> # Since: 0.14.0
>> >> ##
>> >> { 'command': 'closefd', 'data': {'fdname': 'str'} }
>> >> +
>> >> +##
>> >> +# @MachineInfo:
>> >> +#
>> >> +# Information describing a machine.
>> >> +#
>> >> +# @name: the name of the machine
>> >> +#
>> >> +# @alias: #optional an alias for the machine name
>> >> +#
>> >> +# @default: #optional whether the machine is default
>> >
>> > Why is default optional?
>>
>> Brievity.
>
> Can you elaborate, please?
There is only one machine that is default. Having default=false for all
of the rest just adds a lot of unnecessary information in the response.
Regards,
Anthony Liguori
>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>> >
>> >> +#
>> >> +# Since: 1.2.0
>> >> +##
>> >> +{ 'type': 'MachineInfo',
>> >> + 'data': { 'name': 'str', '*alias': 'str',
>> >> +'*is-default': 'bool' } }
>> >> +
>> >> +##
>> >> +# @query-machines:
>> >> +#
>> >> +# Return a list of supported machines
>> >> +#
>> >> +# Returns: a list of MachineInfo
>> >> +#
>> >> +# Since: 1.2.0
>> >> +##
>> >> +{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
>> >> diff --git a/qmp-commands.hx b/qmp-commands.hx
>> >> index 5c55528..a6f82fc 100644
>> >> --- a/qmp-commands.hx
>> >> +++ b/qmp-commands.hx
>> >> @@ -,3 +,9 @@ EQMP
>> >> .mhandler.cmd_new = qmp_marshal_input_device_list_properties,
>> >> },
>> >>
>> >> +{
>> >> +.name = "query-machines",
>> >> +.args_type = "",
>> >> +.mhandler.cmd_new = qmp_marshal_input_query_machines,
>> >> +},
>> >> +
>> >> diff --git a/vl.c b/vl.c
>> >> index 8904db1..cd900e0 100644
>> >> --- a/vl.c
>> >> +++ b/vl.c
>> >> @@ -1209,6 +1209,37 @@ QEMUMachine *find_default_machine(void)
>> >> return NULL;
>> >> }
>> >>
>> >> +MachineInfoList *qmp_query_machines(Error **errp)
>> >> +{
>> >> +MachineInfoList *mach_list = NULL;
>> >> +QEMUMachine *m;
>> >> +
>> >> +for (m = first_machine; m; m = m->next) {
>> >> +MachineInfoList *entry;
>> >> +MachineInfo *info;
>> >> +
>> >> +info = g_malloc0(sizeof(*info));
>> >> +if (m->is_default) {
>> >> +info->has_is_default = true;
>> >> +info->is_default = true;
>> >> +}
>> >> +
>> >> +if (m->alias) {
>> >> +info->has_alias = true;
>> >> +info->alias = g_strdup(m->alias);
>> >> +}
>> >> +
>> >> +info->name = g_strdup(m->name);
>> >> +
>> >> +entry = g_malloc0(sizeof(*entry));
>> >> +entry->value = info;
>> >> +entry->next = mach_list;
>> >> +mach_list = entry;
>> >> +}
>> >> +
>> >> +return mach_list;
>> >> +}
>> >> +
>> >> /***/
>> >> /* main execution loop */
>> >>
>>
[Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols
This lets us provide a default implementation of a symbol which targets can override. Signed-off-by: Anthony Liguori --- compiler.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/compiler.h b/compiler.h index 736e770..f76921e 100644 --- a/compiler.h +++ b/compiler.h @@ -45,6 +45,7 @@ # define GCC_ATTR __attribute__((__unused__, format(gnu_printf, 1, 2))) # define GCC_FMT_ATTR(n, m) __attribute__((format(gnu_printf, n, m))) # endif +#define GCC_WEAK __attribute__((weak)) #else #define GCC_ATTR /**/ #define GCC_FMT_ATTR(n, m) -- 1.7.5.4
[Qemu-devel] [PATCH 1/7] qmp: introduce device-list-properties command
This can be used in conjunction with qom-list-types to determine the supported
set of devices and their parameters.
Signed-off-by: Anthony Liguori
---
qapi-schema.json | 28
qmp-commands.hx |7 +++
qmp.c| 50 ++
3 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index bd9c450..191a889 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1729,6 +1729,34 @@
'returns': [ 'ObjectTypeInfo' ] }
##
+# @DevicePropertyInfo:
+#
+# Information about device properties.
+#
+# @name: the name of the property
+# @type: the typename of the property
+#
+# Since: 1.2
+##
+{ 'type': 'DevicePropertyInfo',
+ 'data': { 'name': 'str', 'type': 'str' } }
+
+##
+# @device-list-properties:
+#
+# List properties associated with a device.
+#
+# @typename: the type name of a device
+#
+# Returns: a list of DevicePropertyInfo describing a devices properties
+#
+# Since: 1.2
+##
+{ 'command': 'device-list-properties',
+ 'data': { 'typename': 'str'},
+ 'returns': [ 'DevicePropertyInfo' ] }
+
+##
# @migrate
#
# Migrates the current running guest to another Virtual Machine.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index ac46638..52127a9 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2217,3 +2217,10 @@ EQMP
.args_type = "implements:s?,abstract:b?",
.mhandler.cmd_new = qmp_marshal_input_qom_list_types,
},
+
+{
+.name = "device-list-properties",
+.args_type = "typename:s",
+.mhandler.cmd_new = qmp_marshal_input_device_list_properties,
+},
+
diff --git a/qmp.c b/qmp.c
index fee9fb2..254a32f 100644
--- a/qmp.c
+++ b/qmp.c
@@ -417,3 +417,53 @@ ObjectTypeInfoList *qmp_qom_list_types(bool has_implements,
return ret;
}
+
+DevicePropertyInfoList *qmp_device_list_properties(const char *typename,
+ Error **errp)
+{
+ObjectClass *klass;
+Property *prop;
+DevicePropertyInfoList *prop_list = NULL;
+
+klass = object_class_by_name(typename);
+if (klass == NULL) {
+error_set(errp, QERR_DEVICE_NOT_FOUND, typename);
+return NULL;
+}
+
+klass = object_class_dynamic_cast(klass, TYPE_DEVICE);
+if (klass == NULL) {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE,
+ "name", TYPE_DEVICE);
+return NULL;
+}
+
+do {
+for (prop = DEVICE_CLASS(klass)->props; prop && prop->name; prop++) {
+DevicePropertyInfoList *entry;
+DevicePropertyInfo *info;
+
+/*
+ * TODO Properties without a parser are just for dirty hacks.
+ * qdev_prop_ptr is the only such PropertyInfo. It's marked
+ * for removal. This conditional should be removed along with
+ * it.
+ */
+if (!prop->info->set) {
+continue; /* no way to set it, don't show */
+}
+
+info = g_malloc0(sizeof(*info));
+info->name = g_strdup(prop->name);
+info->type = g_strdup(prop->info->legacy_name ?: prop->info->name);
+
+entry = g_malloc0(sizeof(*entry));
+entry->value = info;
+entry->next = prop_list;
+prop_list = entry;
+}
+klass = object_class_get_parent(klass);
+} while (klass != object_class_by_name(TYPE_DEVICE));
+
+return prop_list;
+}
--
1.7.5.4
[Qemu-devel] [PATCH 5/7] qapi: add query-cpu-definitions command (v2)
This command attempts to map to the behavior of -cpu ?. Unfortunately, the
output of this command differs wildly across targets.
To accommodate this, we use a weak symbol to implement a default version of the
command that fails with a QERR_NOT_SUPPORTED error code. Targets can then
override and implement this command if it makes sense for them.
Signed-off-by: Anthony Liguori
---
v1 -> v2
- rename query-cpudefs -> query-cpu-definitions
---
qapi-schema.json | 23 +++
qmp-commands.hx |6 ++
qmp.c|6 ++
3 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 1eb0b0f..f1da7ee 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2244,3 +2244,26 @@
# Since: 1.2.0
##
{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
+
+##
+# @CpuDefinitionInfo:
+#
+# Virtual CPU definition.
+#
+# @name: the name of the CPU definition
+#
+# Since: 1.2.0
+##
+{ 'type': 'CpuDefinitionInfo',
+ 'data': { 'name': 'str' } }
+
+##
+# @query-cpu-definitions:
+#
+# Return a list of supported virtual CPU definitions
+#
+# Returns: a list of CpuDefInfo
+#
+# Since: 1.2.0
+##
+{ 'command': 'query-cpu-definitions', 'returns': ['CpuDefinitionInfo'] }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index f343772..4da2b86 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2230,3 +2230,9 @@ EQMP
.mhandler.cmd_new = qmp_marshal_input_query_machines,
},
+{
+.name = "query-cpu-definitions",
+.args_type = "",
+.mhandler.cmd_new = qmp_marshal_input_query_cpu_definitions,
+},
+
diff --git a/qmp.c b/qmp.c
index 254a32f..6c1e4e8 100644
--- a/qmp.c
+++ b/qmp.c
@@ -467,3 +467,9 @@ DevicePropertyInfoList *qmp_device_list_properties(const
char *typename,
return prop_list;
}
+
+CpuDefinitionInfoList GCC_WEAK *qmp_query_cpu_definitions(Error **errp)
+{
+error_set(errp, QERR_NOT_SUPPORTED);
+return NULL;
+}
--
1.7.5.4
[Qemu-devel] [PATCH 7/7] target-ppc: add implementation of query-cpu-definitions (v2)
Signed-off-by: Anthony Liguori
---
v1 -> v2
- rename query-cpudefs -> query-cpu-definitions
---
target-ppc/translate_init.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 5742229..6fe4168 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -27,6 +27,7 @@
#include "gdbstub.h"
#include
#include "kvm_ppc.h"
+#include "qmp-commands.h"
//#define PPC_DUMP_CPU
//#define PPC_DEBUG_SPR
@@ -10345,6 +10346,31 @@ void ppc_cpu_list (FILE *f, fprintf_function
cpu_fprintf)
}
}
+CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+{
+CpuDefinitionInfoList *cpu_list = NULL;
+int i;
+
+for (i = 0; i < ARRAY_SIZE(ppc_defs); i++) {
+CpuDefinitionInfoList *entry;
+CpuDefinitionInfo *info;
+
+if (!ppc_cpu_usable(&ppc_defs[i])) {
+continue;
+}
+
+info = g_malloc0(sizeof(*info));
+info->name = g_strdup(ppc_defs[i].name);
+
+entry = g_malloc0(sizeof(*entry));
+entry->value = info;
+entry->next = cpu_list;
+cpu_list = entry;
+}
+
+return cpu_list;
+}
+
/* CPUClass::reset() */
static void ppc_cpu_reset(CPUState *s)
{
--
1.7.5.4
Re: [Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpudefs
Eduardo Habkost writes:
> On Fri, Aug 10, 2012 at 09:43:21AM -0500, Anthony Liguori wrote:
>> Eduardo Habkost writes:
>>
>> > On Fri, Jul 27, 2012 at 08:37:18AM -0500, Anthony Liguori wrote:
>> >> Signed-off-by: Anthony Liguori
>> >> ---
>> >> target-i386/cpu.c | 22 ++
>> >> 1 files changed, 22 insertions(+), 0 deletions(-)
>> >>
>> >> diff --git a/target-i386/cpu.c b/target-i386/cpu.c
>> >> index 6b9659f..b398439 100644
>> >> --- a/target-i386/cpu.c
>> >> +++ b/target-i386/cpu.c
>> >> @@ -28,6 +28,7 @@
>> >> #include "qemu-config.h"
>> >>
>> >> #include "qapi/qapi-visit-core.h"
>> >> +#include "qmp-commands.h"
>> >>
>> >> #include "hyperv.h"
>> >>
>> >> @@ -1123,6 +1124,27 @@ void x86_cpu_list(FILE *f, fprintf_function
>> >> cpu_fprintf, const char *optarg)
>> >> }
>> >> }
>> >>
>> >> +CpuDefInfoList *qmp_query_cpudefs(Error **errp)
>> >> +{
>> >> +CpuDefInfoList *cpu_list = NULL;
>> >> +x86_def_t *def;
>> >> +
>> >> +for (def = x86_defs; def; def = def->next) {
>> >> +CpuDefInfoList *entry;
>> >> +CpuDefInfo *info;
>> >> +
>> >> +info = g_malloc0(sizeof(*info));
>> >> +info->name = g_strdup(def->name);
>> >> +
>> >> +entry = g_malloc0(sizeof(*entry));
>> >> +entry->value = info;
>> >> +entry->next = cpu_list;
>> >> +cpu_list = entry;
>> >> +}
>> >> +
>> >> +return cpu_list;
>> >> +}
>> >
>> > How would the interface look like once we:
>> > - let libvirt know which features are available on each CPU model
>> > (libvirt needs that information[1]); and
>>
>> I'm not sure I understand why libvirt needs this information. Can you
>> elaborate?
>
> I see two reasons:
>
> - The libvirt API has functions to tell the user which features are
> going to be enabled for each CPU model, so it needs to know which
> features are enabled or not, for each machine-type + cpu-model
> combination, so this information can be reported proeprly.
Ok, step number one is that CPU 'features' need to be defined more
formally. By formally, I mean via qapi-schema.json.
Then we can extend this command to return the set of features supported
by each CPU type.
The first step will need to sort out how this maps across architectures.
> - Also, if libvirt can enable/disable specific CPU features in the
> command-line, it just makes sens to know which ones are already
> enabled in each built-in CPU model.
>
> - Probing for migration: libvirt needs to know if a given CPU model on a
> host can be migrated to another host. To know that, two pieces of
> information are needed:
> A) Which CPU features are visible to the guest for a specific
> configuration;
> B) Which of those features are really supported by the host
> hardware+kernel+QEMU, on the destination host, so it can
> know if migration is really possible.
Note that what QEMU thinks it exposes is not necessarily what gets
exposed. KVM may mask additional features. How is this handled today?
>> > - add machine-type-specific cpudef compatibility changes?
>>
>> I think we've discussed this in IRC. I don't think we need to worry
>> about this.
>
> I remember discussing a lot about the mechanism we will use to add the
> compatibility changes, but I don t know how the query API will look
> like, after we implement this mechanism.
0) User-defined CPU definitions go away
- We already made a big step in this direction
1) CPU becomes a DeviceState
2) Features are expressed as properties
3) Same global mechanism used for everything else is used for CPUs
Regards,
Anthony Liguori
>> > Would the command report different results depending on -machine?
>>
>> No.
>
> The problem is:
>
> 1) We need to introduce fixes on a CPU model that changes the set of
>guest-visible features (add or remove a feature)[1];
> 2) The fix has to keep compatibility, so older machine-types will
>keep exposing the old set of gues-visible features;
>- That means different machine-types will have different CPU
> features being exposed.
> 3) libvirt needs to control/know which guest-visible CPU features are
>availab
[Qemu-devel] [PATCH 3/7] qapi: add query-machines command
This provides the same output as -M ? but in a structured way.
Signed-off-by: Anthony Liguori
---
qapi-schema.json | 28
qmp-commands.hx |6 ++
vl.c | 31 +++
3 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index a938c8d..1eb0b0f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2216,3 +2216,31 @@
# Since: 0.14.0
##
{ 'command': 'closefd', 'data': {'fdname': 'str'} }
+
+##
+# @MachineInfo:
+#
+# Information describing a machine.
+#
+# @name: the name of the machine
+#
+# @alias: #optional an alias for the machine name
+#
+# @default: #optional whether the machine is default
+#
+# Since: 1.2.0
+##
+{ 'type': 'MachineInfo',
+ 'data': { 'name': 'str', '*alias': 'str',
+'*is-default': 'bool' } }
+
+##
+# @query-machines:
+#
+# Return a list of supported machines
+#
+# Returns: a list of MachineInfo
+#
+# Since: 1.2.0
+##
+{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 52127a9..f343772 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2224,3 +2224,9 @@ EQMP
.mhandler.cmd_new = qmp_marshal_input_device_list_properties,
},
+{
+.name = "query-machines",
+.args_type = "",
+.mhandler.cmd_new = qmp_marshal_input_query_machines,
+},
+
diff --git a/vl.c b/vl.c
index ad9b036..084d671 100644
--- a/vl.c
+++ b/vl.c
@@ -1213,6 +1213,37 @@ QEMUMachine *find_default_machine(void)
return NULL;
}
+MachineInfoList *qmp_query_machines(Error **errp)
+{
+MachineInfoList *mach_list = NULL;
+QEMUMachine *m;
+
+for (m = first_machine; m; m = m->next) {
+MachineInfoList *entry;
+MachineInfo *info;
+
+info = g_malloc0(sizeof(*info));
+if (m->is_default) {
+info->has_is_default = true;
+info->is_default = true;
+}
+
+if (m->alias) {
+info->has_alias = true;
+info->alias = g_strdup(m->alias);
+}
+
+info->name = g_strdup(m->name);
+
+entry = g_malloc0(sizeof(*entry));
+entry->value = info;
+entry->next = mach_list;
+mach_list = entry;
+}
+
+return mach_list;
+}
+
/***/
/* main execution loop */
--
1.7.5.4
[Qemu-devel] [PATCH 2/7] qapi: mark QOM commands stable
We've had a cycle to tweak. It is time to commit to supporting them.
Signed-off-by: Anthony Liguori
---
qapi-schema.json | 19 ---
1 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 191a889..a938c8d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1363,9 +1363,7 @@
#4) A link type in the form 'link' where subtype is a qdev
# device type name. Link properties form the device model graph.
#
-# Since: 1.1
-#
-# Notes: This type is experimental. Its syntax may change in future releases.
+# Since: 1.2
##
{ 'type': 'ObjectPropertyInfo',
'data': { 'name': 'str', 'type': 'str' } }
@@ -1382,10 +1380,7 @@
# Returns: a list of @ObjectPropertyInfo that describe the properties of the
# object.
#
-# Since: 1.1
-#
-# Notes: This command is experimental. It's syntax may change in future
-#releases.
+# Since: 1.2
##
{ 'command': 'qom-list',
'data': { 'path': 'str' },
@@ -1421,9 +1416,7 @@
# returns as #str pathnames. All integer property types (u8, u16,
etc)
# are returned as #int.
#
-# Since: 1.1
-#
-# Notes: This command is experimental and may change syntax in future releases.
+# Since: 1.2
##
{ 'command': 'qom-get',
'data': { 'path': 'str', 'property': 'str' },
@@ -1442,9 +1435,7 @@
# @value: a value who's type is appropriate for the property type. See
@qom-get
# for a description of type mapping.
#
-# Since: 1.1
-#
-# Notes: This command is experimental and may change syntax in future releases.
+# Since: 1.2
##
{ 'command': 'qom-set',
'data': { 'path': 'str', 'property': 'str', 'value': 'visitor' },
@@ -1721,8 +1712,6 @@
# Returns: a list of @ObjectTypeInfo or an empty list if no results are found
#
# Since: 1.1
-#
-# Notes: This command is experimental and may change syntax in future releases.
##
{ 'command': 'qom-list-types',
'data': { '*implements': 'str', '*abstract': 'bool' },
--
1.7.5.4
[Qemu-devel] [PATCH 0/7] qapi: add commands to remove the need (v2)
This series implements the necessary commands to implements danpb's idea to
remove -help parsing in libvirt. We would introduce all of these commands in
1.2 and then change the -help output starting in 1.3.
Here is Dan's plan from a previous thread:
Basically I'd sum up my new idea as "just use QMP".
* No new command line arguments like -capabilities
* libvirt invokes something like
$QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
* libvirt then runs a number of QMP commands to find out
what it needs to know. I'd expect the following existing
commands would be used
- query-version - already supported
- query-commands- already supported
- query-events - already supported
- query-kvm - already supported
- qom-{list,list-types,get} - already supported
- query-spice/vnc - already supported
And add the following new commands
- query-devices - new, -device ?, and/or -device NAME,? data
in QMP
- query-machines- new, -M ? in QMP
- query-cpu-types - new, -cpu ? in QMP
The above would take care of probably 50% of the current libvirt
capabilities probing, including a portion of the -help stuff. Then
there is all the rest of the crap we detect from the -help. We could
just take the view, that "as of 1.2", we assume everything we previously
detected is just available by default, and thus don't need to probe
it. For stuff that is QOM based, I expect we'll be able to detect new
features in the future using the qom-XXX monitor commands. For stuff
that is non-qdev, and non-qom, libvirt can just do a plain version
number check, unless we decide there is specific info worth exposing
via other new 'query-XXX' monitor commands.
Basically I'd sum up my new idea as "just use QMP".
* No new command line arguments like -capabilities
* libvirt invokes something like
$QEMUBINARY -qmp CHARDEV -nodefault -nodefconfig -nographics
* libvirt then runs a number of QMP commands to find out
what it needs to know. I'd expect the following existing
commands would be used
- query-version - already supported
- query-commands- already supported
- query-events - already supported
- query-kvm - already supported
- qom-{list,list-types,get} - already supported
- query-spice/vnc - already supported
And add the following new commands
- query-devices - new, -device ?, and/or -device NAME,? data
in QMP
- query-machines- new, -M ? in QMP
- query-cpu-types - new, -cpu ? in QMP
The above would take care of probably 50% of the current libvirt
capabilities probing, including a portion of the -help stuff. Then
there is all the rest of the crap we detect from the -help. We could
just take the view, that "as of 1.2", we assume everything we previously
detected is just available by default, and thus don't need to probe
it. For stuff that is QOM based, I expect we'll be able to detect new
features in the future using the qom-XXX monitor commands. For stuff
that is non-qdev, and non-qom, libvirt can just do a plain version
number check, unless we decide there is specific info worth exposing
via other new 'query-XXX' monitor commands.
The one thing to note is that I didn't add a query-devices command because you
can already do:
qmp query-devices --implements=device --abstract=False
To get the equivalent output of -device ?. Instead, I added a command to list
specific properties of a device which is the equivalent of -device FOO,?
---
v1 -> v2
- rename query-cpudefs -> query-cpu-definitions
[Qemu-devel] [PATCH 0/2] cpu: make a child of DeviceState
This is just a rebase of this series that I posted back in June. Andreas had a different approach involving a #define but I think doing a full split ends up being nicer. For instance, the recently added thread information is only relevant to cpu-softmmu so we can limit that entirely to cpu-softmmu.
[Qemu-devel] [PATCH 1/2] qdev: split up header so it can be used in cpu.h
Header file dependency is a frickin' nightmare right now. cpu.h tends to get
included in our 'include everything' header files but qdev also needs to include
those headers mainly for qdev-properties since it knows about CharDriverState
and friends.
We can solve this for now by splitting out qdev.h along the same lines that we
previously split the C file. Then cpu.h just needs to include qdev-core.h
Signed-off-by: Anthony Liguori
Signed-off-by: Anthony Liguori
---
hw/irq.h |2 +
hw/mc146818rtc.c |1 +
hw/qdev-addr.c |1 +
hw/qdev-core.h | 240
hw/qdev-monitor.h| 16 ++
hw/qdev-properties.c |1 +
hw/qdev-properties.h | 128 +
hw/qdev.c|1 +
hw/qdev.h| 371 +-
9 files changed, 394 insertions(+), 367 deletions(-)
create mode 100644 hw/qdev-core.h
create mode 100644 hw/qdev-monitor.h
create mode 100644 hw/qdev-properties.h
diff --git a/hw/irq.h b/hw/irq.h
index 56c55f0..1339a3a 100644
--- a/hw/irq.h
+++ b/hw/irq.h
@@ -3,6 +3,8 @@
/* Generic IRQ/GPIO pin infrastructure. */
+typedef struct IRQState *qemu_irq;
+
typedef void (*qemu_irq_handler)(void *opaque, int n, int level);
void qemu_set_irq(qemu_irq irq, int level);
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 3777f85..3780617 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -25,6 +25,7 @@
#include "qemu-timer.h"
#include "sysemu.h"
#include "mc146818rtc.h"
+#include "qapi/qapi-visit-core.h"
#ifdef TARGET_I386
#include "apic.h"
diff --git a/hw/qdev-addr.c b/hw/qdev-addr.c
index b711b6b..5b5d38f 100644
--- a/hw/qdev-addr.c
+++ b/hw/qdev-addr.c
@@ -1,6 +1,7 @@
#include "qdev.h"
#include "qdev-addr.h"
#include "targphys.h"
+#include "qapi/qapi-visit-core.h"
/* --- target physical address --- */
diff --git a/hw/qdev-core.h b/hw/qdev-core.h
new file mode 100644
index 000..ca205fc
--- /dev/null
+++ b/hw/qdev-core.h
@@ -0,0 +1,240 @@
+#ifndef QDEV_CORE_H
+#define QDEV_CORE_H
+
+#include "qemu-queue.h"
+#include "qemu-option.h"
+#include "qemu/object.h"
+#include "hw/irq.h"
+#include "error.h"
+
+typedef struct Property Property;
+
+typedef struct PropertyInfo PropertyInfo;
+
+typedef struct CompatProperty CompatProperty;
+
+typedef struct BusState BusState;
+
+typedef struct BusClass BusClass;
+
+enum DevState {
+DEV_STATE_CREATED = 1,
+DEV_STATE_INITIALIZED,
+};
+
+enum {
+DEV_NVECTORS_UNSPECIFIED = -1,
+};
+
+#define TYPE_DEVICE "device"
+#define DEVICE(obj) OBJECT_CHECK(DeviceState, (obj), TYPE_DEVICE)
+#define DEVICE_CLASS(klass) OBJECT_CLASS_CHECK(DeviceClass, (klass),
TYPE_DEVICE)
+#define DEVICE_GET_CLASS(obj) OBJECT_GET_CLASS(DeviceClass, (obj), TYPE_DEVICE)
+
+typedef int (*qdev_initfn)(DeviceState *dev);
+typedef int (*qdev_event)(DeviceState *dev);
+typedef void (*qdev_resetfn)(DeviceState *dev);
+
+struct VMStateDescription;
+
+typedef struct DeviceClass {
+ObjectClass parent_class;
+
+const char *fw_name;
+const char *desc;
+Property *props;
+int no_user;
+
+/* callbacks */
+void (*reset)(DeviceState *dev);
+
+/* device state */
+const struct VMStateDescription *vmsd;
+
+/* Private to qdev / bus. */
+qdev_initfn init;
+qdev_event unplug;
+qdev_event exit;
+const char *bus_type;
+} DeviceClass;
+
+/* This structure should not be accessed directly. We declare it here
+ so that it can be embedded in individual device state structures. */
+struct DeviceState {
+Object parent_obj;
+
+const char *id;
+enum DevState state;
+struct QemuOpts *opts;
+int hotplugged;
+BusState *parent_bus;
+int num_gpio_out;
+qemu_irq *gpio_out;
+int num_gpio_in;
+qemu_irq *gpio_in;
+QLIST_HEAD(, BusState) child_bus;
+int num_child_bus;
+int instance_id_alias;
+int alias_required_for_version;
+};
+
+/*
+ * This callback is used to create Open Firmware device path in accordance with
+ * OF spec http://forthworks.com/standards/of1275.pdf. Indicidual bus bindings
+ * can be found here http://playground.sun.com/1275/bindings/.
+ */
+
+#define TYPE_BUS "bus"
+#define BUS(obj) OBJECT_CHECK(BusState, (obj), TYPE_BUS)
+#define BUS_CLASS(klass) OBJECT_CLASS_CHECK(BusClass, (klass), TYPE_BUS)
+#define BUS_GET_CLASS(obj) OBJECT_GET_CLASS(BusClass, (obj), TYPE_BUS)
+
+struct BusClass {
+ObjectClass parent_class;
+
+/* FIXME first arg should be BusState */
+void (*print_dev)(Monitor *mon, DeviceState *dev, int indent);
+char *(*get_dev_path)(DeviceState *dev);
+char *(*get_fw_dev_path)(DeviceState *dev);
+int (*reset)(BusState *bus);
+};
+
+typedef struct BusChild {
+DeviceState *child;
+int index;
+QTAILQ_ENTRY(BusChild) sibl
[Qemu-devel] [PATCH 2/2] cpu: for cpu-user and cpu-softmmu and make cpu-softmmu a child of DeviceState
The line between linux-user and softmmu is not very well defined right now. linux-user really don't want to include devices and making CpuState a child of DeviceState would require pulling lots of stuff into linux-user. To solve this, we simply fork cpu-user and cpu-softmmu letting them evolve independently. We also need to push a qdev_init_nofail() into all callers of cpu_init(). This is needed eventually anyway so might as well do this now. Signed-off-by: Anthony Liguori --- Makefile.objs |6 --- hw/armv7m.c |1 + hw/axis_dev88.c |1 + hw/exynos4210.c |1 + hw/highbank.c |1 + hw/integratorcp.c |1 + hw/leon3.c|1 + hw/lm32_boards.c |2 + hw/milkymist.c|1 + hw/mips_fulong2e.c|1 + hw/mips_jazz.c|1 + hw/mips_malta.c |1 + hw/mips_mipssim.c |1 + hw/mips_r4k.c |1 + hw/musicpal.c |1 + hw/omap1.c|1 + hw/omap2.c|1 + hw/pc.c |1 + hw/petalogix_ml605_mmu.c |1 + hw/petalogix_s3adsp1800_mmu.c |1 + hw/ppc440_bamboo.c|1 + hw/ppc4xx_devs.c |1 + hw/ppc_newworld.c |1 + hw/ppc_oldworld.c |1 + hw/ppc_prep.c |1 + hw/ppce500_mpc8544ds.c|1 + hw/pxa2xx.c |1 + hw/r2d.c |1 + hw/realview.c |1 + hw/s390-virtio.c |1 + hw/spapr.c|1 + hw/strongarm.c|1 + hw/sun4m.c|1 + hw/sun4u.c|1 + hw/versatilepb.c |1 + hw/vexpress.c |2 + hw/virtex_ml507.c |1 + hw/xen_machine_pv.c |1 + hw/xilinx_zynq.c |1 + hw/xtensa_lx60.c |1 + hw/xtensa_sim.c |1 + include/qemu/cpu-softmmu.h| 82 +++ include/qemu/cpu-user.h | 75 include/qemu/cpu.h| 85 ++--- qemu-common.h |3 +- qom/Makefile.objs |5 +- qom/cpu-softmmu.c | 66 +++ qom/cpu-user.c| 70 + 48 files changed, 343 insertions(+), 91 deletions(-) create mode 100644 include/qemu/cpu-softmmu.h create mode 100644 include/qemu/cpu-user.h create mode 100644 qom/cpu-softmmu.c create mode 100644 qom/cpu-user.c diff --git a/Makefile.objs b/Makefile.objs index 5ebbcfa..f285926 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -12,12 +12,6 @@ qobject-obj-y += qerror.o error.o qemu-error.o universal-obj-y += $(qobject-obj-y) ### -# QOM -qom-obj-y = qom/ - -universal-obj-y += $(qom-obj-y) - -### # oslib-obj-y is code depending on the OS (win32 vs posix) oslib-obj-y = osdep.o oslib-obj-$(CONFIG_WIN32) += oslib-win32.o qemu-thread-win32.o diff --git a/hw/armv7m.c b/hw/armv7m.c index 8cec78d..2e8fa06 100644 --- a/hw/armv7m.c +++ b/hw/armv7m.c @@ -188,6 +188,7 @@ qemu_irq *armv7m_init(MemoryRegion *address_space_mem, fprintf(stderr, "Unable to find CPU definition\n"); exit(1); } +qdev_init_nofail(DEVICE(cpu)); env = &cpu->env; #if 0 diff --git a/hw/axis_dev88.c b/hw/axis_dev88.c index eab6327..f34fe8a 100644 --- a/hw/axis_dev88.c +++ b/hw/axis_dev88.c @@ -265,6 +265,7 @@ void axisdev88_init (ram_addr_t ram_size, cpu_model = "crisv32"; } cpu = cpu_cris_init(cpu_model); +qdev_init_nofail(DEVICE(cpu)); env = &cpu->env; /* allocate RAM */ diff --git a/hw/exynos4210.c b/hw/exynos4210.c index 00d4db8..aca8738 100644 --- a/hw/exynos4210.c +++ b/hw/exynos4210.c @@ -122,6 +122,7 @@ Exynos4210State *exynos4210_init(MemoryRegion *system_mem, fprintf(stderr, "Unable to find CPU %d definition\n", n); exit(1); } +qdev_init_nofail(DEVICE(s->cpu[n])); /* Create PIC controller for each processor instance */ irqp = arm_pic_init_cpu(s->cpu[n]); diff --git a/hw/highbank.c b/hw/highbank.c index 11aa131..8f66f70 100644 --- a/hw/highbank.c +++ b/hw/highbank.c @@ -214,6 +214,7 @@ static void highbank_init(ram_addr_t ram_size, fprintf(stderr, "Unable to find CPU definition\n"); exit(1); } +qdev_init_nofail(DEVICE(cpu)); /* This will become a QOM property eventually */ cpu->reset_cbar = GIC
Re: [Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpudefs
Eduardo Habkost writes: > On Fri, Aug 10, 2012 at 11:37:30AM -0500, Anthony Liguori wrote: >> Eduardo Habkost writes: >> >> > - add machine-type-specific cpudef compatibility changes? >> >> >> >> I think we've discussed this in IRC. I don't think we need to worry >> >> about this. >> > >> > I remember discussing a lot about the mechanism we will use to add the >> > compatibility changes, but I don t know how the query API will look >> > like, after we implement this mechanism. >> >> 0) User-defined CPU definitions go away >>- We already made a big step in this direction >> >> 1) CPU becomes a DeviceState > > 1.1) CPU models become classes > >> >> 2) Features are expressed as properties >> >> 3) Same global mechanism used for everything else is used for CPUs > > This is basically the compatibility mechanism we agreed upon, yes, but > what about the probing mechanism to allow libvirt to know what will be > the result of "-machine M -cpu C"[1] before actually starting a VM? I think that the requirement of "before actually starting a VM" is unreasonable. Presumably migration compatibility checking would happen after launching a guest so libvirt could surely delay querying the CPUID info until after the guest has started. There's a lot of logic involved in deciding what gets exposed to the guest. We don't really fully know until we've created the VCPU. It's a whole lot easier and saner to just create the VCPU. Regards, Anthony Liguori > > [1] By "result" I mean: >- Whether that combination can be run properly on that host; >- Which CPU features will be visible to the guest in case it runs. >Both items depend on CPU model _and_ machine-type, that's why we need >some probing mechanism that depends on the machine-type or use the >machine-type as input. > > >> >> Regards, >> >> Anthony Liguori >> >> >> > Would the command report different results depending on -machine? >> >> >> >> No. >> > >> > The problem is: >> > >> > 1) We need to introduce fixes on a CPU model that changes the set of >> >guest-visible features (add or remove a feature)[1]; >> > 2) The fix has to keep compatibility, so older machine-types will >> >keep exposing the old set of gues-visible features; >> >- That means different machine-types will have different CPU >> > features being exposed. >> > 3) libvirt needs to control/know which guest-visible CPU features are >> >available to the guest (see above); >> > 4) Because of (2), the querying system used by libvirt need to depend on >> >the CPU model and machine-type. >> > >> > >> > [1] Example: >> > The SandyBridge model today has the "tsc-deadline" bit set, but >> > QEMU-1.1 did not expose the tsc-deadline feature properly because of >> > incorrect expectations about the GET_SUPPORTED_CPUID ioctl. This was >> > fixed on qemu-1.2. >> > >> > That means "qemu-1.1 -machine pc-1.1 -cpu SandyBridge" does _not_ >> > expose tsc-deadline to the guest, and we need to make "qemu-1.2 >> > -machine pc-1.1 -cpu SandyBridge" _not_ expose it, too (otherwise >> > migration from qemu-1.1 to qemu-1.2 will be broken). >> > >> >> >> >> > >> >> > Would the command return the latest cpudef without any machine-type >> >> > hacks, and libvirt would have to query for the cpudef compatibility data >> >> > for each machine-type and combine both pieces of information itself? >> >> >> >> I'm not sure what you mean by compatibility data. >> > >> > I mean any guest-visible compatibility bit that we will need to >> > introduce on older machine-types, when making changes on CPU models (see >> > the SandyBridge + tsc-deadline example above). >> > >> > I see two options: >> > - Libvirt queries for a [f(machine_type, cpu_model) -> cpu_features] >> > function, that will take into account the machine-type-specific >> > compatibility bits. >> > - Libvirt queries for a [f(cpu_model) -> cpu_features] function and a >> > [f(machine_type) -> compatibility_changes] function, and combine both. >> > - I don't like this approach, I am just including it as a possible >> > alternative. >> > >> >> >> >> Regards, >> >> >> >> Anthony Liguori >> >> >> >> > >> >> > [1] Note that it doesn't have to be low-level leaf-by-leaf >> >> > register-by-register CPUID bits (I prefer a more high-level >> >> > interface, myself), but it has to at least say "feature FOO is >> >> > enabled/disabled" for a set of features libvirt cares about. >> >> > >> >> > -- >> >> > Eduardo >> >> >> > >> > -- >> > Eduardo >> > > -- > Eduardo
[Qemu-devel] [PATCH 6/7] target-i386: add implementation of query-cpu-definitions (v2)
Signed-off-by: Anthony Liguori
---
v1 -> v2
- rename query-cpudefs -> query-cpu-definitions
---
target-i386/cpu.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 880cfea..6d5d0d6 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -28,6 +28,7 @@
#include "qemu-config.h"
#include "qapi/qapi-visit-core.h"
+#include "qmp-commands.h"
#include "hyperv.h"
@@ -1125,6 +1126,27 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf,
const char *optarg)
}
}
+CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+{
+CpuDefinitionInfoList *cpu_list = NULL;
+x86_def_t *def;
+
+for (def = x86_defs; def; def = def->next) {
+CpuDefinitionInfoList *entry;
+CpuDefinitionInfo *info;
+
+info = g_malloc0(sizeof(*info));
+info->name = g_strdup(def->name);
+
+entry = g_malloc0(sizeof(*entry));
+entry->value = info;
+entry->next = cpu_list;
+cpu_list = entry;
+}
+
+return cpu_list;
+}
+
int cpu_x86_register(X86CPU *cpu, const char *cpu_model)
{
CPUX86State *env = &cpu->env;
--
1.7.5.4
Re: [Qemu-devel] [PATCH 2/7] qapi: mark QOM commands stable
Eric Blake writes: > On 08/10/2012 10:04 AM, Anthony Liguori wrote: >> We've had a cycle to tweak. It is time to commit to supporting them. >> >> Signed-off-by: Anthony Liguori >> --- >> qapi-schema.json | 19 --- >> 1 files changed, 4 insertions(+), 15 deletions(-) >> >> diff --git a/qapi-schema.json b/qapi-schema.json >> index 191a889..a938c8d 100644 >> --- a/qapi-schema.json >> +++ b/qapi-schema.json >> @@ -1363,9 +1363,7 @@ >> #4) A link type in the form 'link' where subtype is a qdev >> # device type name. Link properties form the device model graph. >> # >> -# Since: 1.1 >> -# >> -# Notes: This type is experimental. Its syntax may change in future >> releases. >> +# Since: 1.2 > > Per https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg01416.html, > this should be 1.2.0 (throughout the series). I'll do a follow up to fix this across the board for the entire file. That's what I took away from your previous comment. Regards, Anthony Liguori > >> @@ -1382,10 +1380,7 @@ >> # Returns: a list of @ObjectPropertyInfo that describe the properties of the >> # object. >> # >> -# Since: 1.1 >> -# >> -# Notes: This command is experimental. It's syntax may change in future > > Yay, getting rid of bad grammar in the process (s/It's/Its/ if the > comment were to remain). > > -- > Eric Blake ebl...@redhat.com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [PATCH 2/2] cpu: for cpu-user and cpu-softmmu and make cpu-softmmu a child of DeviceState
Eduardo Habkost writes:
> On Fri, Aug 10, 2012 at 12:00:44PM -0500, Anthony Liguori wrote:
>> The line between linux-user and softmmu is not very well defined right now.
>> linux-user really don't want to include devices and making CpuState a child
>> of
>> DeviceState would require pulling lots of stuff into linux-user.
>>
>> To solve this, we simply fork cpu-user and cpu-softmmu letting them evolve
>> independently.
>>
>> We also need to push a qdev_init_nofail() into all callers of cpu_init().
>> This
>> is needed eventually anyway so might as well do this now.
>>
>> Signed-off-by: Anthony Liguori
>> ---
> [...]
>> --- /dev/null
>> +++ b/qom/cpu-user.c
> [...]
>> +static TypeInfo cpu_type_info = {
>> +.name = TYPE_CPU,
>> +#ifdef CONFIG_USER_ONLY
>> +.parent = TYPE_OBJECT,
>> +#else
>> +.parent = TYPE_DEVICE,
>> +#endif
>
> Is this #ifdef supposed to be here?
Nope. Thanks.
Regards,
Anthony Liguori
>
>> +.instance_size = sizeof(CPUState),
>> +.abstract = true,
>> +.class_size = sizeof(CPUClass),
>> +.class_init = cpu_class_init,
>> +};
>> +
>> +static void cpu_register_types(void)
>> +{
>> +type_register_static(&cpu_type_info);
>> +}
>> +
>> +type_init(cpu_register_types)
>> --
>> 1.7.5.4
>>
>
> --
> Eduardo
Re: [Qemu-devel] github mirror still stale
Peter Maydell writes: > On 18 July 2012 10:28, Peter Maydell wrote: >> On 12 March 2012 20:12, Stefan Weil wrote: >>> We also need more resources for technical maintenance of the >>> QEMU infrastructure. For example, the official mirror of the >>> QEMU git repository (https://github.com/qemu/QEMU) is several >>> months behind, http://git.savannah.gnu.org/cgit/qemu.git is >>> even older. >> >> The github mirror is still wildly out of date -- can we >> get the link to it removed from http://wiki.qemu.org/Download >> please? (I'd do it myself but the page is 'locked'.) > > Ping^2. It would be good to stop advertising stale git mirrors > before we make the 1.2 release... I messed up setting it up and had to delete the whole thing and start over. We now have a proper organization on github and which let me setup a mirror from qemu.org that pushes every 30 minutes to github. It should be active now. I can also add other people to the github organization. Regards, Anthony Liguori > > -- PMM
Re: [Qemu-devel] [PULL 0/7] last SCSI changes for 1.2
Paolo Bonzini writes: > Anthony, > > The following changes since commit 0b8db8fe15d17a529a5ea90614c11e9f031dfee8: > > slirp: fix build on mingw32 (2012-08-06 19:31:55 -0500) > > are available in the git repository at: > > git://github.com/bonzini/qemu.git scsi-next > > for you to fetch changes up to 5222aaf223e52961cabeb7cabc579892ccd8bc59: > > scsi-disk: add support for the UNMAP command (2012-08-09 15:04:09 +0200) Pulled. Thanks. Regards, Anthony Liguori > > > Paolo Bonzini (6): > iscsi: do not leak initiator_name > iscsi: reorganize code for parse_initiator_name > virtio-scsi: do not compare 32-bit QEMU tags against 64-bit virtio-scsi > tags > scsi-disk: more assertions and resets for aiocb > scsi-disk: improve out-of-range LBA detection for WRITE SAME > scsi-disk: add support for the UNMAP command > > Ronnie Sahlberg (1): > iscsi: Pick default initiator-name based on the name of the VM > > block/iscsi.c| 59 ++--- > hw/scsi-disk.c | 112 > ++- > hw/virtio-scsi.c | 10 - > qemu-common.h| 1 + > qemu-doc.texi| 5 +++ > qemu-options.hx | 8 > qemu-tool.c | 5 +++ > vl.c | 5 +++ > 8 file modificati, 163 inserzioni(+), 42 rimozioni(-) > -- > 1.7.11.2
Re: [Qemu-devel] [PULL 00/11] Block patches
Kevin Wolf writes: > The following changes since commit 3d1d9652978ac5a32a0beb4bdf6065ca39440d89: > > handle device help before accelerator set up (2012-08-09 19:53:01 +) > > are available in the git repository at: > http://repo.or.cz/r/qemu/kevin.git for-anthony Pulled. Thanks. Regards, Anthony Liguori > > Avi Kivity (1): > virtio-blk: fix use-after-free while handling scsi commands > > Jason Baron (2): > ahci: Fix ahci cdrom read corruptions for reads > 128k > ahci: Fix sglist memleak in ahci_dma_rw_buf() > > Kevin Wolf (1): > qemu-iotests: Save some sed processes > > Paolo Bonzini (3): > virtio-blk: support VIRTIO_BLK_F_CONFIG_WCE > virtio-blk: disable write cache if not negotiated > blockdev: flip default cache mode from writethrough to writeback > > Stefan Hajnoczi (4): > qed: mark image clean after repair succeeds > qcow2: mark image clean after repair succeeds > block: add BLOCK_O_CHECK for qemu-img check > qemu-iotests: skip 039 with ./check -nocache > > block.h |1 + > block/qcow2.c| 32 -- > block/qed-check.c| 26 > block/qed.c | 11 + > block/qed.h |5 > blockdev.c |1 + > dma-helpers.c|1 + > hw/ide/ahci.c| 44 +++-- > hw/ide/internal.h|1 + > hw/virtio-blk.c | 31 +++- > hw/virtio-blk.h |4 ++- > qemu-img.c |2 +- > tests/qemu-iotests/039 |1 + > tests/qemu-iotests/039.out |6 + > tests/qemu-iotests/common.rc | 34 ++- > 15 files changed, 155 insertions(+), 45 deletions(-)
Re: [Qemu-devel] [PULL 0/3] Trivial patches for 3 to 10 August 2012
Stefan Hajnoczi writes: > The following changes since commit 3d1d9652978ac5a32a0beb4bdf6065ca39440d89: > > handle device help before accelerator set up (2012-08-09 19:53:01 +) > > are available in the git repository at: > > git://github.com/stefanha/qemu.git trivial-patches > > for you to fetch changes up to b90372ad2a69a9cdad2a40766eb46f0a89d98535: > > target-arm: Fix typos in comments (2012-08-10 14:37:28 +0100) Pulled. Thanks. Regards, Anthony Liguori > > > Dunrong Huang (1): > vl.c: Exit QEMU early if no machine is found > > Peter A. G. Crosthwaite (1): > arm: translate: comment typo - s/middel/middle/ > > Peter Maydell (1): > target-arm: Fix typos in comments > > target-arm/arm-semi.c|2 +- > target-arm/cpu.h |2 +- > target-arm/helper.c |6 +++--- > target-arm/neon_helper.c | 26 +- > target-arm/op_helper.c |2 +- > target-arm/translate.c | 12 ++-- > vl.c | 10 +- > 7 files changed, 30 insertions(+), 30 deletions(-) > > -- > 1.7.10.4
Re: [Qemu-devel] [PATCH 05/11] virtio-blk: support VIRTIO_BLK_F_CONFIG_WCE
Kevin Wolf writes:
> From: Paolo Bonzini
>
> Also rename VIRTIO_BLK_F_WCACHE to VIRTIO_BLK_F_WCE for consistency with
> the spec.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Kevin Wolf
This broke qemu-test because it changed the pc-1.0 machine type:
Setting guest RANDOM seed to 47167
*** Running tests ***
Running test /tests/finger-print.sh... OK
--- fingerprints/pc-1.0.x86_64 2011-12-18 13:08:40.0 -0600
+++ fingerprint.txt 2012-08-12 13:30:48.0 -0500
@@ -55,7 +55,7 @@
/sys/bus/pci/devices/:00:06.0/subsystem_device=0x0002
/sys/bus/pci/devices/:00:06.0/class=0x01
/sys/bus/pci/devices/:00:06.0/revision=0x00
-/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x710006d4
+/sys/bus/pci/devices/:00:06.0/virtio/host-features=0x71000ed4
/sys/class/dmi/id/bios_vendor=Bochs
/sys/class/dmi/id/bios_date=01/01/2007
/sys/class/dmi/id/bios_version=Bochs
Guest fingerprint changed for pc-1.0!
Need to make this a qdev-visible feature and then add compatibility
properties for all of the old machine types.
Regards,
Anthony Liguori
> ---
> hw/virtio-blk.c | 16 ++--
> hw/virtio-blk.h |4 +++-
> 2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
> index 552b3b6..97bb4bd 100644
> --- a/hw/virtio-blk.c
> +++ b/hw/virtio-blk.c
> @@ -510,9 +510,19 @@ static void virtio_blk_update_config(VirtIODevice *vdev,
> uint8_t *config)
> blkcfg.size_max = 0;
> blkcfg.physical_block_exp = get_physical_block_exp(s->conf);
> blkcfg.alignment_offset = 0;
> +blkcfg.wce = bdrv_enable_write_cache(s->bs);
> memcpy(config, &blkcfg, sizeof(struct virtio_blk_config));
> }
>
> +static void virtio_blk_set_config(VirtIODevice *vdev, const uint8_t *config)
> +{
> +VirtIOBlock *s = to_virtio_blk(vdev);
> +struct virtio_blk_config blkcfg;
> +
> +memcpy(&blkcfg, config, sizeof(blkcfg));
> +bdrv_set_enable_write_cache(s->bs, blkcfg.wce != 0);
> +}
> +
> static uint32_t virtio_blk_get_features(VirtIODevice *vdev, uint32_t
> features)
> {
> VirtIOBlock *s = to_virtio_blk(vdev);
> @@ -523,9 +533,10 @@ static uint32_t virtio_blk_get_features(VirtIODevice
> *vdev, uint32_t features)
> features |= (1 << VIRTIO_BLK_F_BLK_SIZE);
> features |= (1 << VIRTIO_BLK_F_SCSI);
>
> +features |= (1 << VIRTIO_BLK_F_CONFIG_WCE);
> if (bdrv_enable_write_cache(s->bs))
> -features |= (1 << VIRTIO_BLK_F_WCACHE);
> -
> +features |= (1 << VIRTIO_BLK_F_WCE);
> +
> if (bdrv_is_read_only(s->bs))
> features |= 1 << VIRTIO_BLK_F_RO;
>
> @@ -610,6 +621,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev,
> VirtIOBlkConf *blk)
>sizeof(VirtIOBlock));
>
> s->vdev.get_config = virtio_blk_update_config;
> +s->vdev.set_config = virtio_blk_set_config;
> s->vdev.get_features = virtio_blk_get_features;
> s->vdev.reset = virtio_blk_reset;
> s->bs = blk->conf.bs;
> diff --git a/hw/virtio-blk.h b/hw/virtio-blk.h
> index 79ebccc..35834cf 100644
> --- a/hw/virtio-blk.h
> +++ b/hw/virtio-blk.h
> @@ -31,8 +31,9 @@
> #define VIRTIO_BLK_F_BLK_SIZE 6 /* Block size of disk is available*/
> #define VIRTIO_BLK_F_SCSI 7 /* Supports scsi command passthru */
> /* #define VIRTIO_BLK_F_IDENTIFY 8 ATA IDENTIFY supported,
> DEPRECATED */
> -#define VIRTIO_BLK_F_WCACHE 9 /* write cache enabled */
> +#define VIRTIO_BLK_F_WCE9 /* write cache enabled */
> #define VIRTIO_BLK_F_TOPOLOGY 10 /* Topology information is available
> */
> +#define VIRTIO_BLK_F_CONFIG_WCE 11 /* write cache configurable */
>
> #define VIRTIO_BLK_ID_BYTES 20 /* ID string length */
>
> @@ -49,6 +50,7 @@ struct virtio_blk_config
> uint8_t alignment_offset;
> uint16_t min_io_size;
> uint32_t opt_io_size;
> +uint8_t wce;
> } QEMU_PACKED;
>
> /* These two define direction. */
> --
> 1.7.6.5
Re: [Qemu-devel] [PATCH for-1.2 v5 14/14] pci: Tidy up PCI host bridges
break;
>
> case GT_PCI0_CMD:
> diff --git a/hw/piix_pci.c b/hw/piix_pci.c
> index 04ceccf..537fc19 100644
> --- a/hw/piix_pci.c
> +++ b/hw/piix_pci.c
> @@ -36,7 +36,9 @@
> * http://download.intel.com/design/chipsets/datashts/29054901.pdf
> */
>
> -typedef PCIHostState I440FXState;
> +typedef struct I440FXState {
> +PCIHostState parent_obj;
> +} I440FXState;
>
> #define PIIX_NUM_PIC_IRQS 16 /* i8259 * 2 */
> #define PIIX_NUM_PIRQS 4ULL/* PIRQ[A-D] */
> @@ -274,7 +276,7 @@ static PCIBus *i440fx_common_init(const char *device_name,
> dev = qdev_create(NULL, "i440FX-pcihost");
> s = PCI_HOST_BRIDGE(dev);
> s->address_space = address_space_mem;
> -b = pci_bus_new(&s->busdev.qdev, NULL, pci_address_space,
> +b = pci_bus_new(dev, NULL, pci_address_space,
> address_space_io, 0);
> s->bus = b;
> object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev),
> NULL);
> diff --git a/hw/ppc4xx_pci.c b/hw/ppc4xx_pci.c
> index 5583321..a14fd42 100644
> --- a/hw/ppc4xx_pci.c
> +++ b/hw/ppc4xx_pci.c
> @@ -52,7 +52,7 @@ struct PCITargetMap {
> #define PPC4xx_PCI_NR_PTMS 2
>
> struct PPC4xxPCIState {
> -PCIHostState pci_state;
> +PCIHostState parent_obj;
>
> struct PCIMasterMap pmm[PPC4xx_PCI_NR_PMMS];
> struct PCITargetMap ptm[PPC4xx_PCI_NR_PTMS];
> @@ -96,16 +96,18 @@ static uint64_t pci4xx_cfgaddr_read(void *opaque,
> target_phys_addr_t addr,
> unsigned size)
> {
> PPC4xxPCIState *ppc4xx_pci = opaque;
> +PCIHostState *phb = PCI_HOST_BRIDGE(ppc4xx_pci);
>
> -return ppc4xx_pci->pci_state.config_reg;
> +return phb->config_reg;
> }
>
> static void pci4xx_cfgaddr_write(void *opaque, target_phys_addr_t addr,
>uint64_t value, unsigned size)
> {
> PPC4xxPCIState *ppc4xx_pci = opaque;
> +PCIHostState *phb = PCI_HOST_BRIDGE(ppc4xx_pci);
>
> -ppc4xx_pci->pci_state.config_reg = value & ~0x3;
> +phb->config_reg = value & ~0x3;
> }
>
> static const MemoryRegionOps pci4xx_cfgaddr_ops = {
> diff --git a/hw/ppce500_pci.c b/hw/ppce500_pci.c
> index 967..92b1dc0 100644
> --- a/hw/ppce500_pci.c
> +++ b/hw/ppce500_pci.c
> @@ -78,7 +78,7 @@ struct pci_inbound {
> OBJECT_CHECK(PPCE500PCIState, (obj), TYPE_PPC_E500_PCI_HOST_BRIDGE)
>
> struct PPCE500PCIState {
> -PCIHostState pci_state;
> +PCIHostState parent_obj;
>
> struct pci_outbound pob[PPCE500_PCI_NR_POBS];
> struct pci_inbound pib[PPCE500_PCI_NR_PIBS];
> diff --git a/hw/prep_pci.c b/hw/prep_pci.c
> index 35cb9b2..cc44e61 100644
> --- a/hw/prep_pci.c
> +++ b/hw/prep_pci.c
> @@ -34,7 +34,7 @@
> OBJECT_CHECK(PREPPCIState, (obj), TYPE_RAVEN_PCI_HOST_BRIDGE)
>
> typedef struct PRePPCIState {
> -PCIHostState host_state;
> +PCIHostState parent_obj;
>
> MemoryRegion intack;
> qemu_irq irq[4];
> @@ -60,14 +60,16 @@ static void ppc_pci_io_write(void *opaque,
> target_phys_addr_t addr,
> uint64_t val, unsigned int size)
> {
> PREPPCIState *s = opaque;
> -pci_data_write(s->host_state.bus, PPC_PCIIO_config(addr), val, size);
> +PCIHostState *phb = PCI_HOST_BRIDGE(s);
> +pci_data_write(phb->bus, PPC_PCIIO_config(addr), val, size);
> }
>
> static uint64_t ppc_pci_io_read(void *opaque, target_phys_addr_t addr,
> unsigned int size)
> {
> PREPPCIState *s = opaque;
> -return pci_data_read(s->host_state.bus, PPC_PCIIO_config(addr), size);
> +PCIHostState *phb = PCI_HOST_BRIDGE(s);
> +return pci_data_read(phb->bus, PPC_PCIIO_config(addr), size);
> }
>
> static const MemoryRegionOps PPC_PCIIO_ops = {
> diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
> index df70cd2..8937030 100644
> --- a/hw/spapr_pci.c
> +++ b/hw/spapr_pci.c
> @@ -36,16 +36,18 @@ static PCIDevice *find_dev(sPAPREnvironment *spapr,
> uint64_t buid, uint32_t config_addr)
> {
> int devfn = (config_addr >> 8) & 0xFF;
> -sPAPRPHBState *phb;
> +sPAPRPHBState *sphb;
>
> - QLIST_FOREACH(phb, &spapr->phbs, list) {
> +QLIST_FOREACH(sphb, &spapr->phbs, list) {
> +PCIHostState *phb;
> BusChild *kid;
>
> -if (phb->buid != buid) {
> +if (sphb->buid != buid) {
> continue;
> }
>
> -QTAILQ_FOREACH(kid, &phb->host_state.bus->qbus.children, sibling)
Re: [Qemu-devel] [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1.2
Alex Williamson writes: > VFIO kernel support was just merged into Linux, so I'd like to > formally propose inclusion of the QEMU vfio-pci driver for > QEMU 1.2. Included here is support for x86 PCI device assignment. > PCI INTx is not yet enabled, but devices making use of either MSI > or MSI-X work. The level irqfd and eoifd support I've proposed > for KVM enable an accelerated patch for this through KVM. I'd > like to get this base driver in first and enable the remaining > support in-tree. > > I've split this version up a little from the RFC to make it a bit > easier to review. Review comments from Blue Swirl and Avi are > already incorporated, including Avi's requests to simplify both > the PCI BAR mapping and unmapping paths. Hi Alex, Thanks for pushing this forward! Hopefully this will finally kill off qemu-kvm.git for good. I think this series is going to have to wait for 1.3 to open up. We have a very short release window for this release and I'd feel a lot more comfortable having such a significant feature spend some time in the development cycle getting testing/review. I'd like to see a few Reviewed-by's too for this series before it goes in. I expect they won't be hard to get but I also expect it will take a few more revisions of this series to get there. Regards, Anthony Liguori > > This series is also available at: > > git://github.com/awilliam/qemu-vfio.git tags/vfio-pci-for-qemu-1.2 > > Thanks, > > Alex > > --- > > Alex Williamson (3): > vfio: Enable vfio-pci and mark supported > vfio: vfio-pci device assignment driver > vfio: Import vfio kernel header > > > MAINTAINERS|5 > configure | 12 > hw/i386/Makefile.objs |1 > hw/vfio_pci.c | 1853 > > hw/vfio_pci.h | 101 ++ > linux-headers/linux/vfio.h | 368 + > 6 files changed, 2340 insertions(+) > create mode 100644 hw/vfio_pci.c > create mode 100644 hw/vfio_pci.h > create mode 100644 linux-headers/linux/vfio.h > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 4/7] compiler: add macro for GCC weak symbols
Peter Maydell writes: > On 10 August 2012 17:04, Anthony Liguori wrote: >> This lets us provide a default implementation of a symbol which targets can >> override. >> >> Signed-off-by: Anthony Liguori > > I'm sure you'll be thrilled to hear that this doesn't seem to break MacOS > builds :-) Thank you for testing it. I neglected to mention that I did a fair bit of investigation before hand and was able to confirm that all platforms we care about (Windows, Linux/Unix, OS X) and all compilers we care about (GCC, LLVM) support weak symbols. There may be different attribute names across compilers--it wasn't very clear to me, but they definitely all have the feature in some form. Regards, Anthony Liguori > > -- PMM
Re: [Qemu-devel] [PATCH for-1.2 v5 14/14] pci: Tidy up PCI host bridges
"Michael S. Tsirkin" writes: > On Thu, Aug 02, 2012 at 03:47:06AM +0200, Andreas Färber wrote: >> Uglify the parent field to enforce QOM-style access via casts. >> Don't just typedef PCIHostState, either use it directly or embed it. >> >> Signed-off-by: Andreas Färber > > > IMHO only one chunk from this patch should be applied (below). > Below it is split out but needs to be rebased on top of patches > 1-13. I understand what your objection is but it's unreasonable IMHO. The purpose of QOM is to bring consistency across large swaths of code in QEMU that have historically done things there own way. This means expressing concepts like inheritence and casting in the same way across the board. The common way (the QOM way) is to make the parent type the first member of the struct (typically named parent or parent_obj) and then to use cast macros to upcast and downcast. This patch is 100% correct in that regard and I'm going to apply it once Andreas makes the change I requested. For my part, I'm long over due in writing up a device authoring style guide that I promised a few weeks ago. I'll write that up this afternoon and send it out today. We can debate the merits of this sort of thing in the style guide. Regards, Anthony Liguori > > --> > > From: Andreas Färber > > piix: minor code simplification > > There's no need to deal with qdev internals in piix - we get device > state from qdev_create so just use that. > > Signed-off-by: Andreas Färber > Signed-off-by: Michael S. Tsirkin > > --- > > diff --git a/hw/piix_pci.c b/hw/piix_pci.c > index c497a01..18554a6 100644 > --- a/hw/piix_pci.c > +++ b/hw/piix_pci.c > @@ -274,7 +274,7 @@ static PCIBus *i440fx_common_init(const char *device_name, > dev = qdev_create(NULL, "i440FX-pcihost"); > s = FROM_SYSBUS(I440FXState, sysbus_from_qdev(dev)); > s->address_space = address_space_mem; > -b = pci_bus_new(&s->busdev.qdev, NULL, pci_address_space, > +b = pci_bus_new(&dev, NULL, pci_address_space, > address_space_io, 0); > s->bus = b; > object_property_add_child(qdev_get_machine(), "i440fx", OBJECT(dev), > NULL);
Re: [Qemu-devel] Funny -m arguments can crash
Markus Armbruster writes: > Avi Kivity writes: > >> On 08/08/2012 12:04 PM, Markus Armbruster wrote: >>>> >>>> Yes please, maybe with a notice to the user. >>> >>> Next problem: minimum RAM size. >>> >>> For instance, -M pc -m X, where X < 32KiB dies "qemu: fatal: Trying to >>> execute code outside RAM or ROM at [...] Aborted (core dumped)" with >>> TCG, and "KVM internal error. Suberror: 1" with KVM. >>> >>> Should a minimum RAM size be enforced? Board-specific? >>> >> >> It's really a BIOS bug causing a limitation of both kvm and tcg to be >> hit. The BIOS should recognize it doesn't have sufficient memory and >> hang gracefully (if you can picture that). It just assumes some low >> memory is available and tries to execute it with the results you got. > > SeaBIOS indeed assumes it got at least 1MiB of RAM. It doesn't bother > to check CMOS for a smaller RAM size. However, that bug / feature is > currently masked by a QEMU bug: we screw up CMOS contents when there's > less than 1 MiB of RAM. pc_cmos_init(): > > int val, nb, i; > [...] > /* memory size */ > val = 640; /* base memory in K */ > rtc_set_memory(s, 0x15, val); > rtc_set_memory(s, 0x16, val >> 8); > > val = (ram_size / 1024) - 1024; > if (val > 65535) > val = 65535; > rtc_set_memory(s, 0x17, val); > rtc_set_memory(s, 0x18, val >> 8); > > If ram_size < 1MiB, val goes negative. Oops. > > For instance, with -m 500k, we happily promise 640KiB base memory (CMOS > addr 0x15..16), almost 64MiB extended memory (0x17..18 and 0x30..31), > yet no memory above 16MiB (0x34..35). > > An easy way to fix this is to require 1MiB of RAM :) > > But if you like, I'll put sane values in CMOS instead. That'll expose > the SeaBIOS bug. > > Anthony, you're the PC maintainer, got a preference? > > SeaBIOS thread: > http://comments.gmane.org/gmane.comp.bios.coreboot.seabios/4341 I'd prefer fixing the CMOS values over limiting to 1MB of RAM. Having a 1MB limit is purely theoritical--not practical. There's no good reason for anyone to ask for < 1MB unless they know what they're doing. If it's truly a mistake, then asking for 2MB is just as much of a mistake because no real guest will run with 2MB of memory anyway (you can't even load a kernel). So if we're just going for theoritical correctness, we ought to do it the Right Way which is fixing the CMOS values and putting the check in SeaBIOS. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] update-linux-headers.sh: Pull in asm-generic/kvm_para.h
Peter Maydell writes: > Ping^2 ? In a previous thread, we all agreed that all changes to linux headers would come in through uq/master to ensure that we didn't have a repeat scenario of depending on a header that didn't make it to Avi's tree unchanged. Avi/Marcelo, can you guys pick this up through uq/master? Regards, Anthony Liguori > > On 8 August 2012 13:34, Peter Maydell wrote: >> Ping? >> >> patchwork url: http://patchwork.ozlabs.org/patch/173202/ >> >> -- PMM >> >> On 25 July 2012 16:29, Peter Maydell wrote: >>> Add asm-generic/kvm_para.h to the set of non-architecture specific >>> KVM kernel headers we copy into QEMU. This header may be included >>> by an architecture's kvm_para.h header. >>> >>> Signed-off-by: Peter Maydell >>> --- >>> scripts/update-linux-headers.sh |5 + >>> 1 files changed, 5 insertions(+), 0 deletions(-) >>> >>> diff --git a/scripts/update-linux-headers.sh >>> b/scripts/update-linux-headers.sh >>> index 9d2a4bc..a639c5b 100755 >>> --- a/scripts/update-linux-headers.sh >>> +++ b/scripts/update-linux-headers.sh >>> @@ -46,6 +46,11 @@ mkdir -p "$output/linux-headers/linux" >>> for header in kvm.h kvm_para.h vhost.h virtio_config.h virtio_ring.h; do >>> cp "$tmpdir/include/linux/$header" "$output/linux-headers/linux" >>> done >>> +rm -rf "$output/linux-headers/asm-generic" >>> +mkdir -p "$output/linux-headers/asm-generic" >>> +for header in kvm_para.h; do >>> +cp "$tmpdir/include/asm-generic/$header" >>> "$output/linux-headers/asm-generic" >>> +done >>> if [ -L "$linux/source" ]; then >>> cp "$linux/source/COPYING" "$output/linux-headers" >>> else >>> -- >>> 1.7.5.4
[Qemu-devel] [PATCH] qom: add style guide
Signed-off-by: Anthony Liguori
---
docs/qom-style-guide.md | 489 +++
1 files changed, 489 insertions(+), 0 deletions(-)
create mode 100644 docs/qom-style-guide.md
diff --git a/docs/qom-style-guide.md b/docs/qom-style-guide.md
new file mode 100644
index 000..e7590e0
--- /dev/null
+++ b/docs/qom-style-guide.md
@@ -0,0 +1,489 @@
+QEMU Object Model Style Guide
+=
+
+Overview
+
+This document is a step-by-step tutorial of QOM. It is meant to be read from
+top to bottom addressing the most common use-cases at the start. This is a
+living document and contributions are welcome but it should not attempt to be
+an API reference. There code contains inline documentation and API details
+should be covered in the respective header files.
+
+Motivation
+--
+QEMU makes extensive use of object oriented programming. Since QEMU is written
+in C, these OOP concepts often use very different mechanisms to achieve the
+same goal. The net effect is a lot of infrastructure duplication and a general
+lack of consistency.
+
+The goal of QOM is to use a single infrastructure for all OOP within QEMU.
This
+improves consistency and eases maintainability over the long term.
+
+QOM provides a common infrastructure for:
+
+- Type Management
+ - Registering types
+ - Enumerating registered types
+- Inheritence
+ - Single-parent inheritance
+ - Introspection of inheritance hierarchy
+ - Multiple inheritance through stateless interfaces
+- Polymorphism
+ - Class based polymorphism
+ - Virtual and pure virtual methods
+ - Constructor/destructor chaining
+- Object Properties
+ - Dynamic property registration (tied to Objects)
+ - Property introspection
+ - Access permissions
+ - Accessor hooks
+- Type Casting
+ - Runtime checked upcast/downcast
+ - Full support for casting up and down the chain (including interfaces)
+- Object Enumeration
+ - Expression of relationship between objects
+ - Ability to reference objects with a symbolic path
+ - Represented as a directed graph
+
+While QOM has a lot of high level concepts, the primary design goal has been to
+keep simple concepts simple to implement.
+
+A Note on Consistency
+-
+Much of the QOM types in QEMU have been converted through automated scripts.
+Tremendous effort was made to make sure the resulting code was high quality and
+adhered to all of the guidelines in this document. However, there are many
+cases where some of the conversion could not be scripted easily and some short
+cuts where taken.
+
+Whenever possible, as code is refactored for other reasons, it should be
brought
+up fully to the guidelines expressed in this document.
+
+Creating a Simple Type
+--
+The easiest way to understand QOM is to walk through an example. This is a
+typical example of creating a new type derived from Object as the parent class.
+In this example, all code would live in a single C source file.
+
+Let's get started:
+
+#include "qemu/object.h"
+
+This is the header file that contains the core QOM infrastructure. It has
+minimum dependencies to facilitate unit testing.
+
+#define TYPE_MY_TYPE "my-type"
+#define MY_TYPE(obj) OBJECT_CHECK(MyType, (obj), TYPE_MY_TYPE)
+
+All QOM types should define at least two macros. The first macro is a symbolic
+version of the type name. It should always take the form
+TYPE_ + upper(typename). Type names should generally follow the naming rules
of
+QAPI which means dashes, '-', are preferred to underscores, '_'.
+
+The second macro is a cast macro. The first argument is the type struct and
the
+remaining arguments are self-evident. This form should always be followed even
+if the cast macro isn't currently used by the C file.
+
+typedef struct MyType MyType;
+
+struct MyType
+{
+Object parent_obj;
+
+/*< private >*/
+int foo;
+};
+
+When declaring the structure, a forward declaration should be used. This is
+useful for consistency sake as it is required when defining classes.
+
+The first element must be the parent type and should be named 'parent_obj' or
+just 'parent'. When working with QOM types, you should avoid ever accessing
+this member directly instead relying on casting macros.
+
+Casting macros hide the inheritence hierarchy from the implementation. This
+makes it easier to refactor code over time by changing the hierarchy without
+changing the code in many places.
+
+static TypeInfo my_type_info = {
+.name = TYPE_MY_TYPE,
+.parent = TYPE_OBJECT,
+.instance_size = sizeof(MyType),
+};
+
+static void register_types(void)
+{
+type_register_static(&my_type_info);
+}
+
+type_init(register_types);
+
+All QOM types must be registered with the QOM infrastructure. Once registered,
Re: [Qemu-devel] [PATCH v6 0/3] Sandboxing Qemu guests with Libseccomp
Overall the code looks fine to me. A couple general comments though: - we need a -disable-sandbox flag in case the whitelist is bad and a user needs to disable it. - for the few cases where we may exec something that requires privileges beyond this white list, we need to clearly document that -disable-sandbox may be needed. Most scripts should be fairly limited in what they try to do so I think that the existing sandbox should be okay. Confirming that the existing sandbox is enough to do ifconfig $tap 0.0.0.0 up && brctl addbr br0 $tap would be nice too. I'm a little concerned this hasn't gotten enough testing to enable by default in 1.2. So I'd suggest adding: -sandbox on Parse this argument via QemuOpts and make the default parameter 'enable'. This will let us extend the white list in the future. For the 1.2 release, make the default for sandbox.enable=off but for 1.3, will switch it to 'on' for the default. By making it QemuOpts, we can actually disable/enable through the global configuration file which is a really nice touch. If you can make those changes and resubmit tomorrow, we can include it for the 1.2 release. Regards, Anthony Liguori Eduardo Otubo writes: > Hello all, > > This patch is an effort to sandbox Qemu guests using Libseccomp[0]. The > patches > that follows are pretty simple and straightforward. I added the correct > options > and checks to the configure script and the basic calls to libseccomp in the > main loop at vl.c. Details of each one are in the emails of the patch set. > > This support limits the system call footprint of the entire QEMU process to a > limited set of syscalls, those that we know QEMU uses. The idea is to limit > the > allowable syscalls, therefore limiting the impact that an attacked guest could > have on the host system. > > It's important to note that the libseccomp itself needs the seccomp mode 2 > feature in the kernel, which is only available in kernel versions older (or > equal) than 3.5-rc1. > > v2: Files separated in qemu-seccomp.c and qemu-seccomp.h for a cleaner > implementation. The development was tested with the 3.5-rc1 kernel. > > v3: As we discussed in previous emails in this mailing list, this feature is > not supposed to replace existing security feature, but add another layer > to > the whole. The whitelist should contain all the syscalls QEMU needs. And > as > stated by Will Drewry's commit message[1]: "Filter programs will be > inherited > across fork/clone and execve.", the same white list should be passed > along from > the father process to the child, then execve() shouldn't be a problem. > Note > that there's a feature PR_SET_NO_NEW_PRIVS in seccomp mode 2 in the > kernel, > this prevents processes from gaining privileges on execve. For example, > this > will prevent qemu (if running unprivileged) from executing setuid > programs[2]. > > v4: Introducing "debug" mode on libseccomp support. The "debug" mode will set > the flag SCMP_ACT_TRAP when calling seccomp_start(). It will verbosely > print a message to the stderr in the form "seccomp: illegal system call > execution trapped: XXX" and resume the execution. This is really just > used as > debug mode, it helps users and developers to full fill the whitelist. > > v5: Libseccomp release 1.0.0[3]: The API now is context aware and it breaks > the > compatibility with older versions. I updated all the functions that > differs > from one version to another. > > v6: Debug mode removed as discussed in the list/irc. Planned for future > inclusion. > > As always, comments are more than welcome. > > Regards, > > [0] - http://sourceforge.net/projects/libseccomp/ > [1] - > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=e2cfabdfd075648216f99c2c03821cf3f47c1727 > [2] - https://lkml.org/lkml/2012/4/12/457 > [3] - > http://sourceforge.net/mailarchive/forum.php?thread_name=1633205.5jr3eG7nQ5%40sifl&forum_name=libseccomp-discuss > > > Eduardo Otubo (3): > Adding support for libseccomp in configure and Makefile > Adding qemu-seccomp.[ch] > Adding seccomp calls to vl.c > > Makefile.objs |6 ++ > configure | 22 + > qemu-seccomp.c | 139 > > qemu-seccomp.h | 22 + > vl.c | 13 + > 5 files changed, 202 insertions(+), 0 deletions(-) > create mode 100644 qemu-seccomp.c > create mode 100644 qemu-seccomp.h
Re: [Qemu-devel] [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1.2
Jan Kiszka writes: > On 2012-08-13 15:58, Avi Kivity wrote: >> On 08/13/2012 04:27 PM, Anthony Liguori wrote: >> >>> Thanks for pushing this forward! Hopefully this will finally kill off >>> qemu-kvm.git for good. >> >> No, it won't. vfio requires a 3.6 kernel, which we cannot assume anyone >> has. We'll need the original device assignment code side-by-side. > > ...which is on my to-do list for 1.3. Is there a deprecation plan for the old device assignment code? I'm not really against the idea of requiring a new kernel for new features. >From a Fedora/OpenSUSE point of view, would supporting old kernels be a requirement to stop shipping qemu-kvm.git over qemu.git? Since distros ship new kernels and new userspaces, I don't think distros would care so I'm not sure who we're trying to support old kernels for. Regards, Anthony Liguori > > Jan > > -- > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE > Corporate Competence Center Embedded Linux > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/3] VFIO-based PCI device assignment for QEMU 1.2
Alex Williamson writes: > On Mon, 2012-08-13 at 08:27 -0500, Anthony Liguori wrote: >> Alex Williamson writes: >> >> > VFIO kernel support was just merged into Linux, so I'd like to >> > formally propose inclusion of the QEMU vfio-pci driver for >> > QEMU 1.2. Included here is support for x86 PCI device assignment. >> > PCI INTx is not yet enabled, but devices making use of either MSI >> > or MSI-X work. The level irqfd and eoifd support I've proposed >> > for KVM enable an accelerated patch for this through KVM. I'd >> > like to get this base driver in first and enable the remaining >> > support in-tree. >> > >> > I've split this version up a little from the RFC to make it a bit >> > easier to review. Review comments from Blue Swirl and Avi are >> > already incorporated, including Avi's requests to simplify both >> > the PCI BAR mapping and unmapping paths. >> >> Hi Alex, >> >> Thanks for pushing this forward! Hopefully this will finally kill off >> qemu-kvm.git for good. >> >> I think this series is going to have to wait for 1.3 to open up. We >> have a very short release window for this release and I'd feel a lot >> more comfortable having such a significant feature spend some time in >> the development cycle getting testing/review. >> >> I'd like to see a few Reviewed-by's too for this series before it goes >> in. I expect they won't be hard to get but I also expect it will take a >> few more revisions of this series to get there. > > That's disappointing, but I can understand your reluctance. Blue Swirl > reviewed the RFC and could perhaps add a Reviewed-by. Alexey has been > working on the POWER port and I'm sure could provide a Reviewed-by. We > also have a few early adopters that are already making use of this code. > Towards accepting it, the driver is entirely self contained, there's > really no risk to the rest of qemu. The only missing functionality is > legacy interrupt support. Perhaps there's a compromise where this > driver could be considered a tech preview in 1.2 (x-vfio-pci?). > Thanks, Yeah, if a few people were willing to at least give an Acked-by by Wednesday, I'd be okay taking this in a "preview" or something like that. I wouldn't bother renaming it or anything like that. We can just declare in the release notes that it's an experimental feature and may eat your lunch while you're not looking. Regards, Anthony Liguori > > Alex > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/7] qapi: add commands to remove the need (v2)
Luiz Capitulino writes: > On Mon, 13 Aug 2012 14:16:58 -0300 > Luiz Capitulino wrote: > >> On Fri, 10 Aug 2012 11:04:08 -0500 >> Anthony Liguori wrote: >> >> > This series implements the necessary commands to implements danpb's idea to >> > remove -help parsing in libvirt. We would introduce all of these commands >> > in >> > 1.2 and then change the -help output starting in 1.3. >> >> Applied to the qmp branch, thanks. > > Hmm, this series broke ppc-softmmu for me: Curious, I'll look into that. Thanks Regards, Anthony Liguori > > In file included from > /home/lcapitulino/work/src/qmp-unstable/target-ppc/translate_init.c:30:0, > from > /home/lcapitulino/work/src/qmp-unstable/target-ppc/translate.c:9404: > ../qmp-commands.h:23:1: error: unknown type name ‘QDict’ > ../qmp-commands.h:23:68: error: unknown type name ‘QObject’ > > But it's not its fault. The problem here is probably a patch in my error > series that is doing header cleanup and qmp-commands.h was probably relying > on qapi-types.h (or some of its include files) including qdict.h. > > I'm going to include the following patch in my pull request: > > Subject: [PATCH 36/48] scripts: qapi-commands.py: qmp-commands.h: include > qdict.h > > qmp-commands.h declares several functions that have arguments of > type QDict. However, qdict.h is not included. This will cause a > build breakage when a file includes qmp-commands.h but doesn't > include qdict.h. > > Signed-off-by: Luiz Capitulino > --- > scripts/qapi-commands.py | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py > index 9eed40e..3c4678d 100644 > --- a/scripts/qapi-commands.py > +++ b/scripts/qapi-commands.py > @@ -342,6 +342,7 @@ def gen_command_decl_prologue(header, guard, prefix=""): > #define %(guard)s > > #include "%(prefix)sqapi-types.h" > +#include "qdict.h" > #include "error.h" > > ''', > -- > 1.7.11.2.249.g31c7954.dirty
Re: [Qemu-devel] [PATCH] qom: add style guide
"Michael S. Tsirkin" writes:
> On Mon, Aug 13, 2012 at 01:46:46PM -0500, Anthony Liguori wrote:
>> +typedef struct MyType MyType;
>> +
>> +struct MyType
>> +{
>
> This seems to violate our style:should be
>
>> +struct MyType {
That's a bug in CODING_STYLE. Coding style only talks explicitly about
if but ought to make an exception for type declarations too. If you
grep a bit, you'll see both styles are wildly used.
>> +Object parent_obj;
>> +
>> +/*< private >*/
>> +int foo;
>> +};
>> +
>> +When declaring the structure, a forward declaration should be used. This is
>> +useful for consistency sake as it is required when defining classes.
>> +
>> +The first element must be the parent type and should be named 'parent_obj'
>> or
>> +just 'parent'.
>
> Why should it? Why not use a descriptive name that
> makes it easier to see what the object actually is?
Parent is a descriptive name. That's all it is--the parent. It is not
'bus' or 'bridge' or anything else you want to call it. It's the parent
object.
If you want to interact with the object as the parent, you should cast.
>> When working with QOM types, you should avoid ever accessing
>> +this member directly instead relying on casting macros.
>> +
>> +Casting macros hide the inheritence hierarchy from the implementation. This
>> +makes it easier to refactor code over time by changing the hierarchy without
>> +changing the code in many places.
>
> This seems like a weak motivation. Why do you expect to refactor
> hierarchy all the time? The cost is replacing compile time checks with
> runtime ones.
Unless you have a case where runtime checks have a measurable cost associated
with them, an appeal to performance is not valid.
It simply boils down to readability.
struct PCIDevice
{
DeviceState qdev; // what do we call this?
};
struct E1000
{
PCIDevice pci_dev;
};
E1000 *s = ...;
device_reset(&s->pci_dev->qdev);
Is not at all descriptive. It's also hard to review for when people
introduce types like this. And it's not clear why you can only have one
PCIDevice member. Why isn't:
struct E1000
{
PCIDevice pci_dev0;
PCIDevice pci_dev1;
};
Not valid? It's not obvious to a casual observer. Using a name other
than 'parent' just allows people to have the wrong mental model. It is
not a has-a relationship. s->pci_dev leads a reader to think of things
in terms of a has-a relationship. It's an is-a relationship.
> So refactoring is easier to make but harder to make correct.
> Sounds like a bad tradeoff.
99% of the work in introducing QOM was cleaning up direct references to
members by wrapping them in functions.
It's pretty darn hard to misuse cast macros. I don't buy that they are
any less correct in practice. Casting is done usually at the top of a
function and is unconditional. Even the most basic testing should cover
100% of casts.
Regards,
Anthony Liguori
>
> --
> MST
Re: [Qemu-devel] [PULL] kvm updates
Avi Kivity writes: > Please pull from: > > git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. Regards, Anthony Liguori > > This is mostly Peter's kvm_irqchip_in_kernel() decoupling work. > > > Dunrong Huang (1): > kvm: Check if smp_cpus exceeds max cpus supported by kvm > > Peter Maydell (8): > configure: Don't implicitly hardcode list of KVM architectures > kvm: Decouple 'async interrupt delivery' from 'kernel irqchip' > kvm: Rename kvm_irqchip_set_irq() to kvm_set_irq() > kvm: Move kvm_allows_irq0_override() to target-i386, fix return type > kvm: Decouple 'irqfds usable' from 'kernel irqchip' > kvm: Decouple 'MSI routing via irqfds' from 'kernel irqchip' > kvm: Decouple 'GSI routing' from 'kernel irqchip' > kvm: Add documentation comment for kvm_irqchip_in_kernel() > > configure | 14 +++--- > cpus.c| 3 ++- > hw/kvm/i8259.c| 2 +- > hw/kvm/ioapic.c | 2 +- > hw/pc.c | 1 + > hw/virtio-pci.c | 4 ++-- > kvm-all.c | 54 > +++--- > kvm-stub.c| 9 - > kvm.h | 60 > +--- > target-i386/Makefile.objs | 1 + > target-i386/kvm-stub.c| 18 ++ > target-i386/kvm.c | 13 + > target-i386/kvm_i386.h| 16 > 13 files changed, 170 insertions(+), 27 deletions(-) > create mode 100644 target-i386/kvm-stub.c > create mode 100644 target-i386/kvm_i386.h > > -- > error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH 3/3] vfio: Enable vfio-pci and mark supported
Jan Kiszka writes: > On 2012-08-01 07:18, Alex Williamson wrote: >> Signed-off-by: Alex Williamson >> --- >> >> MAINTAINERS |5 + >> configure | 12 >> hw/i386/Makefile.objs |1 + >> 3 files changed, 18 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 2d219d2..9680d69 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -460,6 +460,11 @@ M: Gerd Hoffmann >> S: Maintained >> F: hw/usb* >> >> +VFIO >> +M: Alex Williamson >> +S: Supported >> +F: hw/vfio* >> + >> vhost >> M: Michael S. Tsirkin >> S: Supported >> diff --git a/configure b/configure >> index c65b5f6..81108dc 100755 >> --- a/configure >> +++ b/configure >> @@ -143,6 +143,7 @@ attr="" >> libattr="" >> xfs="" >> >> +vfio_pci="no" >> vhost_net="no" >> kvm="no" >> gprof="no" >> @@ -489,6 +490,7 @@ Haiku) >>usb="linux" >>kvm="yes" >>vhost_net="yes" >> + vfio_pci="yes" >>if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then >> audio_possible_drivers="$audio_possible_drivers fmod" >>fi >> @@ -824,6 +826,10 @@ for opt do >>;; >>--disable-guest-agent) guest_agent="no" >>;; >> + --disable-vfio-pci) vfio_pci="no" >> + ;; >> + --enable-vfio-pci) vfio_pci="yes" >> + ;; > > Do we need this level of control? Open question I'm just wondering every > time a new feature gets added together with --disable/--enable > switches. I don't think so--it's easy enough for an administrator to disable vfio for a user. Regards, Anthony Liguori > >>*) echo "ERROR: unknown option $opt"; show_help="yes" >>;; >>esac >> @@ -1112,6 +1118,8 @@ echo " --disable-guest-agentdisable building of >> the QEMU Guest Agent" >> echo " --enable-guest-agent enable building of the QEMU Guest Agent" >> echo " --with-coroutine=BACKEND coroutine backend. Supported options:" >> echo " gthread, ucontext, sigaltstack, windows" >> +echo " --disable-vfio-pci disable vfio pci device assignement >> support" >> +echo " --enable-vfio-pcienable vfio pci device assignment support" >> echo "" >> echo "NOTE: The object files are built at the place where configure is >> launched" >> exit 1 >> @@ -3072,6 +3080,7 @@ echo "OpenGL support$opengl" >> echo "libiscsi support $libiscsi" >> echo "build guest agent $guest_agent" >> echo "coroutine backend $coroutine_backend" >> +echo "VFIO PCI support $vfio_pci" >> >> if test "$sdl_too_old" = "yes"; then >> echo "-> Your SDL version is too old - please upgrade to have SDL support" >> @@ -3754,6 +3763,9 @@ case "$target_arch2" in >>*) >> echo "CONFIG_NO_XEN=y" >> $config_target_mak >> esac >> +if test "$vfio_pci" = "yes" -a "$target_softmmu" = "yes" ; then >> + echo "CONFIG_VFIO_PCI=y" >> $config_target_mak >> +fi > > Does this already somehow depend on host == Linux? If not, you may break > the others. > >> case "$target_arch2" in >>i386|x86_64|ppcemb|ppc|ppc64|s390x) >> # Make sure the target and host cpus are compatible >> diff --git a/hw/i386/Makefile.objs b/hw/i386/Makefile.objs >> index 8c764bb..a2783ef 100644 >> --- a/hw/i386/Makefile.objs >> +++ b/hw/i386/Makefile.objs >> @@ -11,5 +11,6 @@ obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o >> obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o >> xen_pt_msi.o >> obj-y += kvm/ >> obj-$(CONFIG_SPICE) += qxl.o qxl-logger.o qxl-render.o >> +obj-$(CONFIG_VFIO_PCI) += vfio_pci.o >> >> obj-y := $(addprefix ../,$(obj-y)) >> > > Jan
Re: [Qemu-devel] [PULL 00/48]: QMP queue
Luiz Capitulino writes: > Contains my new error format series, a few fixes related to the WAKEUP event, > a new event and the new commands to avoid -help output parsing. > > The changes (since 33e95c6328a3149a52615176617997c4f8f7088b) are available > in the following repository: > > git://repo.or.cz/qemu/qmp-unstable.git queue/qmp > Pulled. Thanks. Regards, Anthony Liguori > Anthony Liguori (7): > qmp: introduce device-list-properties command > qapi: mark QOM commands stable > qapi: add query-machines command > compiler: add macro for GCC weak symbols > qapi: add query-cpu-definitions command (v2) > target-i386: add implementation of query-cpu-definitions (v2) > target-ppc: add implementation of query-cpu-definitions (v2) > > Luiz Capitulino (41): > monitor: drop unused monitor debug code > qerror: QERR_AMBIGUOUS_PATH: drop %(object) from human msg > qerror: QERR_DEVICE_ENCRYPTED: change error message > qerror: reduce public exposure > qerror: drop qerror_abort() > qerror: avoid passing qerr pointer > qerror: QError: drop file, linenr, func > qerror: qerror_format(): return an allocated string > qerror: don't delay error message construction > error: don't delay error message construction > qmp: query-block: add 'encryption_key_missing' field > hmp: hmp_cont(): don't rely on QERR_DEVICE_ENCRYPTED > hmp_change(): don't access DeviceEncrypted's data > net: inet_connect(), inet_connect_opts(): add in_progress argument > migration: don't rely on any QERR_SOCKET_* > qerror: drop QERR_SOCKET_CONNECT_IN_PROGRESS > block: block_int: include qerror.h > hmp: hmp.h: include qdict.h > qapi: qapi-types.h: don't include qapi/qapi-types-core.h > qapi: generate correct enum names for camel case enums > qapi: don't convert enum strings to lowercase > qapi-schema: add ErrorClass enum > qerror: qerror_table: don't use C99 struct initializers > error, qerror: add ErrorClass argument to error functions > qerror: add proper ErrorClass value for QERR_ macros > error: add error_get_class() > hmp: hmp_change(): use error_get_class() > error: drop unused functions > qmp: switch to the new error format on the wire > qemu-ga: switch to the new error format on the wire > error: drop error_get_qobject()/error_set_qobject() > error, qerror: pass desc string to error calls > qerror: drop qerror_table and qerror_format() > error, qerror: drop QDict member > docs: writing-qmp-commands.txt: update error section > scripts: qapi-commands.py: qmp-commands.h: include qdict.h > qmp: don't emit the RESET event on wakeup from S3 > qmp: emit the WAKEUP event when the guest is put to run > qmp: qmp-events.txt: put events in alphabetical order > qmp: qmp-events.txt: add missing doc for the SUSPEND event > qmp: add SUSPEND_DISK event > > Makefile.objs | 1 + > QMP/qmp-events.txt| 291 +--- > QMP/qmp-spec.txt | 10 +- > block.c | 1 + > block_int.h | 1 + > compiler.h| 1 + > configure | 10 - > docs/writing-qmp-commands.txt | 47 ++-- > error.c | 93 +--- > error.h | 34 +-- > error_int.h | 29 --- > hmp.c | 69 ++ > hmp.h | 1 + > hw/acpi.c | 2 + > migration-tcp.c | 22 +- > monitor.c | 84 ++- > monitor.h | 1 + > nbd.c | 2 +- > qapi-schema.json | 192 ++-- > qapi/qmp-core.h | 1 + > qapi/qmp-dispatch.c | 11 +- > qemu-char.c | 2 +- > qemu-ga.c | 5 +- > qemu-sockets.c| 14 +- > qemu_socket.h | 4 +- > qerror.c | 516 > ++ > qerror.h | 168 ++ > qmp-commands.hx | 23 +- > qmp.c | 56 + > scripts/qapi-commands.py | 1 + > scripts/qapi-types.py | 17 +- > target-i386/cpu.c | 22 ++ > target-ppc/translate_init.c | 26 +++ > ui/vnc.c | 2 +- > vl.c | 49 +++- > 35 files changed, 689 insertions(+), 1119 deletions(-)
Re: [Qemu-devel] [PULL] Migration next 20120808
Juan Quintela writes: > [Resent with PULL request instead of PATCH, sorry for the inconvenience] > > Hi > > This includes xbzrle series (v12) That were reviewed by Erik and Luiz. > > Anthony, please apply. Pulled. Thanks. Regards, Anthony Liguori > > Later, Juan. > > The following changes since commit c03b0aa0ca93480e92dc356e58538df0835fe621: > > Merge remote-tracking branch 'kraxel/usb.58' into staging (2012-08-07 > 09:46:40 -0500) > > are available in the git repository at: > > > http://repo.or.cz/r/qemu/quintela.git migration-next-20120808 > > for you to fetch changes up to dd051c7217eae04191169ac62f6ffb7531c8da32: > > Restart optimization on stage3 update version (2012-08-08 13:51:12 +0200) > > > Juan Quintela (1): > Restart optimization on stage3 update version > > Orit Wasserman (11): > Add migration capabilities > Add migrate-set-capabilities > Add XBZRLE documentation > Add cache handling functions > Add uleb encoding/decoding functions > Add xbzrle_encode_buffer and xbzrle_decode_buffer functions > Add XBZRLE to ram_save_block and ram_save_live > Add migrate_set_cache_size command > Change total_time to total-time in MigrationStats > Add migration accounting for normal and duplicate pages > Add XBZRLE statistics > > Makefile.objs | 1 + > arch_init.c | 246 > +- > cutils.c | 42 > docs/xbzrle.txt | 128 > hmp-commands.hx | 38 +++ > hmp.c | 103 +++ > hmp.h | 4 + > include/qemu/page_cache.h | 79 +++ > migration.c | 112 + > migration.h | 21 > monitor.c | 14 +++ > page_cache.c | 218 > qapi-schema.json | 119 +- > qemu-common.h | 21 > qmp-commands.hx | 159 +- > savevm.c | 159 ++ > 16 files changed, 1451 insertions(+), 13 deletions(-) > create mode 100644 docs/xbzrle.txt > create mode 100644 include/qemu/page_cache.h > create mode 100644 page_cache.c > > -- > 1.7.11.2
Re: [Qemu-devel] [PULL for-1.2 00/10] arm-devs queue
Peter Maydell writes: > This is the usual arm-devs pullreq, with the last set of patches > to go in before the 1.2 hardfreeze. Nothing particularly exciting > here, mostly just cleanup, plus a fix for that embarrassing > "v7m machines assert on startup" bug of mine. > > thanks > -- PMM > Pulled. Thanks. Regards, Anthony Liguori > The following changes since commit 33e95c6328a3149a52615176617997c4f8f7088b: > > qom: Reimplement Interfaces (2012-08-13 11:20:41 +0200) > > are available in the git repository at: > > git://git.linaro.org/people/pmaydell/qemu-arm.git arm-devs.next > > for you to fetch changes up to 58f9b98f8a341c8b7bb0c9b38e492a01fe71d666: > > arm: Move some ARM devices into libhw (2012-08-13 16:13:02 +0100) > > > Andreas Färber (1): > arm: Move some ARM devices into libhw > > Mitsyanko Igor (6): > hw/sd.c: convert wp_groups in SDState to bitfield > hw/sd.c: make sd_wp_addr() accept 64 bit address argument > hw/sd.c: introduce wrapper for conversion address to wp group > hw/sd.c: convert binary variables to bool > hw/sd.c: make sd_dataready() return bool > hw/sd.c: make sd_wp_addr() return bool > > Peter A. G. Crosthwaite (2): > armv7m: Guard against no -kernel argument > ssd0323: abort() instead of exit(1) on error. > > Peter Maydell (1): > hw/armv7m_nvic: Fix incorrect default for num-irqs property > > default-configs/arm-softmmu.mak | 18 ++ > hw/Makefile.objs| 20 +++ > hw/arm/Makefile.objs| 15 ++-- > hw/armv7m.c |5 +++ > hw/armv7m_nvic.c| 21 > hw/sd.c | 72 > +-- > hw/sd.h |6 ++-- > hw/ssd0323.c|4 ++- > 8 files changed, 104 insertions(+), 57 deletions(-)
Re: [Qemu-devel] [RFC v0] HACK: qom: object_property_set: abort on failure
"Peter A. G. Crosthwaite" writes:
> Hi All. A couple of times now ive had debug issues due to silent failure of
> object_property_set. This function silently fails if the requested property
> does not exist for the target object. To trap this error I applied the patch
> below to my tree, but I am assuming that this is not mergeable as is as im
> guessing there are clients out there that are speculatively trying to set
> props.
>
> Could someone confirm the expected policy here? is setting a non-existant
> property supposed to be a no-op (as it currently is) or should it fail
> gracefully?
Are you calling set via object_property_set_[str,int,bool,...]?
Why don't you add a terminal error to those functions if setting fails and errp
is NULL.
Regards,
Anthony Liguori
>
> Whats the best meachinism for creating a no_fail version of
> object_property_set,
> for the 90% case where a non-existant property is an error in machine model
> development?
>
> Signed-off-by: Peter A. G. Crosthwaite
> ---
> qom/object.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/qom/object.c b/qom/object.c
> index a552be2..6e875a8 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -687,7 +687,7 @@ void object_property_set(Object *obj, Visitor *v, const
> char *name,
> {
> ObjectProperty *prop = object_property_find(obj, name, errp);
> if (prop == NULL) {
> -return;
> +abort();
> }
>
> if (!prop->set) {
> --
> 1.7.0.4
[Qemu-devel] [PATCH] block-migration: deprecate block migration for the 1.2 release
To be replaced with live block copy.
Signed-off-by: Anthony Liguori
---
migration.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/migration.c b/migration.c
index 653a3c1..babccf4 100644
--- a/migration.c
+++ b/migration.c
@@ -482,10 +482,19 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
MigrationParams params;
const char *p;
int ret;
+static bool suppress_deprecation_message;
params.blk = blk;
params.shared = inc;
+if (blk && !suppress_deprecation_message) {
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ "Block migration is deprecated. "
+ "See http://wiki.qemu.org/Features/LiveBlockCopy "
+ "for an alternative syntax.");
+suppress_deprecation_message = true;
+}
+
if (s->state == MIG_STATE_ACTIVE) {
error_set(errp, QERR_MIGRATION_ACTIVE);
return;
--
1.7.5.4
Re: [Qemu-devel] [PULL 0/6 1.2] Tracing patches for QEMU 1.2
Stefan Hajnoczi writes: > The last pull request from 19 July was not merged. Here it is rebased on > qemu.git/master with two additional fixes from Stefan Weil. I'm not sure what you mean: commit 903f650b0c77827f8d92b35f61419401d648df1e Merge: 61dc008 90a147a Author: Anthony Liguori Date: Mon Jul 23 13:15:34 2012 -0500 Merge remote-tracking branch 'stefanha/tracing' into staging * stefanha/tracing: Update simpletrace.py for new log format Simpletrace v2: Support multiple arguments, strings. monitor: remove unused do_info_trace trace: added ability to comment out events in the list Your pull request was for 90a147a275da3a432bdf00238ebf438eff1d2c1b which is what is being merged here. What your pull request inaccurate? Regards, Anthony Liguori > > The following changes since commit 633decd71119a4293e5e53e6059026c517a8bef0: > > Merge remote-tracking branch 'qmp/queue/qmp' into staging (2012-08-13 > 16:12:35 -0500) > > are available in the git repository at: > > > git://github.com/stefanha/qemu.git tracing > > for you to fetch changes up to 4552e41025af4694c55854448c3ae4d95e72c7f6: > > trace/simple: Replace asprintf by g_strdup_printf (2012-08-14 13:19:57 > +0100) > > > Harsh Prateek Bora (4): > trace: rename TraceRecordHeader to TraceLogHeader > trace: remove unnecessary write_to_buffer() typecasting > trace: drop unused TraceBufferRecord->next_tbuf_idx field > trace: avoid pointer aliasing in trace_record_finish() > > Stefan Weil (2): > trace/simple: Fix compiler warning for 32 bit hosts > trace/simple: Replace asprintf by g_strdup_printf > > scripts/tracetool/backend/simple.py |2 +- > trace/simple.c | 35 > +-- > trace/simple.h |1 - > 3 files changed, 14 insertions(+), 24 deletions(-) > > -- > 1.7.10.4
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti writes: > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: >> >>>> We can know the guest is panicked when the guest runs on xen. >> >>>> But we do not have such feature on kvm. >> >>>> >> >>>> Another purpose of this feature is: management app(for example: >> >>>> libvirt) can do auto dump when the guest is panicked. If management >> >>>> app does not do auto dump, the guest's user can do dump by hand if >> >>>> he sees the guest is panicked. >> >>>> >> >>>> We have three solutions to implement this feature: >> >>>> 1. use vmcall >> >>>> 2. use I/O port >> >>>> 3. use virtio-serial. >> >>>> >> >>>> We have decided to avoid touching hypervisor. The reason why I choose >> >>>> choose the I/O port is: >> >>>> 1. it is easier to implememt >> >>>> 2. it does not depend any virtual device >> >>>> 3. it can work when starting the kernel >> >>> >> >>> How about searching for the "Kernel panic - not syncing" string >> >>> in the guests serial output? Say libvirtd could take an action upon >> >>> that? >> >> >> >> No, this is not satisfactory. It depends on the guest OS being >> >> configured to use the serial port for console output which we >> >> cannot mandate, since it may well be required for other purposes. >> > >> Please don't forget Windows guests, there is no console and no "Kernel >> Panic" string ;) >> >> What I used for debugging purposes on Windows guest is to register a >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR >> register. >> >> Yan. > > Considering whether a "panic-device" should cover other OSes is also > something to consider. Even for Linux, is "panic" the only case which > should be reported via the mechanism? What about oopses without panic? > > Is the mechanism general enough for supporting new events, etc. Hi, I think this discussion is gone of the deep end. Forget about !x86 platforms. They have their own way to do this sort of thing. Think of this feature like a status LED on a motherboard. These are very common and usually controlled by IO ports. We're simply reserving a "status LED" for the guest to indicate that it has paniced. Let's not over engineer this. Regards, Anthony Liguori > >> >> > Well, we have more than a single serial port, even when leaving >> > virtio-serial aside... >> > >> > Jan >> > >> > -- >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE >> > Corporate Competence Center Embedded Linux >> > -- >> > To unsubscribe from this list: send the line "unsubscribe kvm" in >> > the body of a message to majord...@vger.kernel.org >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti writes: > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: >> Marcelo Tosatti writes: >> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: >> >> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: >> >> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: >> >> >>>> We can know the guest is panicked when the guest runs on xen. >> >> >>>> But we do not have such feature on kvm. >> >> >>>> >> >> >>>> Another purpose of this feature is: management app(for example: >> >> >>>> libvirt) can do auto dump when the guest is panicked. If management >> >> >>>> app does not do auto dump, the guest's user can do dump by hand if >> >> >>>> he sees the guest is panicked. >> >> >>>> >> >> >>>> We have three solutions to implement this feature: >> >> >>>> 1. use vmcall >> >> >>>> 2. use I/O port >> >> >>>> 3. use virtio-serial. >> >> >>>> >> >> >>>> We have decided to avoid touching hypervisor. The reason why I choose >> >> >>>> choose the I/O port is: >> >> >>>> 1. it is easier to implememt >> >> >>>> 2. it does not depend any virtual device >> >> >>>> 3. it can work when starting the kernel >> >> >>> >> >> >>> How about searching for the "Kernel panic - not syncing" string >> >> >>> in the guests serial output? Say libvirtd could take an action upon >> >> >>> that? >> >> >> >> >> >> No, this is not satisfactory. It depends on the guest OS being >> >> >> configured to use the serial port for console output which we >> >> >> cannot mandate, since it may well be required for other purposes. >> >> > >> >> Please don't forget Windows guests, there is no console and no "Kernel >> >> Panic" string ;) >> >> >> >> What I used for debugging purposes on Windows guest is to register a >> >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR >> >> register. >> >> >> >> Yan. >> > >> > Considering whether a "panic-device" should cover other OSes is also \ > >> > something to consider. Even for Linux, is "panic" the only case which >> > should be reported via the mechanism? What about oopses without panic? >> > >> > Is the mechanism general enough for supporting new events, etc. >> >> Hi, >> >> I think this discussion is gone of the deep end. >> >> Forget about !x86 platforms. They have their own way to do this sort of >> thing. > > The panic function in kernel/panic.c has the following options, which > appear to be arch independent, on panic: > > - reboot > - blink Not sure the semantics of blink but that might be a good place for a pvops hook. > > None are paravirtual interfaces however. > >> Think of this feature like a status LED on a motherboard. These >> are very common and usually controlled by IO ports. >> >> We're simply reserving a "status LED" for the guest to indicate that it >> has paniced. Let's not over engineer this. > > My concern is that you end up with state that is dependant on x86. > > Subject: [PATCH v8 3/6] add a new runstate: RUN_STATE_GUEST_PANICKED > > Having the ability to stop/restart the guest (and even introducing a > new VM runstate) is more than a status LED analogy. I must admit, I don't know why a new runstate is necessary/useful. The kernel shouldn't have to care about the difference between a halted guest and a panicked guest. That level of information belongs in userspace IMHO. > Can this new infrastructure be used by other architectures? I guess I don't understand why the kernel side of this isn't anything more than a paravirt op hook that does a single outb() with the remaining logic handled 100% in QEMU. > Do you consider allowing support for Windows as overengineering? I don't think there is a way to hook BSOD on Windows so attempting to engineer something that works with Windows seems odd, no? Regards, Anthony Liguori > >> Regards, >> >> Anthony Liguori >> >> > >> >> >> >> > Well, we have more than a single serial port, even when leaving >> >> > virtio-serial aside... >> >> > >> >> > Jan >> >> > >> >> > -- >> >> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE >> >> > Corporate Competence Center Embedded Linux >> >> > -- >> >> > To unsubscribe from this list: send the line "unsubscribe kvm" in >> >> > the body of a message to majord...@vger.kernel.org >> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH] block-migration: deprecate block migration for the 1.2 release
Luiz Capitulino writes:
> On Tue, 14 Aug 2012 08:32:31 -0500
> Anthony Liguori wrote:
>
>> To be replaced with live block copy.
>>
>> Signed-off-by: Anthony Liguori
>> ---
>> migration.c |9 +
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/migration.c b/migration.c
>> index 653a3c1..babccf4 100644
>> --- a/migration.c
>> +++ b/migration.c
>> @@ -482,10 +482,19 @@ void qmp_migrate(const char *uri, bool has_blk, bool
>> blk,
>> MigrationParams params;
>> const char *p;
>> int ret;
>> +static bool suppress_deprecation_message;
>>
>> params.blk = blk;
>> params.shared = inc;
>>
>> +if (blk && !suppress_deprecation_message) {
>> +qerror_report(ERROR_CLASS_GENERIC_ERROR,
>> + "Block migration is deprecated. "
>> + "See http://wiki.qemu.org/Features/LiveBlockCopy "
>> + "for an alternative syntax.");
>
> Why not error_set()?
Because we fall through (we don't fail). This is just a warning.
If you error_set(), then the migration command fails. We don't want it
to fail.
I guess qerror_report will do that too :-(
I'll change it to an fprintf :-((
Regards,
Anthony Liguori
>
>> +suppress_deprecation_message = true;
>> +}
>> +
>> if (s->state == MIG_STATE_ACTIVE) {
>> error_set(errp, QERR_MIGRATION_ACTIVE);
>> return;
Re: [Qemu-devel] [PATCH 3/4] s390/kvm: Add a channel I/O based virtio transport driver.
Cornelia Huck writes:
> Add a driver for kvm guests that matches virtual ccw devices provided
> by the host as virtio bridge devices.
>
> These virtio-ccw devices use a special set of channel commands in order
> to perform virtio functions.
>
> Signed-off-by: Cornelia Huck
Hi,
Have you written an appendix for the virtio specification for
virtio-ccw? I think it would be good to include in this series for the
purposes of review.
Regards,
Anthony Liguori
> ---
> arch/s390/include/asm/irq.h | 1 +
> arch/s390/kernel/irq.c| 1 +
> drivers/s390/kvm/Makefile | 2 +-
> drivers/s390/kvm/virtio_ccw.c | 761
> ++
> 4 files changed, 764 insertions(+), 1 deletion(-)
> create mode 100644 drivers/s390/kvm/virtio_ccw.c
>
> diff --git a/arch/s390/include/asm/irq.h b/arch/s390/include/asm/irq.h
> index 2b9d418..b4bea53 100644
> --- a/arch/s390/include/asm/irq.h
> +++ b/arch/s390/include/asm/irq.h
> @@ -31,6 +31,7 @@ enum interruption_class {
> IOINT_CTC,
> IOINT_APB,
> IOINT_CSC,
> + IOINT_VIR,
> NMI_NMI,
> NR_IRQS,
> };
> diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
> index dd7630d..2cc7eed 100644
> --- a/arch/s390/kernel/irq.c
> +++ b/arch/s390/kernel/irq.c
> @@ -56,6 +56,7 @@ static const struct irq_class intrclass_names[] = {
> {.name = "CTC", .desc = "[I/O] CTC" },
> {.name = "APB", .desc = "[I/O] AP Bus" },
> {.name = "CSC", .desc = "[I/O] CHSC Subchannel" },
> + {.name = "VIR", .desc = "[I/O] Virtual I/O Devices" },
> {.name = "NMI", .desc = "[NMI] Machine Check" },
> };
>
> diff --git a/drivers/s390/kvm/Makefile b/drivers/s390/kvm/Makefile
> index 0815690..241891a 100644
> --- a/drivers/s390/kvm/Makefile
> +++ b/drivers/s390/kvm/Makefile
> @@ -6,4 +6,4 @@
> # it under the terms of the GNU General Public License (version 2 only)
> # as published by the Free Software Foundation.
>
> -obj-$(CONFIG_S390_GUEST) += kvm_virtio.o
> +obj-$(CONFIG_S390_GUEST) += kvm_virtio.o virtio_ccw.o
> diff --git a/drivers/s390/kvm/virtio_ccw.c b/drivers/s390/kvm/virtio_ccw.c
> new file mode 100644
> index 000..df0f994
> --- /dev/null
> +++ b/drivers/s390/kvm/virtio_ccw.c
> @@ -0,0 +1,761 @@
> +/*
> + * ccw based virtio transport
> + *
> + * Copyright IBM Corp. 2012
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License (version 2 only)
> + * as published by the Free Software Foundation.
> + *
> + *Author(s): Cornelia Huck
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * virtio related functions
> + */
> +
> +struct vq_config_block {
> + __u16 index;
> + __u16 num;
> +} __attribute__ ((packed));
> +
> +#define VIRTIO_CCW_CONFIG_SIZE 0x100
> +/* same as PCI config space size, should be enough for all drivers */
> +
> +struct virtio_ccw_device {
> + struct virtio_device vdev;
> + __u8 status;
> + __u8 config[VIRTIO_CCW_CONFIG_SIZE];
> + struct ccw_device *cdev;
> + struct ccw1 ccw;
> + __u32 area;
> + __u32 curr_io;
> + int err;
> + wait_queue_head_t wait_q;
> + spinlock_t lock;
> + struct list_head virtqueues;
> + unsigned long indicators; /* XXX - works because we're under 64 bit */
> + struct vq_config_block *config_block;
> +};
> +
> +struct vq_info_block {
> + __u64 queue;
> + __u16 num;
> +} __attribute__ ((packed));
> +
> +struct virtio_ccw_vq_info {
> + struct virtqueue *vq;
> + int num;
> + int queue_index;
> + void *queue;
> + struct vq_info_block *info_block;
> + struct list_head node;
> +};
> +
> +#define KVM_VIRTIO_CCW_RING_ALIGN 4096
> +
> +#define CCW_CMD_SET_VQ 0x13
> +#define CCW_CMD_VDEV_RESET 0x33
> +#define CCW_CMD_SET_IND 0x43
> +#define CCW_CMD_READ_FEAT 0x12
> +#define CCW_CMD_WRITE_FEAT 0x11
> +#define CCW_CMD_READ_CONF 0x22
> +#define CCW_CMD_WRITE_CONF 0x21
> +#define CCW_CMD_WRITE_STATUS 0x31
> +#define CCW_CMD_READ_VQ_CONF 0x32
> +
> +#define VIRTIO_CCW_DOING_SET_VQ 0x0001
> +#define VIRTIO_CCW_DOING_RESET 0x0004
> +#define VIRTIO_CCW_DOING_READ_FEAT 0x0
Re: [Qemu-devel] [PATCH v8] kvm: notify host when the guest is panicked
Marcelo Tosatti writes: > On Tue, Aug 14, 2012 at 02:35:34PM -0500, Anthony Liguori wrote: >> Marcelo Tosatti writes: >> >> > On Tue, Aug 14, 2012 at 01:53:01PM -0500, Anthony Liguori wrote: >> >> Marcelo Tosatti writes: >> >> >> >> > On Tue, Aug 14, 2012 at 05:55:54PM +0300, Yan Vugenfirer wrote: >> >> >> >> >> >> On Aug 14, 2012, at 1:42 PM, Jan Kiszka wrote: >> >> >> >> >> >> > On 2012-08-14 10:56, Daniel P. Berrange wrote: >> >> >> >> On Mon, Aug 13, 2012 at 03:21:32PM -0300, Marcelo Tosatti wrote: >> >> >> >>> On Wed, Aug 08, 2012 at 10:43:01AM +0800, Wen Congyang wrote: >> >> >> >>>> We can know the guest is panicked when the guest runs on xen. >> >> >> >>>> But we do not have such feature on kvm. >> >> >> >>>> >> >> >> >>>> Another purpose of this feature is: management app(for example: >> >> >> >>>> libvirt) can do auto dump when the guest is panicked. If >> >> >> >>>> management >> >> >> >>>> app does not do auto dump, the guest's user can do dump by hand if >> >> >> >>>> he sees the guest is panicked. >> >> >> >>>> >> >> >> >>>> We have three solutions to implement this feature: >> >> >> >>>> 1. use vmcall >> >> >> >>>> 2. use I/O port >> >> >> >>>> 3. use virtio-serial. >> >> >> >>>> >> >> >> >>>> We have decided to avoid touching hypervisor. The reason why I >> >> >> >>>> choose >> >> >> >>>> choose the I/O port is: >> >> >> >>>> 1. it is easier to implememt >> >> >> >>>> 2. it does not depend any virtual device >> >> >> >>>> 3. it can work when starting the kernel >> >> >> >>> >> >> >> >>> How about searching for the "Kernel panic - not syncing" string >> >> >> >>> in the guests serial output? Say libvirtd could take an action upon >> >> >> >>> that? >> >> >> >> >> >> >> >> No, this is not satisfactory. It depends on the guest OS being >> >> >> >> configured to use the serial port for console output which we >> >> >> >> cannot mandate, since it may well be required for other purposes. >> >> >> > >> >> >> Please don't forget Windows guests, there is no console and no "Kernel >> >> >> Panic" string ;) >> >> >> >> >> >> What I used for debugging purposes on Windows guest is to register a >> >> >> bugcheck callback in virtio-net driver and write 1 to VIRTIO_PCI_ISR >> >> >> register. >> >> >> >> >> >> Yan. >> >> > >> >> > Considering whether a "panic-device" should cover other OSes is also \ >> > >> >> > something to consider. Even for Linux, is "panic" the only case which >> >> > should be reported via the mechanism? What about oopses without panic? >> >> > >> >> > Is the mechanism general enough for supporting new events, etc. >> >> >> >> Hi, >> >> >> >> I think this discussion is gone of the deep end. >> >> >> >> Forget about !x86 platforms. They have their own way to do this sort of >> >> thing. >> > >> > The panic function in kernel/panic.c has the following options, which >> > appear to be arch independent, on panic: >> > >> > - reboot >> > - blink >> >> Not sure the semantics of blink but that might be a good place for a >> pvops hook. >> >> > >> > None are paravirtual interfaces however. >> > >> >> Think of this feature like a status LED on a motherboard. These >> >> are very common and usually controlled by IO ports. >> >> >> >> We're simply reserving a "status LED" for the guest to indicate that it >> >> has paniced. Let's not over engineer this. >> > >> > My concern is that you end up wi
[Qemu-devel] [PATCH] win32: provide separate macros for weak decls and definitions
mingw32 seems to want the declaration to also carry the weak attribute.
Strangely, gcc on Linux absolutely does not want the declaration to be marked
as weak. This may not be the right fix, but it seems to do the trick.
Signed-off-by: Anthony Liguori
---
arch_init.h |4
compiler.h |6 ++
qmp.c |8 +++-
target-i386/cpu.c |4 ++--
target-ppc/translate_init.c |4 ++--
5 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/arch_init.h b/arch_init.h
index 547f93c..d9c572a 100644
--- a/arch_init.h
+++ b/arch_init.h
@@ -1,6 +1,8 @@
#ifndef QEMU_ARCH_INIT_H
#define QEMU_ARCH_INIT_H
+#include "qmp-commands.h"
+
enum {
QEMU_ARCH_ALL = -1,
QEMU_ARCH_ALPHA = 1,
@@ -32,4 +34,6 @@ int tcg_available(void);
int kvm_available(void);
int xen_available(void);
+CpuDefinitionInfoList GCC_WEAK_DECL *arch_query_cpu_definitions(Error **errp);
+
#endif
diff --git a/compiler.h b/compiler.h
index f76921e..07ba1f8 100644
--- a/compiler.h
+++ b/compiler.h
@@ -45,7 +45,13 @@
# define GCC_ATTR __attribute__((__unused__, format(gnu_printf, 1, 2)))
# define GCC_FMT_ATTR(n, m) __attribute__((format(gnu_printf, n, m)))
# endif
+#if defined(_WIN32)
+#define GCC_WEAK __attribute__((weak))
+#define GCC_WEAK_DECL GCC_WEAK
+#else
#define GCC_WEAK __attribute__((weak))
+#define GCC_WEAK_DECL
+#endif
#else
#define GCC_ATTR /**/
#define GCC_FMT_ATTR(n, m)
diff --git a/qmp.c b/qmp.c
index 6c1e4e8..8463922 100644
--- a/qmp.c
+++ b/qmp.c
@@ -468,8 +468,14 @@ DevicePropertyInfoList *qmp_device_list_properties(const
char *typename,
return prop_list;
}
-CpuDefinitionInfoList GCC_WEAK *qmp_query_cpu_definitions(Error **errp)
+CpuDefinitionInfoList GCC_WEAK *arch_query_cpu_definitions(Error **errp)
{
error_set(errp, QERR_NOT_SUPPORTED);
return NULL;
}
+
+CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+{
+return arch_query_cpu_definitions(errp);
+}
+
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 6d5d0d6..120a2e3 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -28,7 +28,7 @@
#include "qemu-config.h"
#include "qapi/qapi-visit-core.h"
-#include "qmp-commands.h"
+#include "arch_init.h"
#include "hyperv.h"
@@ -1126,7 +1126,7 @@ void x86_cpu_list(FILE *f, fprintf_function cpu_fprintf,
const char *optarg)
}
}
-CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
{
CpuDefinitionInfoList *cpu_list = NULL;
x86_def_t *def;
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 6fe4168..fba2b42 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -27,7 +27,7 @@
#include "gdbstub.h"
#include
#include "kvm_ppc.h"
-#include "qmp-commands.h"
+#include "arch_init.h"
//#define PPC_DUMP_CPU
//#define PPC_DEBUG_SPR
@@ -10346,7 +10346,7 @@ void ppc_cpu_list (FILE *f, fprintf_function
cpu_fprintf)
}
}
-CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+CpuDefinitionInfoList *arch_query_cpu_definitions(Error **errp)
{
CpuDefinitionInfoList *cpu_list = NULL;
int i;
--
1.7.5.4
Re: [Qemu-devel] [PATCH 2/2] cpu: for cpu-user and cpu-softmmu and make cpu-softmmu a child of DeviceState
Andreas Färber writes: > Am 10.08.2012 19:00, schrieb Anthony Liguori: >> The line between linux-user and softmmu is not very well defined right now. >> linux-user really don't want to include devices and making CpuState a child >> of >> DeviceState would require pulling lots of stuff into linux-user. >> >> To solve this, we simply fork cpu-user and cpu-softmmu letting them evolve >> independently. > > In the KVM call discussion there was no consensus that such independent > evolution is actually desirable. > > For example, moving forward with eliminating the CPU_COMMON mess this > will mean duplicating the implementation of cpu_common_reset() - > currently empty but in need of at least some zero'ing in the future. My > fear is that such duplication will lead to fixes getting applied to the > softmmu version only and contributors forgetting / being unaware that > there is a second place to apply the same change. Well the alternative is to build qdev for linux-user. I tried very hard to make that work but I gave up. That is without a doubt the Right Solution. > > Putting different TypeInfos into seperate source files is fine with me, > but I would rather have shared implementations with an #ifdef than > duplicating things. I fear a tremendous amount of #ifdef's becoming necessary to make this work long term. That's why I prefer divergence. linux-user can stay simple and softmmu will be unaffected. > By comparison, forgetting to add a new field in either struct would lead > to a compilation failure, getting noticed, so that seems doable. > >> We also need to push a qdev_init_nofail() into all callers of cpu_init(). >> This >> is needed eventually anyway so might as well do this now. > > Patch would be better readable doing that as a follow-up... Pretty sure that causes a breakage although I don't remember why so I don't think splitting up the patch is possible. > >> Signed-off-by: Anthony Liguori >> --- >> Makefile.objs |6 --- >> hw/armv7m.c |1 + >> hw/axis_dev88.c |1 + >> hw/exynos4210.c |1 + >> hw/highbank.c |1 + >> hw/integratorcp.c |1 + >> hw/leon3.c|1 + >> hw/lm32_boards.c |2 + >> hw/milkymist.c|1 + >> hw/mips_fulong2e.c|1 + >> hw/mips_jazz.c|1 + >> hw/mips_malta.c |1 + >> hw/mips_mipssim.c |1 + >> hw/mips_r4k.c |1 + >> hw/musicpal.c |1 + >> hw/omap1.c|1 + >> hw/omap2.c|1 + >> hw/pc.c |1 + >> hw/petalogix_ml605_mmu.c |1 + >> hw/petalogix_s3adsp1800_mmu.c |1 + >> hw/ppc440_bamboo.c|1 + >> hw/ppc4xx_devs.c |1 + >> hw/ppc_newworld.c |1 + >> hw/ppc_oldworld.c |1 + >> hw/ppc_prep.c |1 + >> hw/ppce500_mpc8544ds.c|1 + >> hw/pxa2xx.c |1 + >> hw/r2d.c |1 + >> hw/realview.c |1 + >> hw/s390-virtio.c |1 + >> hw/spapr.c|1 + >> hw/strongarm.c|1 + >> hw/sun4m.c|1 + >> hw/sun4u.c|1 + >> hw/versatilepb.c |1 + >> hw/vexpress.c |2 + >> hw/virtex_ml507.c |1 + >> hw/xen_machine_pv.c |1 + >> hw/xilinx_zynq.c |1 + >> hw/xtensa_lx60.c |1 + >> hw/xtensa_sim.c |1 + >> include/qemu/cpu-softmmu.h| 82 +++ >> include/qemu/cpu-user.h | 75 >> include/qemu/cpu.h| 85 >> ++--- >> qemu-common.h |3 +- >> qom/Makefile.objs |5 +- >> qom/cpu-softmmu.c | 66 +++ >> qom/cpu-user.c| 70 + >> 48 files changed, 343 insertions(+), 91 deletions(-) >> create mode 100644 include/qemu/cpu-softmmu.h >> create mode 100644 include/qemu/cpu-user.h >> create mode 100644 qom/cpu-softmmu.c >> create mode 100644 qom/cpu-user.c >> >> diff --git a/Makefile.objs b/Makefile.objs >>
Re: [Qemu-devel] [PATCH 0/4] [PULL] qemu-kvm.git uq/master queue
Marcelo Tosatti writes: > The following changes since commit 873359d411eeb380906761e46839a2b705dbcf75: > > Merge branch 'linux-user.next' of > git://git.linaro.org/people/pmaydell/qemu-arm (2012-08-14 19:50:22 +) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git uq/master Pulled. Thanks. Regards, Anthony Liguori > > Jan Kiszka (3): > kvm: i8254: Cache kernel clock offset in KVMPITState > kvm: i8254: Finish time conversion fix > kvmvapic: Disable if there is insufficient memory > > Peter Maydell (1): > update-linux-headers.sh: Pull in asm-generic/kvm_para.h > > hw/apic_common.c|4 ++- > hw/kvm/i8254.c | 52 +- > scripts/update-linux-headers.sh |5 +++ > 3 files changed, 42 insertions(+), 19 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PULL 00/10] Block patches
Kevin Wolf writes: > The following changes since commit 03834e22abafbc8dc4052d46a5ccd6dd135a54a3: > > Merge remote-tracking branch 'origin/master' into staging (2012-08-14 > 15:19:50 -0500) > > are available in the git repository at: > > http://repo.or.cz/r/qemu/kevin.git for-anthony > Pulled. Thanks. Regards, Anthony Liguori > Corey Bryant (7): > qemu-char: Add MSG_CMSG_CLOEXEC flag to recvmsg > qapi: Introduce add-fd, remove-fd, query-fdsets > block: Prevent detection of /dev/fdset/ as floppy > block: Convert open calls to qemu_open > block: Convert close calls to qemu_close > block: Enable qemu_open/close to work with fd sets > monitor: Clean up fd sets on monitor disconnect > > Kevin Wolf (2): > block: Flush parent to OS with cache=unsafe > qemu-iotests: Fix 030 after switch to GenericError > > Stefan Priebe (1): > iscsi: Fix NULL dereferences / races between task completion and abort > > Makefile |6 +- > block.c|3 +- > block/iscsi.c | 55 - > block/raw-posix.c | 46 > block/raw-win32.c |6 +- > block/vdi.c|5 +- > block/vmdk.c | 25 ++--- > block/vpc.c|4 +- > block/vvfat.c | 16 ++-- > cutils.c |5 + > monitor.c | 294 > > monitor.h |5 + > osdep.c| 116 +++ > qapi-schema.json | 98 > qemu-char.c| 12 ++- > qemu-common.h |2 + > qemu-tool.c| 20 > qemu-user.c| 20 > qmp-commands.hx| 122 > savevm.c |4 +- > tests/Makefile |2 +- > tests/qemu-iotests/030 |6 +- > 22 files changed, 776 insertions(+), 96 deletions(-)
Re: [Qemu-devel] [PULL 0/9 for-1.2] Trivial patches for 11 to 15 August 2012
Stefan Hajnoczi writes: > The last pull request for QEMU 1.2! > > The following changes since commit 03834e22abafbc8dc4052d46a5ccd6dd135a54a3: > > Merge remote-tracking branch 'origin/master' into staging (2012-08-14 > 15:19:50 -0500) > Pulled. Thanks. Regards, Anthony Liguori > are available in the git repository at: > > git://github.com/stefanha/qemu.git trivial-patches > > for you to fetch changes up to c3594ed73e0a7e7feae309be79f0eb6bafcc02ab: > > ivshmem, qdev-monitor: fix order of qerror parameters (2012-08-15 15:37:08 > +0100) > > > Alberto Garcia (1): > ivshmem, qdev-monitor: fix order of qerror parameters > > Alejandro Martinez Ruiz (1): > ehci: fix assertion typo > > Peter Maydell (3): > Makefile: Avoid explicit list of directories in clean target > cputlb.c: Fix out of date comment > iov_send_recv(): Handle zero bytes case even if OS does not > > Stefan Weil (4): > trace: Fix "Qemu" -> "QEMU" > docs: Fix spelling (propery -> property) > Spelling fix in comment (peripherans -> peripherals) > framebuffer: Fix spelling in comment (leight -> height) > > Makefile |7 ++- > cputlb.c |4 +++- > docs/bootindex.txt |2 +- > hw/framebuffer.c |2 +- > hw/ivshmem.c |3 ++- > hw/qdev-monitor.c |2 +- > hw/usb/hcd-ehci.c |2 +- > hw/versatilepb.c |2 +- > iov.c |7 +++ > scripts/simpletrace.py |2 +- > 10 files changed, 20 insertions(+), 13 deletions(-) > > -- > 1.7.10.4
Re: [Qemu-devel] [PATCH v2 for-1.2 00/27] Suppress unused default drives
Peter Maydell writes: > On 15 August 2012 20:25, Alexander Graf wrote: >> On 15.08.2012, at 21:17, Markus Armbruster wrote: >> >>> We create a number of default drives for machines to use: floppy, >>> CD-ROM, SD card. Machines can suppress the ones they don't use, but >>> few do. Fix that. > >>> v2: >>> Make default drives opt-in instead of opt-out for boards (Andreas) >>> Cover new target unicore32 >>> Bonus fix for unicore32 -M puv3 without -kernel >>> Cover mpc8544ds, pseries (missed in v1) >> >> Nack from my POV. Too late for 1.2. Better get this in early for 1.3. No, it's not too late for 1.2. The release process is pretty clear. Major features needed to be posted before August 1st. The late to get non-bug fixes in is today. This is not a major feature but more importantly, has gone through a few revisions and has gotten positive review comments. So let's not just go around declaring things as being "too late". If something needs more review or hasn't gotten adequate review, it's perfectly acceptable to point that out. But please don't just Nack and say it's too late. > Agree. I also think we should follow up Paul Brook's suggestion > that we don't need to have any kind of "default sd card" flag > at all. Floppy is weird because we don't properly separate out > the drive and the controller, right? Not sure about cdrom... This is a valid critique and suggests that more review is needed. Given that, I won't pick this up today. But let's not throw around Nacks without justification. Regards, Anthony Liguori > > -- PMM
Re: [Qemu-devel] Hard freeze for 1.2 today
Eric Blake writes: > On 08/15/2012 08:22 AM, anth...@codemonkey.ws wrote: >> >> Hi, >> >> Today is the hard freeze for 1.2. If you have any pull requests and/or >> patches targetted for the hard freeze, please send them by 3pm >> US/Central time today and clearly mark them "for-1.2". >> >> If there are existing patches and/or pull requests on the mailing list >> that you think should be in 1.2, please respond to the email with a >> pointer to the mail. > > Anyone else interested in helping whip this patch to qemu-img into > shape? Libvirt would really love to have JSON output from qemu-img in 1.2: > https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg02864.html Really needs at least an Ack from Kevin with respect to whether qemu-img is going to be the interface that we expose this kind of information from. I think this probably needs to wait until 1.3 (assuming it's even the right interface). Regards, Anthony Liguori > > -- > Eric Blake ebl...@redhat.com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org
Re: [Qemu-devel] [PATCH v2 for-1.2 00/27] Suppress unused default drives
Markus Armbruster writes: > Anthony Liguori writes: > >> Peter Maydell writes: >> >>> On 15 August 2012 20:25, Alexander Graf wrote: >>>> On 15.08.2012, at 21:17, Markus Armbruster wrote: >>>> >>>>> We create a number of default drives for machines to use: floppy, >>>>> CD-ROM, SD card. Machines can suppress the ones they don't use, but >>>>> few do. Fix that. >>> >>>>> v2: >>>>> Make default drives opt-in instead of opt-out for boards (Andreas) >>>>> Cover new target unicore32 >>>>> Bonus fix for unicore32 -M puv3 without -kernel >>>>> Cover mpc8544ds, pseries (missed in v1) >>>> >>>> Nack from my POV. Too late for 1.2. Better get this in early for 1.3. > > What's the risk? > > For the record, I tested every single machine to make sure it still gets > default drives for any drive it uses. > >> No, it's not too late for 1.2. >> >> The release process is pretty clear. Major features needed to be posted >> before August 1st. The late to get non-bug fixes in is today. >> >> This is not a major feature but more importantly, has gone through a few >> revisions and has gotten positive review comments. >> >> So let's not just go around declaring things as being "too late". If >> something needs more review or hasn't gotten adequate review, it's >> perfectly acceptable to point that out. But please don't just Nack and >> say it's too late. >> >>> Agree. I also think we should follow up Paul Brook's suggestion >>> that we don't need to have any kind of "default sd card" flag >>> at all. Floppy is weird because we don't properly separate out >>> the drive and the controller, right? Not sure about cdrom... >> >> This is a valid critique and suggests that more review is needed. >> Given that, I won't pick this up today. But let's not throw around >> Nacks without justification. > > Paul's idea is worth pursuing. But I don't think we should reject a > improvement we can have now just we can imagine an even nicer > improvement we may have some day. Taking the former now doesn't make > the latter any harder. If doing it a different way means touching 50 files again, then it's best not to rush into that. There is something to be said to for avoiding unnecessary churn. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH v2 for-1.2 00/27] Suppress unused default drives
Peter Maydell writes: > On 15 August 2012 20:58, Anthony Liguori wrote: >> Peter Maydell writes: >>> On 15 August 2012 20:25, Alexander Graf wrote: >>>> Nack from my POV. Too late for 1.2. Better get this in early for 1.3. >> >> No, it's not too late for 1.2. >> >> The release process is pretty clear. Major features needed to be posted >> before August 1st. The late to get non-bug fixes in is today. > > Yes. I don't think that means "it's OK to send out a patchset that > isn't just doing cosmetic fixes to a generally OK previous version > on the day of feature freeze and expect that people will have time > to review it". > > Basically, if this wasn't freeze day I'd expect a patchseries like this > to sit on the list for at least three days or so for review. > >> This is not a major feature but more importantly, has gone through a few >> revisions and has gotten positive review comments. > > Anything touching 50 files is "major feature" IMHO, and the first > version of this patchset went out just 6 days ago. > > Short rc phases only work if people are reasonably sensible about > not putting in enormous numbers of patches right at the freeze > deadline, IMHO. This patchset doesn't meet the "value obtained > for amount of disruption / quality of review" bar for me, is all. http://ozlabs.org/~rusty/index.cgi/tech/2007-05-04.html It's not that I disagree with you. I think this is good feedback for a series like this. I just don't want people sending out single sentence "Nack" emails for patch series just because we're at the end of the release cycle. It sets the wrong tone IMHO. Regards, Anthony Liguori > > -- PMM
Re: [Qemu-devel] [PULL 0/2] s390 patch queue 2012-08-15
Alexander Graf writes: > Hi Blue / Aurelien, > > This is my current patch queue for s390. Please pull. > Pulled. Thanks. Regards, Anthony Liguori > Alex > > > The following changes since commit 03834e22abafbc8dc4052d46a5ccd6dd135a54a3: > Anthony Liguori (1): > Merge remote-tracking branch 'origin/master' into staging > > are available in the git repository at: > > git://repo.or.cz/qemu/agraf.git s390-for-upstream > > Christian Borntraeger (2): > s390: Fix error handling and condition code of service call > s390: provide interface for service interrupt/introduce interrupt.c > > target-s390x/Makefile.objs |2 +- > target-s390x/cpu.h |3 +++ > target-s390x/interrupt.c | 29 + > target-s390x/kvm.c |5 +++-- > target-s390x/op_helper.c | 43 +++ > 5 files changed, 55 insertions(+), 27 deletions(-) > create mode 100644 target-s390x/interrupt.c
Re: [Qemu-devel] [PULL 00/24] ppc patch queue 2012-08-15
Alexander Graf writes:
> Hi Blue / Aurelien,
>
> This is my current patch queue for ppc. Please pull.
>
Pulled. Thanks.
Regards,
Anthony Liguori
> Alex
>
>
> The following changes since commit 03834e22abafbc8dc4052d46a5ccd6dd135a54a3:
> Anthony Liguori (1):
> Merge remote-tracking branch 'origin/master' into staging
>
> are available in the git repository at:
>
> git://repo.or.cz/qemu/agraf.git ppc-for-upstream
>
> Alexander Graf (4):
> Revert "PPC: e500: Use new MPIC dt format"
> xbzrle: fix compilation on ppc32
> PPC: spapr: Rework VGA select logic
> PPC: spapr: Remove global variable
>
> Alexey Kardashevskiy (9):
> pseries pci: removed redundant busdev
> pseries pci: spapr_populate_pci_devices renamed to spapr_populate_pci_dt
> pseries: Rework irq assignment to avoid carrying qemu_irqs around
> pseries: Separate PCI RTAS setup from common from emulation specific
> PCI setup
> pseries: added allocator for a block of IRQs
> pseries: Export find_phb() utility function for PCI code
> pseries: Add trace event for PCI irqs
> pseries: Add PCI MSI/MSI-X support
> pseries dma: DMA window params added to PHB and DT population changed
>
> Benjamin Herrenschmidt (1):
> pseries: Update SLOF
>
> Bharat Bhushan (1):
> openpic: Added BRR1 register
>
> David Gibson (3):
> ppc: Fix bug in handling of PAPR hypercall exits
> pseries: Remove extraneous prints
> pseries: Update SLOF firmware image
>
> Scott Wood (4):
> PPC: e500: rename mpc8544ds into generic file
> PPC: e500: change internal references away from mpc8544ds
> PPC: e500: split mpc8544ds machine from generic e500 code
> PPC: e500: add generic e500 platform
>
> zhlci...@gmail.com (2):
> Add one new file vga-pci.h and cleanup on all platforms
> spapr: Add support for -vga option
>
> hw/alpha_pci.c |1 +
> hw/cirrus_vga.c|2 +-
> hw/mips_malta.c|1 +
> hw/openpic.c | 17 ++
> hw/pc.c|1 +
> hw/pc.h|4 -
> hw/ppc/Makefile.objs |4 +-
> hw/{ppce500_mpc8544ds.c => ppc/e500.c} | 141 ++
> hw/ppc/e500.h | 21 ++
> hw/ppc/e500plat.c | 60 ++
> hw/ppc/mpc8544ds.c | 61 ++
> hw/ppc_newworld.c |2 +-
> hw/ppc_oldworld.c |2 +-
> hw/ppc_prep.c |1 +
> hw/spapr.c | 101 +++---
> hw/spapr.h | 17 +-
> hw/spapr_iommu.c | 58 --
> hw/spapr_llan.c|2 +-
> hw/spapr_pci.c | 326
>
> hw/spapr_pci.h | 34 +++-
> hw/spapr_vio.c | 14 +-
> hw/spapr_vio.h |8 +-
> hw/spapr_vty.c |2 +-
> hw/sun4u.c |1 +
> hw/vga-pci.c |2 +-
> hw/vga-pci.h | 12 ++
> hw/xics.c | 12 +-
> hw/xics.h |5 +-
> pc-bios/README |2 +-
> pc-bios/slof.bin | Bin 880496 -> 878640 bytes
> roms/SLOF |2 +-
> savevm.c |2 +-
> target-ppc/kvm.c |2 +-
> trace-events |8 +
> 34 files changed, 718 insertions(+), 210 deletions(-)
> rename hw/{ppce500_mpc8544ds.c => ppc/e500.c} (85%)
> create mode 100644 hw/ppc/e500.h
> create mode 100644 hw/ppc/e500plat.c
> create mode 100644 hw/ppc/mpc8544ds.c
> create mode 100644 hw/vga-pci.h
[Qemu-devel] [PATCH 2/4] Adding qemu-seccomp.[ch] (v8)
From: Eduardo Otubo
Signed-off-by: Eduardo Otubo
Signed-off-by: Anthony Liguori
---
v1:
- I added a syscall struct using priority levels as described in the
libseccomp man page. The priority numbers are based to the frequency
they appear in a sample strace from a regular qemu guest run under
libvirt.
Libseccomp generates linear BPF code to filter system calls, those rules
are read one after another. The priority system places the most common
rules first in order to reduce the overhead when processing them.
v1 -> v2:
- Fixed some style issues
- Removed code from vl.c and created qemu-seccomp.[ch]
- Now using ARRAY_SIZE macro
- Added more syscalls without priority/frequency set yet
v2 -> v3:
- Adding copyright and license information
- Replacing seccomp_whitelist_count just by ARRAY_SIZE
- Adding header protection to qemu-seccomp.h
- Moving QemuSeccompSyscall definition to qemu-seccomp.c
- Negative return from seccomp_start is fatal now.
- Adding open() and execve() to the whitelis
v3 -> v4:
- Tests revealed a bigger set of syscalls.
- seccomp_start() now has an argument to set the mode according to the
configure option trap or kill.
v4 -> v5:
- Tests on x86_64 required a new specific set of system calls.
- libseccomp release 1.0.0: part of the API have changed in this last
release, had to adapt to the new function signatures.
---
qemu-seccomp.c | 141
qemu-seccomp.h | 22 +
2 files changed, 163 insertions(+), 0 deletions(-)
create mode 100644 qemu-seccomp.c
create mode 100644 qemu-seccomp.h
diff --git a/qemu-seccomp.c b/qemu-seccomp.c
new file mode 100644
index 000..64329a3
--- /dev/null
+++ b/qemu-seccomp.c
@@ -0,0 +1,141 @@
+/*
+ * QEMU seccomp mode 2 support with libseccomp
+ *
+ * Copyright IBM, Corp. 2012
+ *
+ * Authors:
+ * Eduardo Otubo
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ */
+#include
+#include
+#include "qemu-seccomp.h"
+
+struct QemuSeccompSyscall {
+int32_t num;
+uint8_t priority;
+};
+
+static const struct QemuSeccompSyscall seccomp_whitelist[] = {
+{ SCMP_SYS(timer_settime), 255 },
+{ SCMP_SYS(timer_gettime), 254 },
+{ SCMP_SYS(futex), 253 },
+{ SCMP_SYS(select), 252 },
+{ SCMP_SYS(recvfrom), 251 },
+{ SCMP_SYS(sendto), 250 },
+{ SCMP_SYS(read), 249 },
+{ SCMP_SYS(brk), 248 },
+{ SCMP_SYS(clone), 247 },
+{ SCMP_SYS(mmap), 247 },
+{ SCMP_SYS(mprotect), 246 },
+{ SCMP_SYS(execve), 245 },
+{ SCMP_SYS(open), 245 },
+{ SCMP_SYS(ioctl), 245 },
+{ SCMP_SYS(recvmsg), 245 },
+{ SCMP_SYS(sendmsg), 245 },
+{ SCMP_SYS(accept), 245 },
+{ SCMP_SYS(connect), 245 },
+{ SCMP_SYS(gettimeofday), 245 },
+{ SCMP_SYS(readlink), 245 },
+{ SCMP_SYS(access), 245 },
+{ SCMP_SYS(prctl), 245 },
+{ SCMP_SYS(signalfd), 245 },
+#if defined(__i386__)
+{ SCMP_SYS(fcntl64), 245 },
+{ SCMP_SYS(fstat64), 245 },
+{ SCMP_SYS(stat64), 245 },
+{ SCMP_SYS(getgid32), 245 },
+{ SCMP_SYS(getegid32), 245 },
+{ SCMP_SYS(getuid32), 245 },
+{ SCMP_SYS(geteuid32), 245 },
+{ SCMP_SYS(sigreturn), 245 },
+{ SCMP_SYS(_newselect), 245 },
+{ SCMP_SYS(_llseek), 245 },
+{ SCMP_SYS(mmap2), 245},
+{ SCMP_SYS(sigprocmask), 245 },
+#elif defined(__x86_64__)
+{ SCMP_SYS(sched_getparam), 245},
+{ SCMP_SYS(sched_getscheduler), 245},
+{ SCMP_SYS(fstat), 245},
+{ SCMP_SYS(clock_getres), 245},
+{ SCMP_SYS(sched_get_priority_min), 245},
+{ SCMP_SYS(sched_get_priority_max), 245},
+{ SCMP_SYS(stat), 245},
+{ SCMP_SYS(socket), 245},
+{ SCMP_SYS(setsockopt), 245},
+{ SCMP_SYS(uname), 245},
+{ SCMP_SYS(semget), 245},
+#endif
+{ SCMP_SYS(eventfd2), 245 },
+{ SCMP_SYS(dup), 245 },
+{ SCMP_SYS(gettid), 245 },
+{ SCMP_SYS(timer_create), 245 },
+{ SCMP_SYS(exit), 245 },
+{ SCMP_SYS(clock_gettime), 245 },
+{ SCMP_SYS(time), 245 },
+{ SCMP_SYS(restart_syscall), 245 },
+{ SCMP_SYS(pwrite64), 245 },
+{ SCMP_SYS(chown), 245 },
+{ SCMP_SYS(openat), 245 },
+{ SCMP_SYS(getdents), 245 },
+{ SCMP_SYS(timer_delete), 245 },
+{ SCMP_SYS(exit_group), 245 },
+{ SCMP_SYS(rt_sigreturn), 245 },
+{ SCMP_SYS(sync), 245 },
+{ SCMP_SYS(pread64), 245 },
+{ SCMP_SYS(madvise), 245 },
+{ SCMP_SYS(set_robust_list), 245 },
+{ SCMP_SYS(lseek), 245 },
+{ SCMP_SYS(pselect6), 245 },
+{ SCMP_SYS(fork), 245 },
+{ SCMP_SYS(bind), 245 },
+{ SCMP_SYS(listen), 245 },
+{ SCMP_SYS(eventfd), 245 },
+{ SCMP_SYS(rt_sigprocmask), 245 },
+{ SCMP_SYS(write), 244 },
+{ SCMP_SYS(fcntl), 243 },
+{ SCMP_SYS(tgkill), 242 },
+{ SCMP_
[Qemu-devel] [PATCH 1/4] Adding support for libseccomp in configure and Makefile (v8)
From: Eduardo Otubo Adding basic options to the configure script to use libseccomp or not. The default is set to 'no'. If the flag --enable-libseccomp is used, the script will check for its existence using pkg-config. Signed-off-by: Eduardo Otubo Signed-off-by: Anthony Liguori --- v1 -> v2: - As I removed all the code related to seccomp from vl.c, I created qemu-seccomp.[ch]. - Also making the configure script to add the specific line to Makefile.obj in order to compile with appropriate support to seccomp. v2 -> v3: - Removing the line from Makefile.obj and adding it to Makefile.objs. - Marking libseccomp default option to 'yes' in the configure script. v3 -> v8: - fix configure probe if libseccomp isn't available (aliguori) --- Makefile.objs |6 ++ configure | 26 ++ 2 files changed, 32 insertions(+), 0 deletions(-) diff --git a/Makefile.objs b/Makefile.objs index 309d066..4412757 100644 --- a/Makefile.objs +++ b/Makefile.objs @@ -97,6 +97,12 @@ common-obj-y += qemu-timer.o qemu-timer-common.o common-obj-$(CONFIG_SLIRP) += slirp/ ## +# libseccomp +ifeq ($(CONFIG_SECCOMP),y) +common-obj-y += qemu-seccomp.o +endif + +## # libuser user-obj-y = diff --git a/configure b/configure index 45b9268..5267d53 100755 --- a/configure +++ b/configure @@ -218,6 +218,7 @@ zlib="yes" guest_agent="yes" libiscsi="" coroutine="" +seccomp="" # parse CC options first for opt do @@ -864,6 +865,10 @@ for opt do ;; --disable-guest-agent) guest_agent="no" ;; + --enable-seccomp) seccomp="yes" + ;; + --disable-seccomp) seccomp="no" + ;; *) echo "ERROR: unknown option $opt"; show_help="yes" ;; esac @@ -1152,6 +1157,8 @@ echo " --disable-usb-redir disable usb network redirection support" echo " --enable-usb-redir enable usb network redirection support" echo " --disable-guest-agentdisable building of the QEMU Guest Agent" echo " --enable-guest-agent enable building of the QEMU Guest Agent" +echo " --disable-seccompdisable seccomp support" +echo " --enable-seccomp enables seccomp support" echo " --with-coroutine=BACKEND coroutine backend. Supported options:" echo " gthread, ucontext, sigaltstack, windows" echo "" @@ -1414,6 +1421,20 @@ EOF fi ## +# libseccomp check + +if test "$seccomp" != "no" ; then +if $pkg_config libseccomp --modversion >/dev/null 2>&1; then +LIBS=`$pkg_config --libs libseccomp` + seccomp="yes" +else + seccomp="no" + if test "$seccomp" = "yes"; then +feature_not_found "libseccomp" + fi +fi +fi +## # xen probe if test "$xen" != "no" ; then @@ -3143,6 +3164,7 @@ echo "usb net redir $usb_redir" echo "OpenGL support$opengl" echo "libiscsi support $libiscsi" echo "build guest agent $guest_agent" +echo "seccomp support $seccomp" echo "coroutine backend $coroutine_backend" if test "$sdl_too_old" = "yes"; then @@ -3438,6 +3460,10 @@ if test "$libiscsi" = "yes" ; then echo "CONFIG_LIBISCSI=y" >> $config_host_mak fi +if test "$seccomp" = "yes"; then + echo "CONFIG_SECCOMP=y" >> $config_host_mak +fi + # XXX: suppress that if [ "$bsd" = "yes" ] ; then echo "CONFIG_BSD=y" >> $config_host_mak -- 1.7.5.4
[Qemu-devel] [PATCH 3/4] Adding seccomp calls to vl.c (v8)
From: Eduardo Otubo
Signed-off-by: Eduardo Otubo
Signed-off-by: Anthony Liguori
---
v1:
- Full seccomp calls and data included in vl.c
v1 -> v2:
- Full seccomp calls and data removed from vl.c and put into separate
qemu-seccomp.[ch] file.
---
vl.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/vl.c b/vl.c
index d01256a..1010248 100644
--- a/vl.c
+++ b/vl.c
@@ -63,6 +63,11 @@
#include
#include
#endif
+
+#ifdef CONFIG_SECCOMP
+#include "qemu-seccomp.h"
+#endif
+
#ifdef __sun__
#include
#include
@@ -2344,6 +2349,14 @@ int main(int argc, char **argv, char **envp)
const char *trace_events = NULL;
const char *trace_file = NULL;
+#ifdef CONFIG_SECCOMP
+if (seccomp_start() < 0) {
+fprintf(stderr,
+"seccomp: failed to install syscall filter in the kernel\n");
+exit(1);
+}
+#endif
+
atexit(qemu_run_exit_notifiers);
error_set_progname(argv[0]);
--
1.7.5.4
[Qemu-devel] [PATCH 0/4] Add -sandbox option to enable seccomp mode 2
Hi, I attempted to apply Eduardo's seccomp patches and ran into a number of problems. In the interest of time, I thought it would be easier for me to fix them and just respin the series myself. I've tested this as best I can--I don't have a seccomp capable kernel. But since the option is available regardless of kernel support, I feel pretty confident that this at least as correct as Eduardo's series.
[Qemu-devel] [PATCH 4/4] Command line support for seccomp with -sandbox (v8)
From: Eduardo Otubo
Signed-off-by: Eduardo Otubo
Signed-off-by: Anthony Liguori
---
v7 -> v8
- Parse options correctly (aliguori)
---
qemu-config.c | 14 ++
qemu-config.h |1 +
qemu-options.hx | 10 ++
vl.c| 38 ++
4 files changed, 55 insertions(+), 8 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 6700de0..c05ffbc 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -362,6 +362,19 @@ static QemuOptsList qemu_global_opts = {
},
};
+QemuOptsList qemu_sandbox_opts = {
+.name = "sandbox",
+.implied_opt_name = "enable",
+.head = QTAILQ_HEAD_INITIALIZER(qemu_sandbox_opts.head),
+.desc = {
+{
+.name = "enable",
+.type = QEMU_OPT_BOOL,
+},
+{ /* end of list */ }
+},
+};
+
static QemuOptsList qemu_mon_opts = {
.name = "mon",
.implied_opt_name = "chardev",
@@ -645,6 +658,7 @@ static QemuOptsList *vm_config_groups[32] = {
&qemu_machine_opts,
&qemu_boot_opts,
&qemu_iscsi_opts,
+&qemu_sandbox_opts,
NULL,
};
diff --git a/qemu-config.h b/qemu-config.h
index 12ddf3e..5557562 100644
--- a/qemu-config.h
+++ b/qemu-config.h
@@ -6,6 +6,7 @@
extern QemuOptsList qemu_fsdev_opts;
extern QemuOptsList qemu_virtfs_opts;
extern QemuOptsList qemu_spice_opts;
+extern QemuOptsList qemu_sandbox_opts;
QemuOptsList *qemu_find_opts(const char *group);
QemuOptsList *qemu_find_opts_err(const char *group, Error **errp);
diff --git a/qemu-options.hx b/qemu-options.hx
index 6aeef6a..3c411c4 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2723,6 +2723,16 @@ STEXI
Old param mode (ARM only).
ETEXI
+DEF("sandbox", HAS_ARG, QEMU_OPTION_sandbox, \
+"-sandbox Enable seccomp mode 2 system call filter (default
'off').\n",
+QEMU_ARCH_ALL)
+STEXI
+@item -sandbox
+@findex -sandbox
+Enable Seccomp mode 2 system call filter. 'on' will enable syscall filtering
and 'off' will
+disable it. The default is 'off'.
+ETEXI
+
DEF("readconfig", HAS_ARG, QEMU_OPTION_readconfig,
"-readconfig \n", QEMU_ARCH_ALL)
STEXI
diff --git a/vl.c b/vl.c
index 1010248..124d30d 100644
--- a/vl.c
+++ b/vl.c
@@ -770,6 +770,26 @@ static int bt_parse(const char *opt)
return 1;
}
+static int parse_sandbox(QemuOpts *opts, void *opaque)
+{
+/* FIXME: change this to true for 1.3 */
+if (qemu_opt_get_bool(opts, "enable", false)) {
+#ifdef CONFIG_SECCOMP
+if (seccomp_start() < 0) {
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ "failed to install seccomp syscall filter in the
kernel");
+return -1;
+}
+#else
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ "sandboxing request but seccomp is not compiled into
this build");
+return -1;
+#endif
+}
+
+return 0;
+}
+
/***/
/* QEMU Block devices */
@@ -2349,14 +2369,6 @@ int main(int argc, char **argv, char **envp)
const char *trace_events = NULL;
const char *trace_file = NULL;
-#ifdef CONFIG_SECCOMP
-if (seccomp_start() < 0) {
-fprintf(stderr,
-"seccomp: failed to install syscall filter in the kernel\n");
-exit(1);
-}
-#endif
-
atexit(qemu_run_exit_notifiers);
error_set_progname(argv[0]);
@@ -3260,6 +3272,12 @@ int main(int argc, char **argv, char **envp)
case QEMU_OPTION_qtest_log:
qtest_log = optarg;
break;
+case QEMU_OPTION_sandbox:
+opts = qemu_opts_parse(qemu_find_opts("sandbox"), optarg, 1);
+if (!opts) {
+exit(0);
+}
+break;
default:
os_parse_cmd_args(popt->index, optarg);
}
@@ -3267,6 +3285,10 @@ int main(int argc, char **argv, char **envp)
}
loc_set_none();
+if (qemu_opts_foreach(qemu_find_opts("sandbox"), parse_sandbox, NULL, 0)) {
+exit(1);
+}
+
if (machine == NULL) {
fprintf(stderr, "No machine found.\n");
exit(1);
--
1.7.5.4
Re: [Qemu-devel] x86, nops settings result in kernel crash
Alan Cox writes: > On Thu, 16 Aug 2012 14:45:15 -0400 (EDT) > Tomas Racek wrote: > >> - Original Message - >> > On Thu, Aug 16, 2012 at 09:35:12AM -0400, Tomas Racek wrote: >> > > Hi, >> > > >> > > I am writing a file system test which I execute in qemu with kernel >> > > compiled from latest git sources and running it causes this error: >> > > >> > > https://bugzilla.kernel.org/show_bug.cgi?id=45971 >> > > >> > > It works with v3.5, so I ran git bisect which pointed me to: >> > > >> > > d6250a3f12edb3a86db9598ffeca3de8b4a219e9 x86, nops: Missing break >> > > resulting in incorrect selection on Intel >> > > >> > > To be quite honest, I don't understand this stuff much but I tried >> > > to do some debugging and I figured out (I hope) that the crash is >> > > caused by setting ideal_nops to p6_nops (k8_nops was used before >> > > the break statement was added). >> > >> > Maybe I overlooked it or maybe it was implied but did you try >> > reverting >> > the patch and rerunning your test? Does it work ok then? >> > >> >> Yes, if I remove the break statement (introduced by this commit), it works >> fine. > > What version of qemu is this - do we have qemu bug here I wonder. >From the cpuinfo, it's 0.15.1. That's old but not ancient. I took a brief look at the kernel code here. The default invocation of qemu presents an idealistic CPU with a very minimum feature bit set exposed. No processor has ever existed with this feature set. We do this in order to maintain compatibility when migration from Intel to AMD but also for legacy reasons. >From the report, using '-cpu host' solves the problem. '-cpu host' exposes most of the host CPUID to the guest. That said, QEMU really doesn't do anything differently depending on what feature bits are exposed to the guest. So my guess is that the odd combination of CPUID bits that are exposed to the guest is confusing the kernel. Can you post dmesg from the host kernel? Perhaps there's instruction emulation failing in the host KVM? That would manifest in strange behavior in the guest. Regards, Anthony Liguori > > Alan
Re: [Qemu-devel] commit da57febfed "qdev: give all devices a canonical path" broke usb_del
Michael Tokarev writes:
> On 08.08.2012 17:09, Michael Tokarev wrote:
> []
>> Something similar should be applied to 1.1-stable. FWIW, some
>> changes are not needed there.
>
> Cherry-pick to stable-1.1 removes the two unneeded hunks.
> This is what I plan to include into debian package. It
> fixes the original usb_del issue, and I didn't find new
> regressions so far - tried a few device_del and similar.
>
> Should it go to qemu/stable-1.1 as well?
>
> Thank you!
>
> /mjtAuthor: Paolo Bonzini
> Date: Wed Aug 8 14:39:11 2012 +0200
> Bug-Debian: http://bugs.debian.org/684282
> Comment: cherry-picked from qemu/master to stable-1.1 (mjt)
>
> qom: object_delete should unparent the object first
>
> object_deinit is only called when the reference count goes to zero,
> and yet tries to do an object_unparent. Now, object_unparent
> either does nothing or it will decrease the reference count.
> Because we know the reference count is zero, the object_unparent
> call in object_deinit is useless.
>
> Instead, we need to disconnect the object from its parent just
> before we remove the last reference apart from the parent's. This
> happens in object_delete. Once we do this, all calls to
> object_unparent peppered through QEMU can go away.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Michael Tokarev
>
> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
> index 0345490..585da4e 100644
> --- a/hw/acpi_piix4.c
> +++ b/hw/acpi_piix4.c
> @@ -299,7 +299,6 @@ static void acpi_piix_eject_slot(PIIX4PMState *s,
> unsigned slots)
> if (pc->no_hotplug) {
> slot_free = false;
> } else {
> -object_unparent(OBJECT(dev));
> qdev_free(qdev);
> }
> }
> diff --git a/hw/qdev.c b/hw/qdev.c
> index 6a8f6bd..9bb1c6b 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -240,7 +240,6 @@ void qbus_reset_all_fn(void *opaque)
> int qdev_simple_unplug_cb(DeviceState *dev)
> {
> /* just zap it */
> -object_unparent(OBJECT(dev));
> qdev_free(dev);
> return 0;
> }
> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
> index 0214f37..84221df 100644
> --- a/hw/xen_platform.c
> +++ b/hw/xen_platform.c
> @@ -87,9 +87,6 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
> {
> if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
> PCI_CLASS_NETWORK_ETHERNET) {
> -/* Until qdev_free includes a call to object_unparent, we call it
> here
> - */
> -object_unparent(&d->qdev.parent_obj);
> qdev_free(&d->qdev);
> }
> }
> diff --git a/qom/object.c b/qom/object.c
> index 6f839ad..58dd886 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -347,8 +347,6 @@ static void object_deinit(Object *obj, TypeImpl *type)
> if (type_has_parent(type)) {
> object_deinit(obj, type_get_parent(type));
> }
> -
> -object_unparent(obj);
> }
>
> void object_finalize(void *data)
> @@ -385,8 +383,9 @@ Object *object_new(const char *typename)
>
> void object_delete(Object *obj)
> {
> +object_unparent(obj);
> +g_assert(obj->ref == 1);
> object_unref(obj);
> -g_assert(obj->ref == 0);
> g_free(obj);
> }
This won't work with composition. object_delete() is never called for
child<> objects.
Regards,
Anthony Liguori
>
Re: [Qemu-devel] [PATCH 1/5] move qemu_irq typedef out of cpu-common.h
Blue Swirl writes:
> On Mon, Aug 20, 2012 at 11:13 AM, Igor Mammedov wrote:
>> On Mon, 20 Aug 2012 06:41:04 +0200
>> Stefan Weil wrote:
>>
>>> Am 20.08.2012 01:39, schrieb Igor Mammedov:
>>> > it's necessary for making CPU child of DEVICE without
>>> > causing circular header deps.
>>> >
>>> > Signed-off-by: Igor Mammedov
>>> > ---
>>> > hw/arm-misc.h |1 +
>>> > hw/bt.h |2 ++
>>> > hw/devices.h |2 ++
>>> > hw/irq.h |2 ++
>>> > hw/omap.h |1 +
>>> > hw/soc_dma.h |1 +
>>> > hw/xen.h |1 +
>>> > qemu-common.h |1 -
>>> > sysemu.h |1 +
>>> > 9 files changed, 11 insertions(+), 1 deletions(-)
>>> >
>>> > diff --git a/hw/arm-misc.h b/hw/arm-misc.h
>>> > index bdd8fec..b13aa59 100644
>>> > --- a/hw/arm-misc.h
>>> > +++ b/hw/arm-misc.h
>>> > @@ -12,6 +12,7 @@
>>> > #define ARM_MISC_H 1
>>> >
>>> > #include "memory.h"
>>> > +#include "hw/irq.h"
>>> >
>>> > /* The CPU is also modeled as an interrupt controller. */
>>> > #define ARM_PIC_CPU_IRQ 0
>>> > diff --git a/hw/bt.h b/hw/bt.h
>>> > index a48b8d4..ebf6a37 100644
>>> > --- a/hw/bt.h
>>> > +++ b/hw/bt.h
>>> > @@ -23,6 +23,8 @@
>>> >* along with this program; if not, see <http://www.gnu.org/licenses/>.
>>> >*/
>>> >
>>> > +#include "hw/irq.h"
>>> > +
>>> > /* BD Address */
>>> > typedef struct {
>>> > uint8_t b[6];
>>> > diff --git a/hw/devices.h b/hw/devices.h
>>> > index 1a55c1e..c60bcab 100644
>>> > --- a/hw/devices.h
>>> > +++ b/hw/devices.h
>>> > @@ -1,6 +1,8 @@
>>> > #ifndef QEMU_DEVICES_H
>>> > #define QEMU_DEVICES_H
>>> >
>>> > +#include "hw/irq.h"
>>> > +
>>> > /* ??? Not all users of this file can include cpu-common.h. */
>>> > struct MemoryRegion;
>>> >
>>> > diff --git a/hw/irq.h b/hw/irq.h
>>> > index 56c55f0..1339a3a 100644
>>> > --- a/hw/irq.h
>>> > +++ b/hw/irq.h
>>> > @@ -3,6 +3,8 @@
>>> >
>>> > /* Generic IRQ/GPIO pin infrastructure. */
>>> >
>>> > +typedef struct IRQState *qemu_irq;
>>> > +
>>> > typedef void (*qemu_irq_handler)(void *opaque, int n, int level);
>>> >
>>> > void qemu_set_irq(qemu_irq irq, int level);
>>> > diff --git a/hw/omap.h b/hw/omap.h
>>> > index 413851b..8b08462 100644
>>> > --- a/hw/omap.h
>>> > +++ b/hw/omap.h
>>> > @@ -19,6 +19,7 @@
>>> > #ifndef hw_omap_h
>>> > #include "memory.h"
>>> > # define hw_omap_h"omap.h"
>>> > +#include "hw/irq.h"
>>> >
>>> > # define OMAP_EMIFS_BASE 0x
>>> > # define OMAP2_Q0_BASE0x
>>> > diff --git a/hw/soc_dma.h b/hw/soc_dma.h
>>> > index 904b26c..e386ace 100644
>>> > --- a/hw/soc_dma.h
>>> > +++ b/hw/soc_dma.h
>>> > @@ -19,6 +19,7 @@
>>> >*/
>>> >
>>> > #include "memory.h"
>>> > +#include "hw/irq.h"
>>> >
>>> > struct soc_dma_s;
>>> > struct soc_dma_ch_s;
>>> > diff --git a/hw/xen.h b/hw/xen.h
>>> > index e5926b7..ff11dfd 100644
>>> > --- a/hw/xen.h
>>> > +++ b/hw/xen.h
>>> > @@ -8,6 +8,7 @@
>>> >*/
>>> > #include
>>> >
>>> > +#include "hw/irq.h"
>>> > #include "qemu-common.h"
>>> >
>>> > /* xen-machine.c */
>>> > diff --git a/qemu-common.h b/qemu-common.h
>>> > index e5c2bcd..6677a30 100644
>>> > --- a/qemu-common.h
>>> > +++ b/qemu-common.h
>>> > @@ -273,7 +273,6 @@ typedef struct PCIEPort PCIEPort;
>>> > typedef struct PCIESlot PCIESlot;
>>> > typedef struct MSIMessage MSIMessage;
>>> > typedef struct SerialState SerialState;
>>> > -typedef struct IRQState *qemu_irq;
>>> > typedef struct PCMCIACardState PCMCIACardState;
>>> > typedef struct MouseTransformInfo MouseTransformInfo;
>>> > typedef struct uWireSlave uWireSlave;
>>>
>>> Just move the declaration of qemu_irq to the beginning of qemu-common.h
>>> and leave the rest of files untouched. That also fixes the circular
>>> dependency.
>>>
>>> I already have a patch that does this, so you can integrate it in your
>>> series
>>> instead of this one.
>> No doubt it's more simpler way, but IMHO It's more of a hack than fixing
>> problem.
>> It works for now but doesn't alleviate problem with header nightmare in qemu,
>> where everything is included in qemu-common.h and everything includes it as
>> well.
>>
>> Any way if majority prefer simple move, I'll drop this patch in favor of
>> yours.
>
> I like Igor's approach more.
Ack.
We should move away from dumping ground includes like qemu-common in
favor of meaningful headers that are explicitly included where needed.
Regards,
Anthony Liguori
>
>>
>>>
>>>
>>> > diff --git a/sysemu.h b/sysemu.h
>>> > index 65552ac..f765821 100644
>>> > --- a/sysemu.h
>>> > +++ b/sysemu.h
>>> > @@ -9,6 +9,7 @@
>>> > #include "qapi-types.h"
>>> > #include "notify.h"
>>> > #include "main-loop.h"
>>> > +#include "hw/irq.h"
>>> >
>>> > /* vl.c */
>>> >
>>>
>>
>>
>> --
>> Regards,
>> Igor
Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size
"Daniel P. Berrange" writes:
> From: "Daniel P. Berrange"
>
> Add a 'query-target' QAPI command to allow management applications
> to determine what target architecture a QEMU binary is emulating
> without having to parse the binary name or -help output
>
> $ qmp-shell -p /tmp/qemu
> (QEMU) query-target
> { u'return': { u'arch': u'x86_64', u'bits': 64}}
"bits" is really ambiguous. What it means in QEMU (specifically the
value you are returning) is probably not what you expect it to mean.
We're going to most likely fix TARGET_PHYS_ADDR_BITS to 64 real soon.
Why did you include this field? What information are you looking to get
from QEMU and what decisions do you plan to make with it?
Regards,
Anthony Liguori
>
> Signed-off-by: Daniel P. Berrange
> ---
> arch_init.c | 11 +++
> qapi-schema.json | 25 +
> qmp-commands.hx | 5 +
> 3 files changed, 41 insertions(+)
>
> diff --git a/arch_init.c b/arch_init.c
> index 9b46bfc..095672d 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -1080,3 +1080,14 @@ int xen_available(void)
> return 0;
> #endif
> }
> +
> +
> +TargetInfo *qmp_query_target(Error **errp)
> +{
> +TargetInfo *info = g_malloc0(sizeof(*info));
> +
> +info->arch = g_strdup(TARGET_ARCH);
> +info->bits = TARGET_PHYS_ADDR_BITS;
> +
> +return info;
> +}
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 3d2b2d1..f0e3fe0 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -2454,3 +2454,28 @@
> #
> ##
> { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
> +
> +##
> +# @TargetInfo:
> +#
> +# Information describing the QEMU target.
> +#
> +# @arch: the name of the target architecture (eg "x86_64", "i686", etc)
> +#
> +# @bits: number of bits in physical address (eg 32 or 64)
> +#
> +# Since: 1.2.0
> +##
> +{ 'type': 'TargetInfo',
> + 'data': { 'arch': 'str', 'bits': 'int' } }
> +
> +##
> +# @query-target:
> +#
> +# Return information about the target for this QEMU
> +#
> +# Returns: TargetInfo
> +#
> +# Since: 1.2.0
> +##
> +{ 'command': 'query-target', 'returns': 'TargetInfo' }
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index 2ce4ce6..00d798f 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -2509,3 +2509,8 @@ EQMP
> .mhandler.cmd_new = qmp_marshal_input_query_cpu_definitions,
> },
>
> +{
> +.name = "query-target",
> +.args_type = "",
> +.mhandler.cmd_new = qmp_marshal_input_query_target,
> +},
> --
> 1.7.11.2
Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size
"Daniel P. Berrange" writes:
> On Mon, Aug 20, 2012 at 04:48:24PM -0500, Anthony Liguori wrote:
>> "Daniel P. Berrange" writes:
>>
>> > From: "Daniel P. Berrange"
>> >
>> > Add a 'query-target' QAPI command to allow management applications
>> > to determine what target architecture a QEMU binary is emulating
>> > without having to parse the binary name or -help output
>> >
>> > $ qmp-shell -p /tmp/qemu
>> > (QEMU) query-target
>> > { u'return': { u'arch': u'x86_64', u'bits': 64}}
>>
>> "bits" is really ambiguous. What it means in QEMU (specifically the
>> value you are returning) is probably not what you expect it to mean.
>
> My intent was to indicate the pointer word size for the architecture.
> eg 64 for x86_64, ppc64, etc, and 32 and i686, ppc, etc. Probably
> should have called it 'wordsize' or something like that
So this is physical address size which doesn't necessarily correspond to
whether you can run a "64-bit" OS or not. As Peter mentioned, i386 can
have a larger physical address size even though it's limited to 32-bit
guests.
We really don't need to use a physical address size < 64-bit anymore.
It's just a matter of time before someone comes in and fixes
TARGET_PHYS_ADDR_BITS to 64 which ought to significantly reduce the
build time since we don't need to duplicate objects anymore.
So yeah, removing 'bits' is probably a good idea.
> # virsh capabilities
> snip...
>
> hvm
>
> 32
> /bin/qemu-system-arm
> ...
>
> Currently we just have a table of arch name -> wordsize mapping
> data in libvirt. I figured if I was adding a 'query-target' command
> to QEMU, we might as well include this info too. It is not critical
> though if you'd rather we omitted it though.
Does anyone actually use wordsize that libvirt reports? What decisions
are made with that information?
I'd much rather QEMU provide this kind of information to libvirt but
understanding how it's used is important to figure out what to expose.
Regards,
Anthony Liguori
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] Ping 1.2 PATCH "eventfd: making it thread safe" (was Re: [PATCH v2 1/3] net: asynchronous send/receive infrastructure for net/socket.c)
Paolo Bonzini writes: > Il 21/08/2012 18:39, ronnie sahlberg ha scritto: >> In >> net_socket_update_fd_handler() >> >> shouldnt you call qemu_notify_event() if any of the handlers have >> changed from NULL to non-NULL ? >> or else it might take a while before the change takes effect. > > Why haven't we applied yet the patch to do that unconditionally? > > http://permalink.gmane.org/gmane.comp.emulators.qemu/162828 Can you ping the actual patch... Gmane seems to be down right now. Regards, Anthony Liguori > > Paolo
Re: [Qemu-devel] commit da57febfed "qdev: give all devices a canonical path" broke usb_del
Paolo Bonzini writes:
> Il 20/08/2012 19:58, Anthony Liguori ha scritto:
>> Michael Tokarev writes:
>>
>>> On 08.08.2012 17:09, Michael Tokarev wrote:
>>> []
>>>> Something similar should be applied to 1.1-stable. FWIW, some
>>>> changes are not needed there.
>>>
>>> Cherry-pick to stable-1.1 removes the two unneeded hunks.
>>> This is what I plan to include into debian package. It
>>> fixes the original usb_del issue, and I didn't find new
>>> regressions so far - tried a few device_del and similar.
>>>
>>> Should it go to qemu/stable-1.1 as well?
>>>
>>> Thank you!
>>>
>>> /mjtAuthor: Paolo Bonzini
>>> Date: Wed Aug 8 14:39:11 2012 +0200
>>> Bug-Debian: http://bugs.debian.org/684282
>>> Comment: cherry-picked from qemu/master to stable-1.1 (mjt)
>>>
>>> qom: object_delete should unparent the object first
>>>
>>> object_deinit is only called when the reference count goes to zero,
>>> and yet tries to do an object_unparent. Now, object_unparent
>>> either does nothing or it will decrease the reference count.
>>> Because we know the reference count is zero, the object_unparent
>>> call in object_deinit is useless.
>>>
>>> Instead, we need to disconnect the object from its parent just
>>> before we remove the last reference apart from the parent's. This
>>> happens in object_delete. Once we do this, all calls to
>>> object_unparent peppered through QEMU can go away.
>>>
>>> Signed-off-by: Paolo Bonzini
>>> Signed-off-by: Michael Tokarev
>>>
>>> diff --git a/hw/acpi_piix4.c b/hw/acpi_piix4.c
>>> index 0345490..585da4e 100644
>>> --- a/hw/acpi_piix4.c
>>> +++ b/hw/acpi_piix4.c
>>> @@ -299,7 +299,6 @@ static void acpi_piix_eject_slot(PIIX4PMState *s,
>>> unsigned slots)
>>> if (pc->no_hotplug) {
>>> slot_free = false;
>>> } else {
>>> -object_unparent(OBJECT(dev));
>>> qdev_free(qdev);
>>> }
>>> }
>>> diff --git a/hw/qdev.c b/hw/qdev.c
>>> index 6a8f6bd..9bb1c6b 100644
>>> --- a/hw/qdev.c
>>> +++ b/hw/qdev.c
>>> @@ -240,7 +240,6 @@ void qbus_reset_all_fn(void *opaque)
>>> int qdev_simple_unplug_cb(DeviceState *dev)
>>> {
>>> /* just zap it */
>>> -object_unparent(OBJECT(dev));
>>> qdev_free(dev);
>>> return 0;
>>> }
>>> diff --git a/hw/xen_platform.c b/hw/xen_platform.c
>>> index 0214f37..84221df 100644
>>> --- a/hw/xen_platform.c
>>> +++ b/hw/xen_platform.c
>>> @@ -87,9 +87,6 @@ static void unplug_nic(PCIBus *b, PCIDevice *d)
>>> {
>>> if (pci_get_word(d->config + PCI_CLASS_DEVICE) ==
>>> PCI_CLASS_NETWORK_ETHERNET) {
>>> -/* Until qdev_free includes a call to object_unparent, we call it
>>> here
>>> - */
>>> -object_unparent(&d->qdev.parent_obj);
>>> qdev_free(&d->qdev);
>>> }
>>> }
>>> diff --git a/qom/object.c b/qom/object.c
>>> index 6f839ad..58dd886 100644
>>> --- a/qom/object.c
>>> +++ b/qom/object.c
>>> @@ -347,8 +347,6 @@ static void object_deinit(Object *obj, TypeImpl *type)
>>> if (type_has_parent(type)) {
>>> object_deinit(obj, type_get_parent(type));
>>> }
>>> -
>>> -object_unparent(obj);
>>> }
>>>
>>> void object_finalize(void *data)
>>> @@ -385,8 +383,9 @@ Object *object_new(const char *typename)
>>>
>>> void object_delete(Object *obj)
>>> {
>>> +object_unparent(obj);
>>> +g_assert(obj->ref == 1);
>>> object_unref(obj);
>>> -g_assert(obj->ref == 0);
>>> g_free(obj);
>>> }
>>
>> This won't work with composition. object_delete() is never called for
>> child<> objects.
>
> For non-heap-allocated children, their last ref will go away when the
> parent's child<> property is eliminated. This will remove the last
> reference and call object_finalize (which will take care of multiple
> levels of compositions).
>
> The same holds for heap-allocated children, but indeed you will leak the
> memory for the object because object_delete is not called. However this
> is already the case, the patch is not introducing a regression.
Ok, can you submit as a top level patch and I'll apply it for 1.2?
Regards,
Anthony Liguori
>
> Paolo
Re: [Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size
"Daniel P. Berrange" writes:
> On Tue, Aug 21, 2012 at 09:53:55AM -0300, Luiz Capitulino wrote:
>> On Tue, 21 Aug 2012 11:07:50 +0100
>> "Daniel P. Berrange" wrote:
>>
>> > On Mon, Aug 20, 2012 at 04:02:39PM -0300, Luiz Capitulino wrote:
>> > > On Mon, 20 Aug 2012 15:31:38 +0100
>> > > "Daniel P. Berrange" wrote:
>> > >
>> > > > From: "Daniel P. Berrange"
>> > > >
>> > > > Add a 'query-target' QAPI command to allow management applications
>> > > > to determine what target architecture a QEMU binary is emulating
>> > > > without having to parse the binary name or -help output
>> > > >
>> > > > $ qmp-shell -p /tmp/qemu
>> > > > (QEMU) query-target
>> > > > { u'return': { u'arch': u'x86_64', u'bits': 64}}
>> > > >
>> > > > Signed-off-by: Daniel P. Berrange
>> > > > ---
>> > > > arch_init.c | 11 +++
>> > > > qapi-schema.json | 25 +
>> > > > qmp-commands.hx | 5 +
>> > > > 3 files changed, 41 insertions(+)
>> > > >
>> > > > diff --git a/arch_init.c b/arch_init.c
>> > > > index 9b46bfc..095672d 100644
>> > > > --- a/arch_init.c
>> > > > +++ b/arch_init.c
>> > > > @@ -1080,3 +1080,14 @@ int xen_available(void)
>> > > > return 0;
>> > > > #endif
>> > > > }
>> > > > +
>> > > > +
>> > > > +TargetInfo *qmp_query_target(Error **errp)
>> > > > +{
>> > > > +TargetInfo *info = g_malloc0(sizeof(*info));
>> > > > +
>> > > > +info->arch = g_strdup(TARGET_ARCH);
>> > > > +info->bits = TARGET_PHYS_ADDR_BITS;
>> > > > +
>> > > > +return info;
>> > > > +}
>> > > > diff --git a/qapi-schema.json b/qapi-schema.json
>> > > > index 3d2b2d1..f0e3fe0 100644
>> > > > --- a/qapi-schema.json
>> > > > +++ b/qapi-schema.json
>> > > > @@ -2454,3 +2454,28 @@
>> > > > #
>> > > > ##
>> > > > { 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
>> > > > +
>> > > > +##
>> > > > +# @TargetInfo:
>> > > > +#
>> > > > +# Information describing the QEMU target.
>> > > > +#
>> > > > +# @arch: the name of the target architecture (eg "x86_64", "i686",
>> > > > etc)
>> > >
>> > > Should be an enum, otherwise looks good.
>> >
>> > Really ? It feels a little bit odd to make this an enum IMHO.
>>
>> I don't think it's odd. We should avoid using free-form strings when
>> the set of possible values a command returns is limited and known.
>>
>> The only small issue I see though, is that TARGET_ARCH is defined in
>> configure, so you'll have to add something like CONFIG_TARGET_ENUM there too
>
> Well the (slightly inefficient) way is to just iterate over the enum
> strings until you find the matching index. Not a good idea for large
> enums, but I figure it'd be acceptable for the small number of arches.
We can create a new CONFIG_ #define that gets set directly to the
enumerator value. No need for string comparison.
Regards,
Anthony Liguori
>
> Daniel
> --
> |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] For 1.2: Re: [PATCH 3/8] migration: move total_time from ram stats to migration info
Eric Blake writes:
> On 08/18/2012 05:17 AM, Juan Quintela wrote:
>> Signed-off-by: Juan Quintela
>> ---
>> hmp.c| 4 ++--
>> migration.c | 6 +++---
>> qapi-schema.json | 14 +++---
>> qmp-commands.hx | 6 +++---
>> 4 files changed, 15 insertions(+), 15 deletions(-)
>>
>
>> +++ b/qapi-schema.json
>> @@ -290,10 +290,6 @@
>> #
>> # @total: total amount of bytes involved in the migration process
>> #
>> -# @total-time: total amount of ms since migration started. If
>> -#migration has ended, it returns the total migration
>> -#time. (since 1.2)
>> -#
>> # @duplicate: number of duplicate pages (since 1.2)
>> #
>> # @normal : number of normal pages (since 1.2)
>> @@ -304,8 +300,7 @@
>> ##
>> { 'type': 'MigrationStats',
>>'data': {'transferred': 'int', 'remaining': 'int', 'total': 'int' ,
>> - 'total-time': 'int', 'duplicate': 'int', 'normal': 'int',
>> - 'normal-bytes': 'int' } }
>> + 'duplicate': 'int', 'normal': 'int', 'normal-bytes': 'int' } }
>>
>> ##
>> # @XBZRLECacheStats
>> @@ -350,12 +345,17 @@
>> #migration statistics, only returned if XBZRLE feature is
>> on and
>> #status is 'active' or 'completed' (since 1.2)
>> #
>> +# @total-time: total amount of milliseconds since migration started.
>> +#If migration has ended, it returns the total migration
>> +#time. (since 1.2)
>> +#
>> # Since: 0.14.0
>> ##
>> { 'type': 'MigrationInfo',
>>'data': {'*status': 'str', '*ram': 'MigrationStats',
>> '*disk': 'MigrationStats',
>> - '*xbzrle-cache': 'XBZRLECacheStats'} }
>> + '*xbzrle-cache': 'XBZRLECacheStats',
>> + 'total-time': 'int'} }
>
> Anthony - are you planning on taking this series for 1.2?
No. This is a new feature and we're past freeze.
> If we don't
> get this patch in on time, then taking this for 1.3 would result in
> changing released QMP interface (right now, there has been no release
> with the field in the wrong type).
Ack. We need to preserve compat with the 1.2 interface.
Regards,
Anthony Liguori
>
> --
> Eric Blake ebl...@redhat.com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
[Qemu-devel] [PATCH] qapi: add 'query-target' command to return target arch/bit size (v2)
From: "Daniel P. Berrange"
Add a 'query-target' QAPI command to allow management applications
to determine what target architecture a QEMU binary is emulating
without having to parse the binary name or -help output
$ qmp-shell -p /tmp/qemu
(QEMU) query-target
{ u'return': { u'arch': u'x86_64' }}
Signed-off-by: Daniel P. Berrange
Signed-off-by: Anthony Liguori
---
v1 -> v2 (aliguori)
- remove 'bits' field
- switch command to return an enum
---
arch_init.c | 11 +++
configure|7 ++-
qapi-schema.json | 39 +++
qmp-commands.hx |5 +
4 files changed, 61 insertions(+), 1 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 9b46bfc..5a1173e 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -44,6 +44,7 @@
#include "exec-memory.h"
#include "hw/pcspk.h"
#include "qemu/page_cache.h"
+#include "qmp-commands.h"
#ifdef DEBUG_ARCH_INIT
#define DPRINTF(fmt, ...) \
@@ -1080,3 +1081,13 @@ int xen_available(void)
return 0;
#endif
}
+
+
+TargetInfo *qmp_query_target(Error **errp)
+{
+TargetInfo *info = g_malloc0(sizeof(*info));
+
+info->arch = TARGET_TYPE;
+
+return info;
+}
diff --git a/configure b/configure
index 60d266f..d97fd81 100755
--- a/configure
+++ b/configure
@@ -3834,14 +3834,19 @@ case "$target_arch2" in
;;
esac
+upper() {
+echo "$@"| LC_ALL=C tr '[a-z]' '[A-Z]'
+}
+
echo "TARGET_SHORT_ALIGNMENT=$target_short_alignment" >> $config_target_mak
echo "TARGET_INT_ALIGNMENT=$target_int_alignment" >> $config_target_mak
echo "TARGET_LONG_ALIGNMENT=$target_long_alignment" >> $config_target_mak
echo "TARGET_LLONG_ALIGNMENT=$target_llong_alignment" >> $config_target_mak
echo "TARGET_ARCH=$TARGET_ARCH" >> $config_target_mak
-target_arch_name="`echo $TARGET_ARCH | LC_ALL=C tr '[a-z]' '[A-Z]'`"
+target_arch_name="`upper $TARGET_ARCH`"
echo "TARGET_$target_arch_name=y" >> $config_target_mak
echo "TARGET_ARCH2=$target_arch2" >> $config_target_mak
+echo "TARGET_TYPE=TARGET_TYPE_`upper $target_arch2`" >> $config_target_mak
echo "TARGET_BASE_ARCH=$TARGET_BASE_ARCH" >> $config_target_mak
if [ "$TARGET_ABI_DIR" = "" ]; then
TARGET_ABI_DIR=$TARGET_ARCH
diff --git a/qapi-schema.json b/qapi-schema.json
index 3d2b2d1..72b3c4d 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2454,3 +2454,42 @@
#
##
{ 'command': 'query-fdsets', 'returns': ['FdsetInfo'] }
+
+##
+# @TargetType
+#
+# Target CPU emulation type
+#
+# These parameters correspond to the softmmu binary CPU name that is currently
+# running.
+#
+# Since: 1.2.0
+##
+{ 'enum': 'TargetType',
+ 'data': [ 'alpha', 'arm', 'cris', 'i386', 'lm32', 'm68k', 'microblazeel',
+'microblaze', 'mips64el', 'mips64', 'mipsel', 'mips', 'or32',
+'ppc64', 'ppcemb', 'ppc', 's390x', 'sh4eb', 'sh4', 'sparc64',
+'sparc', 'unicore32', 'x86_64', 'xtensaeb', 'xtensa' ] }
+
+##
+# @TargetInfo:
+#
+# Information describing the QEMU target.
+#
+# @arch: the target architecture (eg "x86_64", "i386", etc)
+#
+# Since: 1.2.0
+##
+{ 'type': 'TargetInfo',
+ 'data': { 'arch': 'TargetType' } }
+
+##
+# @query-target:
+#
+# Return information about the target for this QEMU
+#
+# Returns: TargetInfo
+#
+# Since: 1.2.0
+##
+{ 'command': 'query-target', 'returns': 'TargetInfo' }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 2ce4ce6..00d798f 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -2509,3 +2509,8 @@ EQMP
.mhandler.cmd_new = qmp_marshal_input_query_cpu_definitions,
},
+{
+.name = "query-target",
+.args_type = "",
+.mhandler.cmd_new = qmp_marshal_input_query_target,
+},
--
1.7.5.4
Re: [Qemu-devel] [PATCH] qom: removal of link property need to release its target
Paolo Bonzini writes:
> Il 22/08/2012 05:02, Liu Ping Fan ha scritto:
>> From: Liu Ping Fan
>>
>> Currently, link property's target is only managed by
>> object_set_link_property(). This will raise such issue that when
>> the property is finalized, its target has no opportunity to release.
>>
>> Fix this issue by introduce object_finalize_link_property()
>>
>> Signed-off-by: Liu Ping Fan
>
> Acked-by: Paolo Bonzini
This patch is correct but it uncovers a bigger problem. Short of
reworking most of the hotplug code, I can't find an easy fix.
The first problem is that with this patch, all links are unreferenced at
property removal. Right now, bus children are added as links but when
they are added, the link is already set (there is no explicit set).
This means that those links never get the extra reference.
We can fix this by adding an extra reference in add_link but this
creates yet another problem with hotplug. Specificially, qdev_free()
asserts that ref > 0 because there is now a reference being held by the
bus.
This is the same problem we have with object_unparent.
The key problem here is how unplug is implemented. Unplug wants to be
both synchronous and asynchronous.
I think we need to do the following:
1) Move object_unparent to qdev_device_del (the parent is added by
qdev_device_add so this is quite logical).
2) Make DeviceState::unplug *never* call qdev_free().
3) Add an "unplugged" NotifierList to DeviceState.
4) Change the various hotplug consumers to call qdev_set_parent_bus() to
NULL to unplug the device from the bus. Change qdev_set_parent_bus()
to allow this and remove the bus link and invoke the unplugged notifier.
5) Change qdev_device_del() to add a notifier to the object that calls
object_unparent() and object_unref.
6) Rename DeviceState::unplug to DeviceState::request_unplug
7) Take Ping Fan's patch + another patch to add a reference count in
object_property_add_link
Regards,
Anthony Liguori
>
> Paolo
>
>> ---
>> qom/object.c | 12 +++-
>> 1 files changed, 11 insertions(+), 1 deletions(-)
>>
>> diff --git a/qom/object.c b/qom/object.c
>> index a552be2..76b3d34 100644
>> --- a/qom/object.c
>> +++ b/qom/object.c
>> @@ -957,6 +957,16 @@ static void object_set_link_property(Object *obj,
>> Visitor *v, void *opaque,
>> }
>> }
>>
>> +static void object_finalize_link_property(Object *obj, const char *name,
>> + void *opaque)
>> +{
>> +Object **child = opaque;
>> +
>> +if (*child != NULL) {
>> +object_unref(*child);
>> +}
>> +}
>> +
>> void object_property_add_link(Object *obj, const char *name,
>>const char *type, Object **child,
>>Error **errp)
>> @@ -968,7 +978,7 @@ void object_property_add_link(Object *obj, const char
>> *name,
>> object_property_add(obj, name, full_type,
>> object_get_link_property,
>> object_set_link_property,
>> -NULL, child, errp);
>> +object_finalize_link_property, child, errp);
>>
>> g_free(full_type);
>> }
>>
