[Qemu-devel] [PATCH] nsis: Improved support for parallel installation of 32 and 64 bit code
32 and 64 bit variants of QEMU already had different default installation directories, but used a common registry key for saving the choosen directory. This is confusing for users who want to install both variants, so fix it by using different registry keys. Signed-off-by: Stefan Weil --- qemu.nsi |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/qemu.nsi b/qemu.nsi index 1d57455..1418baf 100644 --- a/qemu.nsi +++ b/qemu.nsi @@ -60,7 +60,11 @@ InstallDir $PROGRAMFILES\qemu ; Registry key to check for directory (so if you install again, it will ; overwrite the old one automatically) -InstallDirRegKey HKLM "Software\qemu" "Install_Dir" +!ifdef W64 +InstallDirRegKey HKLM "Software\qemu64" "Install_Dir" +!else +InstallDirRegKey HKLM "Software\qemu32" "Install_Dir" +!endif ; Request administrator privileges for Windows Vista. RequestExecutionLevel admin -- 1.7.10.4
[Qemu-devel] [PATCH] block: Remove unused assignment (fixes warning from clang)
blockdev.c:1929:13: warning: Value stored to 'ret' is never read
ret = 0;
^ ~
Signed-off-by: Stefan Weil
---
blockdev.c |1 -
1 file changed, 1 deletion(-)
diff --git a/blockdev.c b/blockdev.c
index 8aa66a9..8c83f6f 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1926,7 +1926,6 @@ void qmp_drive_mirror(const char *device, const char
*target,
} else {
switch (mode) {
case NEW_IMAGE_MODE_EXISTING:
-ret = 0;
break;
case NEW_IMAGE_MODE_ABSOLUTE_PATHS:
/* create new image with backing file */
--
1.7.10.4
Re: [Qemu-devel] [RFC v5 0/5] hw/arm: add initial support for Canon DIGIC SoC: ping-ping-ping
On Fri, 20 Sep 2013 13:01:14 +0400 Antony Pavlov wrote: ping-ping-ping > On Fri, 13 Sep 2013 18:37:27 +0400 > Antony Pavlov wrote: > > ping-ping > > > On Sat, 7 Sep 2013 11:04:22 +0400 > > Antony Pavlov wrote: > > > > ping > > > [RFC v5 1/5] hw/arm: add very initial support for Canon DIGIC SoC > > > [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards support > > > [RFC v5 3/5] hw/arm/digic: add timer support > > > [RFC v5 4/5] hw/arm/digic: add UART support > > > [RFC v5 5/5] hw/arm/digic: add NOR ROM support > > > > > > Changes since v4: > > > 1. digic.h: parent_obj: change type Object -> DeviceState > > > 2. digic-uart: drop reg array > > > 3. digic_boards: fix K8P3215UQB comment > > > 4. Makefile: place digic stuff in own line > > > 5. drop cpu-qom.h inclusion > > > 6. digic.h: add private/public labels > > > 7. digic.h: fix guard macro > > > 8. move base address macros to digic.c > > > 9. fix header comments > > > > > > Changes since v3: > > > 1. fix typos and formatting > > > 2. digic-timer: drop DPRINTF > > > 3. digic-timer: fix DIGIC4_TIMER_BASE() macro > > > 4. digic.c: fix max timer device string > > > > > > Changes since v2: > > > 1. rebase over latest master; > > >* pass available size to object_initialize(). > > > 2. digic-uart: qemu_log: use LOG_UNIMP instead LOG_GUEST_ERROR; > > > 3. digic-boards: update rom image load code: introduce digic_load_rom(). > > > > > > Changes since v1: > > > 0. drop the "add ARM946E-S CPU" patch; > > > 1. convert to QOM, split DIGIC SoC code and board code > > > (thanks to Andreas Fa:rber, Peter Maydell and Peter Crosthwaite); > > > 2. fix digic-uart (many thanks to Peter Crosthwaite > > > for his comments); > > > 3. digic-boards: digic4_add_k8p3215uqb_rom(): update > > > rom image load code: use the '-bios' option. > > > > > > DIGIC is Canon Inc.'s name for a family of SoC > > > for digital cameras and camcorders. > > > > > > See http://en.wikipedia.org/wiki/DIGIC for details. > > > > > > There is no publicly available specification for > > > DIGIC chips. All information about DIGIC chip > > > internals is based on reverse engineering efforts > > > made by CHDK (http://chdk.wikia.com) and > > > Magic Lantern (http://www.magiclantern.fm) projects > > > contributors. > > > > > > Also this patch series adds initial support for Canon > > > PowerShot A1100 IS compact camera (it is my only camera > > > with connected UART interface). As the DIGIC-based cameras > > > differences mostly are unsignificant (e.g. RAM-size, > > > ROM type and size, GPIO usage) the other compact > > > and DSLR cameras support can be easely added. > > > > > > This DIGIC support patch series is inspired > > > by EOS QEMU from Magic Lantern project. > > > The main differences: > > > * EOS QEMU uses home-brew all-in-one monolith design; > > > this patch series uses conventional qemu object-centric design; > > > * EOS QEMU tries provide simplest emulation for most > > > controllers inside SoC to run Magic Lantern firmware; > > > this patch series provide more complete support > > > only for core devices to run barebox bootloader. > > > ** EOS QEMU does not support timer counting > > > (this patch series emulate 1 MHz counting); > > > ** EOS QEMU support DIGIC UART only for output > > > character to stderr; (this patch series emulate > > > introduces full blown UART interface); > > > ** EOS QEMU has incomplete ROM support; > > > (this patch series uses conventional qemu pflash). > > > > > > This initial DIGIC support can't be used to run > > > the original camera firmware, but it can successfully > > > run experimental version of barebox bootloader > > > (see http://www.barebox.org). > > > > > > The last sources of barebox for PowerShot A1100 can be > > > obtained here: > > > https://github.com/frantony/barebox/tree/next.digic.20130829 > > > > > > The precompiled ROM image usable with qemu can be > > > obtained here: > > > > > > https://github.com/frantony/barebox/blob/next.digic.20130829/canon-a1100-rom1.bin > > > > > > This ROM image (after "dancing bit" encoding) can be run on > > > real Canon A1100 camera. > > > > > > The short build instruction for __previous__ DIGIC barebox > > > version (it can be used with more recent sources too) can > > > be obtained here: > > > http://lists.infradead.org/pipermail/barebox/2013-August/016007.html > > > > > > -- > > Best regards, > > Antony Pavlov > > -- > Best regards, > Antony Pavlov -- -- Best regards, Antony Pavlov
Re: [Qemu-devel] [PATCH 1/6] kvm: Add KVM_GET_EMULATED_CPUID
On Fri, Sep 27, 2013 at 11:21:34AM -0300, Eduardo Habkost wrote: > The problem here is that "requested_features" doesn't include just > the explicit "+flag" flags, but any flag included in the CPU model > definition. See the "-cpu n270" example below. Oh, you mean if requested_features would contain a flag included from the CPU model definition - a flag which we haven't requested explicitly - and if kvm emulates that flag, then it will get enabled? Hmm. > It should, but your patch will make it stop failing because of MOVBE, as > now it can be emulated[1]. Right. > "enforce" makes sure all features are really being enabled. It makes > QEMU abort if there's any feature that can't be enabled on that host. Ok. > [1] Maybe one source of confusion is that the existing code have two > feature-filtering functions doing basically the same thing: > filter_features_for_kvm() and kvm_check_features_against_host(). That's Yes, and the first gets executed unconditionally and does the feature filtering, right after the second has run in the kvm_enabled() branch. > something we must clean up, and they should be unified. "enforce" should > become synonymous to "make sure filtered_features is all zeroes". This > way, libvirt can emulate what 'enforce" does while being able to collect > detailed error information (which is not easy to do if QEMU simply > aborts). Ok, maybe someone who's more knowledgeable with this code should do it - not me :) Also, there's another aspect, while we're here: now that QEMU emulates MOVBE with TCG too, how do we specify on the command line, which emulation should be used - kvm.ko or QEMU? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --
Re: [Qemu-devel] [RFC v5 0/5] hw/arm: add initial support for Canon DIGIC SoC: ping-ping-ping
On 28 September 2013 19:41, Antony Pavlov wrote: > On Fri, 20 Sep 2013 13:01:14 +0400 > Antony Pavlov wrote: > > ping-ping-ping Just FYI, I'm on holiday, but this is on the list for when I get back... -- PMM
Re: [Qemu-devel] Virtio Polling Mode
Hi Yaohui, Yes, there is a flag associated both with the used and the avail rings to disable notifications. This can be used to implement polling. There have been multiple research projects/papers that have experimented with polling. Regards, Anthony Liguori On Fri, Sep 27, 2013 at 1:56 PM, Hu Yaohui wrote: > Hi All, > I am wondering whether virtio has provided polling mode already. Instead > of sending a event from guest to host through eventfd on guest side and > inject an interrupt into guest on host side to notify each other? Could > both sides keep polling the Vring to communicate with each other? > Thanks for your time! > > Best Wishes, > Yaohui >
[Qemu-devel] ELVIS/ELI I/O acceleration code / Re: KVM call agenda for 2013-04-09
Stefan Hajnoczi wrote on 09/04/2013 06:13:47 PM: > From: Stefan Hajnoczi > To: Juan Quintela , > Cc: qemu-devel qemu-devel , KVM devel mailing > list > Date: 09/04/2013 06:13 PM > Subject: Re: [Qemu-devel] KVM call agenda for 2013-04-09 > Sent by: qemu-devel-bounces+abelg=il.ibm@nongnu.org > > Meeting notes on Abel's presentation: > > Aim: improve vhost scalability > > Shared vhost thread > == > Problem: Linux scheduler does not see state of virtqueues, cannot make > good scheduling decisions > Solution: Shared thread serves multiple VMs and therefore influences > "I/O scheduling" instead of kernel thread per vhost device > > Exitless communication > = > * Polling on host to notice guest vring updates without guest pio instruction >* Use CPU affinity to bind vcpus to separate cores and let polling > run on dedicated cores > * Existless Interrupt (ELI) or future hardware APIC virtualization > feature to inject virtual interrupts > without vmexit and EOI > > See paper for performance results (impressive numbers): > http://domino.research.ibm.com/library/cyberdig.nsf/papers/ > 479E3578ED05BFAC85257B4200427735/$File/h-0319.pdf > > Abel will publish rebased code on GitHub but does not have time to > upstream them. > > The next step: QEMU/KVM community can digest the paper + patches and > decide on ideas to upstream. It has been a while since this KVM call but the code for ELVIS and ELI is now available in github: https://github.com/abelg/virtual_io_acceleration/commits/ibm-io-acceleration-3.9-github Source-code contributors (in alphabetical order): Nadav Amit nadav.a...@gmail.com Muli Ben-Yehuda mu...@mulix.org Abel Gordon ab...@il.ibm.com Nadav Har'El n...@math.technion.ac.il Alex Landau landau.a...@gmail.com Each commit made in September 16th represents a separate and documented patch. Note this work is under development and more effort is required to make it upstream-ready. You are all welcome to join the upstreaming effort :) A short documentation can be found in the wiki page: https://github.com/abelg/virtual_io_acceleration/wiki/Virtual-I-O-acceleration-technologies-for-KVM Please note this work will be presented and discussed in the upcoming KVM forum (October 21-23, Edinburgh, UK) Regards, Abel.
Re: [Qemu-devel] Attaching PCI devices to the PCIe root complex
On Fri, Sep 27, 2013 at 07:06:44PM +0200, Markus Armbruster wrote: > Marcel Apfelbaum writes: > > > On Wed, 2013-09-25 at 10:01 +0300, Michael S. Tsirkin wrote: > >> On Tue, Sep 24, 2013 at 06:01:02AM -0400, Laine Stump wrote: > >> > When I added support for the Q35-based machinetypes to libvirt, I > >> > specifically prohibited attaching any PCI devices (with the exception of > >> > graphics controllers) to the PCIe root complex, > >> > >> That's wrong I think. Anything attached to RC is an integrated > >> endpoint, and these can be PCI devices. > > I couldn't find on PCIe spec any mention that "Root Complex Integrated > > EndPoint" > > must be PCIe. But, from spec 1.3.2.3: > > - A Root Complex Integrated Endpoint must not require I/O resources > > claimed through BAR(s). > > - A Root Complex Integrated Endpoint must not generate I/O Requests. > > - A Root Complex Integrated Endpoint is required to support MSI or > > MSI-X or both if an > > interrupt resource is requested. > > I suppose that this restriction can be removed for PCI devices that > > 1. Actually work when plugged in into RC Integrated EndPoint > > 2. Respond to the above limitations > > > >> > >> > and had planned to > >> > prevent attaching them to PCIe root ports (ioh3420 device) and PCIe > >> > downstream switch ports (xio-3130 device) as well. I did this because, > >> > even though qemu currently allows attaching a normal PCI device in any > >> > of these three places, the restriction exists for real hardware and I > >> > didn't see any guarantee that qemu wouldn't add the restriction in the > >> > future in order to more closely emulate real hardware. > >> > > >> > However, since I did that, I've learned that many of the qemu "pci" > >> > devices really should be considered as "pci or pcie". Gerd Hoffman lists > >> > some of these cases in a bug he filed against libvirt: > >> > > >> >https://bugzilla.redhat.com/show_bug.cgi?id=1003983 > >> > > >> > I would like to loosen up the restrictions in libvirt, but want to make > >> > sure that I don't allow something that could later be forbidden by qemu > >> > (thus creating a compatibility problem during upgrades). Beyond Gerd's > >> > specific requests to allow ehci, uhci, and hda controllers to attach to > >> > PCIe ports, are there any other devices that I specifically should or > >> > shouldn't allow? (I would rather be conservative in what I allow - it's > >> > easy to allow more things later, but nearly impossible to revoke > >> > permission once it's been allowed). > > For the moment I would not remove any restrictions, but only the ones > > requested and verified by somebody. > > > >> > >> IMO, we really need to grow an interface to query this kind of thing. > > Basically libvirt needs to know: > > 1. for (libvirt) controllers: what kind of devices can be plugged in > > 2. for devices (controller is also a device) > > - to which controllers can it be plugged in > > - does it support hot-plug? > > 3. implicit controllers of the machine types (q35 - "pcie-root", i440fx - > > "pci-root") > > All the above must be exported to libvirt > > > > Implementation options: > > 1. Add a compliance field on PCI/PCIe devices and controllers stating if it > > supports > >PCI/PCIe or both (and maybe hot-plug) > >- consider plug type + compliance to figure out whether a plug can go > > into a socket > > > > 2. Use Markus Armbruster idea of introducing a concept of "plug and > > sockets": > >- dividing the devices into adapters and plugs > >- adding sockets to bridges(buses?). > >In this way it would be clear which devices can connect to bridges > > This isn't actually my idea. It's how things are designed to work in > qdev, at least in my admittedly limited understanding of qdev. > > In traditional qdev, a device has exactly one plug (its "bus type", > shown by -device help), and it may have one ore more buses. Each bus > has a type, and you can plug a device only into a bus of the matching > type. This was too limiting, and is not how things work now. > > As far as I know, libvirt already understands that a device can only > plug into a matching bus. > > In my understanding of where we're headed with qdev, things are / will > become more general, yet stay really simple: > > * A device can have an arbitrary number of sockets and plugs. > > * Each socket / plug has a type. > > * A plug can go into a socket of the same type, and only there. > > Pretty straightforward generalization of traditional qdev. I wouldn't > expect libvirt to have serious trouble coping with it, as long as we > provide the necessary information on device models' plugs and sockets. > > In this framework, there's no such thing as a device model that can plug > either into a PCI or a PCIe socket. Makes sense to me, because there's > no such thing in the physical world, either. > Instead, and just like in the physical world, you have one separate > device variant per desir
Re: [Qemu-devel] [PATCH v2 0/7] smbios cleanup & nicer defaults for type 1
On Fri, Aug 16, 2013 at 03:18:27PM +0200, arm...@redhat.com wrote: > From: Markus Armbruster > > This gets rid of one of the last get_param_value() users, makes > multiple -smbios work sanely, cleans up the gross side effect in > qemu_uuid_parse(), and more. Topped off with a little feature in the > last patch. > > v2: Rebase, only last patch had conflicts I applied patch 1-5 on my tree, thanks everyone. > Markus Armbruster (7): > smbios: Normalize smbios_entry_add()'s error handling to exit(1) > smbios: Convert to QemuOpts > smbios: Improve diagnostics for conflicting entries > smbios: Make multiple -smbios type= accumulate sanely > smbios: Factor out smbios_maybe_add_str() > vl: Set current_machine early > smbios: Set system manufacturer, product & version by default > > arch_init.c| 9 +- > hw/i386/pc.c | 6 +- > hw/i386/pc_piix.c | 5 + > hw/i386/pc_q35.c | 3 + > hw/i386/smbios.c | 349 > - > include/hw/i386/pc.h | 1 + > include/hw/i386/smbios.h | 7 +- > include/sysemu/arch_init.h | 2 +- > include/sysemu/sysemu.h| 1 + > vl.c | 8 +- > 10 files changed, 276 insertions(+), 115 deletions(-) > > -- > 1.8.1.4 >
Re: [Qemu-devel] [PATCH v5 1/5] hpet: inverse polarity when pin above ISA_NUM_IRQS
On Thu, Sep 12, 2013 at 11:25:14AM +0800, Liu Ping Fan wrote:
> According to hpet spec, hpet irq is high active. But according to
> ICH spec, there is inversion before the input of ioapic. So the OS
> will expect low active on this IRQ line.
>(And this is observed on
> bare metal).
How does one test this on bare metal?
>
> We fold the emulation of this inversion inside the hpet logic.
>
> Signed-off-by: Liu Ping Fan
Doesn't this affect cross-version migration?
E.g. imagine that you migrate between systems
with/without this fix.
> ---
> hw/timer/hpet.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
> index fcd22ae..8429eb3 100644
> --- a/hw/timer/hpet.c
> +++ b/hw/timer/hpet.c
> @@ -198,13 +198,23 @@ static void update_irq(struct HPETTimer *timer, int set)
> if (!set || !timer_enabled(timer) || !hpet_enabled(timer->state)) {
> s->isr &= ~mask;
> if (!timer_fsb_route(timer)) {
> -qemu_irq_lower(s->irqs[route]);
> +/* fold the ICH PIRQ# pin's internal inversion logic into hpet */
> +if (route >= ISA_NUM_IRQS) {
> +qemu_irq_raise(s->irqs[route]);
> +} else {
> +qemu_irq_lower(s->irqs[route]);
> +}
> }
> } else if (timer_fsb_route(timer)) {
> stl_le_phys(timer->fsb >> 32, timer->fsb & 0x);
> } else if (timer->config & HPET_TN_TYPE_LEVEL) {
> s->isr |= mask;
> -qemu_irq_raise(s->irqs[route]);
> +/* fold the ICH PIRQ# pin's internal inversion logic into hpet */
> +if (route >= ISA_NUM_IRQS) {
> +qemu_irq_lower(s->irqs[route]);
> +} else {
> +qemu_irq_raise(s->irqs[route]);
> +}
> } else {
> s->isr &= ~mask;
> qemu_irq_pulse(s->irqs[route]);
> --
> 1.8.1.4
>
Re: [Qemu-devel] [PATCH v5 2/5] hpet: entitle more irq pins for hpet
On Thu, Sep 12, 2013 at 11:25:15AM +0800, Liu Ping Fan wrote:
> On PC, IRQ2/8 can be reserved for hpet timer 0/1. And pin 16~23
> of ioapic can be dynamically assigned to hpet as guest chooses.
> (Will enable them after introducing pc 1.6 compat)
>
> Signed-off-by: Liu Ping Fan
> ---
> hw/timer/hpet.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
> index 8429eb3..46903b9 100644
> --- a/hw/timer/hpet.c
> +++ b/hw/timer/hpet.c
> @@ -25,6 +25,7 @@
> */
>
> #include "hw/hw.h"
> +#include "hw/boards.h"
> #include "hw/i386/pc.h"
> #include "ui/console.h"
> #include "qemu/timer.h"
> @@ -42,6 +43,12 @@
>
> #define HPET_MSI_SUPPORT0
>
> +/* For bug compat, using only IRQ2. Soon it will be fixed as
> + * 0xff0104ULL, i.e using IRQ16~23, IRQ8 and IRQ2
So users are expected to stick a bitmask of legal
pins here?
I think that's a bit too much rope to give to users.
Don't you think?
> after
> + * introducing pc-1.6 compat.
> + */
> +#define HPET_TN_INT_CAP_DEFAULT 0x4ULL
> +
> #define TYPE_HPET "hpet"
> #define HPET(obj) OBJECT_CHECK(HPETState, (obj), TYPE_HPET)
>
> @@ -73,6 +80,7 @@ typedef struct HPETState {
> uint8_t rtc_irq_level;
> qemu_irq pit_enabled;
> uint8_t num_timers;
> +uint32_t intcap;
> HPETTimer timer[HPET_MAX_TIMERS];
>
> /* Memory-mapped, software visible registers */
> @@ -663,8 +671,8 @@ static void hpet_reset(DeviceState *d)
> if (s->flags & (1 << HPET_MSI_SUPPORT)) {
> timer->config |= HPET_TN_FSB_CAP;
> }
> -/* advertise availability of ioapic inti2 */
> -timer->config |= 0x0004ULL << 32;
> +/* advertise availability of ioapic int */
> +timer->config |= (uint64_t)s->intcap << 32;
> timer->period = 0ULL;
> timer->wrap_flag = 0;
> }
> @@ -753,6 +761,7 @@ static void hpet_realize(DeviceState *dev, Error **errp)
> static Property hpet_device_properties[] = {
> DEFINE_PROP_UINT8("timers", HPETState, num_timers, HPET_MIN_TIMERS),
> DEFINE_PROP_BIT("msi", HPETState, flags, HPET_MSI_SUPPORT, false),
> +DEFINE_PROP_UINT32("intcap", HPETState, intcap, HPET_TN_INT_CAP_DEFAULT),
> DEFINE_PROP_END_OF_LIST(),
> };
>
> --
> 1.8.1.4
>
Re: [Qemu-devel] [PATCH v2 2/7] smbios: Convert to QemuOpts
On Fri, Aug 16, 2013 at 03:18:29PM +0200, arm...@redhat.com wrote:
> From: Markus Armbruster
>
> So that it can be set in config file for -readconfig.
>
> This tightens parsing of -smbios, and makes it more consistent with
> other options: unknown parameters are rejected, numbers with trailing
> junk are rejected, when a parameter is given multiple times, last
> rather than first wins, ...
>
> Signed-off-by: Markus Armbruster
> Reviewed-by: Eric Blake
> ---
> arch_init.c| 4 +-
> hw/i386/smbios.c | 211
> -
> include/hw/i386/smbios.h | 4 +-
> include/sysemu/arch_init.h | 2 +-
> vl.c | 3 +-
> 5 files changed, 180 insertions(+), 44 deletions(-)
>
> diff --git a/arch_init.c b/arch_init.c
> index 1ddead0..96477fd 100644
> --- a/arch_init.c
> +++ b/arch_init.c
> @@ -1133,10 +1133,10 @@ void do_acpitable_option(const QemuOpts *opts)
> #endif
> }
>
> -void do_smbios_option(const char *optarg)
> +void do_smbios_option(QemuOpts *opts)
> {
> #ifdef TARGET_I386
> -smbios_entry_add(optarg);
> +smbios_entry_add(opts);
> #endif
> }
>
> diff --git a/hw/i386/smbios.c b/hw/i386/smbios.c
> index 0608aee..a113f8b 100644
> --- a/hw/i386/smbios.c
> +++ b/hw/i386/smbios.c
> @@ -2,9 +2,11 @@
> * SMBIOS Support
> *
> * Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
> + * Copyright (C) 2013 Red Hat, Inc.
> *
> * Authors:
> * Alex Williamson
> + * Markus Armbruster
> *
> * This work is licensed under the terms of the GNU GPL, version 2. See
> * the COPYING file in the top-level directory.
> @@ -13,6 +15,7 @@
> * GNU GPL, version 2 or (at your option) any later version.
> */
>
> +#include "qemu/config-file.h"
> #include "qemu/error-report.h"
> #include "sysemu/sysemu.h"
> #include "hw/i386/smbios.h"
> @@ -41,11 +44,100 @@ struct smbios_table {
> #define SMBIOS_FIELD_ENTRY 0
> #define SMBIOS_TABLE_ENTRY 1
>
> -
> static uint8_t *smbios_entries;
> static size_t smbios_entries_len;
> static int smbios_type4_count = 0;
>
> +static QemuOptsList qemu_smbios_opts = {
> +.name = "smbios",
> +.head = QTAILQ_HEAD_INITIALIZER(qemu_smbios_opts.head),
> +.desc = {
> +/*
> + * no elements => accept any params
> + * validation will happen later
> + */
> +{ /* end of list */ }
> +}
> +};
> +
> +static const QemuOptDesc qemu_smbios_file_opts[] = {
> +{
> +.name = "file",
> +.type = QEMU_OPT_STRING,
> +.help = "binary file containing an SMBIOS element",
> +},
> +{ /* end of list */ }
> +};
> +
> +static const QemuOptDesc qemu_smbios_type0_opts[] = {
> +{
> +.name = "type",
> +.type = QEMU_OPT_NUMBER,
> +.help = "SMBIOS element type",
> +},{
> +.name = "vendor",
> +.type = QEMU_OPT_STRING,
> +.help = "vendor name",
> +},{
> +.name = "version",
> +.type = QEMU_OPT_STRING,
> +.help = "version number",
> +},{
> +.name = "date",
> +.type = QEMU_OPT_STRING,
> +.help = "release date",
> +},{
> +.name = "release",
> +.type = QEMU_OPT_STRING,
> +.help = "revision number",
> +},
> +{ /* end of list */ }
> +};
> +
> +static const QemuOptDesc qemu_smbios_type1_opts[] = {
> +{
> +.name = "type",
> +.type = QEMU_OPT_NUMBER,
> +.help = "SMBIOS element type",
> +},{
> +.name = "manufacturer",
> +.type = QEMU_OPT_STRING,
> +.help = "manufacturer name",
> +},{
> +.name = "product",
> +.type = QEMU_OPT_STRING,
> +.help = "product name",
> +},{
> +.name = "version",
> +.type = QEMU_OPT_STRING,
> +.help = "version number",
> +},{
> +.name = "serial",
> +.type = QEMU_OPT_STRING,
> +.help = "serial number",
> +},{
> +.name = "uuid",
> +.type = QEMU_OPT_STRING,
> +.help = "UUID",
> +},{
> +.name = "sku",
> +.type = QEMU_OPT_STRING,
> +.help = "SKU number",
> +},{
> +.name = "family",
> +.type = QEMU_OPT_STRING,
> +.help = "family name",
> +},
> +{ /* end of list */ }
> +};
> +
> +static void smbios_register_config(void)
> +{
> +qemu_add_opts(&qemu_smbios_opts);
> +}
> +
> +machine_init(smbios_register_config);
> +
> static void smbios_validate_table(void)
> {
> if (smbios_type4_count && smbios_type4_count != smp_cpus) {
> @@ -124,23 +216,30 @@ void smbios_add_field(int type, int offset, const void
> *data, size_t len)
> cpu_to_le16(le16_to_cpu(*(uint16_t *)smbios_entries) + 1);
> }
>
> -static void smbios_build_type_0_fields(const char *t)
> +static void smbios_build_type_0_fields(QemuOpts *opts)
> {
> -char buf[1024];
> +const char *val;
> unsigned char major, minor;
>
> -if (get
[Qemu-devel] [PATCH] ahci: set ahci mode on reset
ATM we set AHCI mode on 1st GHC write.
Spec says we should set it on reset.
Signed-off-by: Michael S. Tsirkin
---
hw/ide/ahci.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index a71a4ca..a8be62c 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -1198,7 +1198,15 @@ void ahci_reset(AHCIState *s)
int i;
s->control_regs.irqstatus = 0;
-s->control_regs.ghc = 0;
+/* AHCI Enable (AE)
+ * The implementation of this bit is dependent upon the value of the
+ * CAP.SAM bit. If CAP.SAM is '0', then GHC.AE shall be read-write and
+ * shall have a reset value of '0'. If CAP.SAM is '1', then AE shall be
+ * read-only and shall have a reset value of '1'.
+ *
+ * We set HOST_CAP_AHCI so we must enable AHCI at reset.
+ */
+s->control_regs.ghc = HOST_CTL_AHCI_EN;
for (i = 0; i < s->ports; i++) {
pr = &s->dev[i].port_regs;
--
MST
Re: [Qemu-devel] [Xen-devel] Hvmloader: Add _STA for PCI hotplug slots
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Saturday, September 28, 2013 5:43 AM
> To: Gonglei (Arei); anthony.per...@citrix.com; Stefano Stabellini
> Cc: xen-de...@lists.xen.org; Hanweidong (Randy); Yanqiangjun; Luonengjun;
> qemu-devel@nongnu.org; Gaowei (UVP); Huangweidong (Hardware)
> Subject: Re: [Xen-devel] Hvmloader: Add _STA for PCI hotplug slots
>
> On Fri, Sep 27, 2013 at 06:29:20AM +, Gonglei (Arei) wrote:
> > Hi,
>
> Hey,
>
> (CCing Stefano and Anthony).
>
> >
> > In Xen platform, after using upstream qemu, the all of pci devices will show
> hotplug in the windows guest.
> > In this situation, the windows guest may occur blue screen when VM' user
> click the icon of VGA card for trying unplug VGA card.
> > However, we don't hope VM's user can do such dangerous operation, and
> showing all pci devices inside the guest OS is unfriendly.
> >
> > In addition, I find the traditional qemu have not this problem, and KVM
> > also.
> >
> > On the KVM platform, the seabios will read the RMV bits of pci slot
> > (according
> the 0xae08 I/O port register),
> > then modify the SSDT table.
> >
> > The key steps as follows:
> > In Seabios:
> > #define PCI_RMV_BASE 0xae0c// 0xae08 I/O port register
> > static void* build_ssdt(void)
> > {
> > ...
> > // build Device object for each slot
> > u32 rmvc_pcrm = inl(PCI_RMV_BASE);
> > ...
> > }
> >
> > In upstream Qemu, read 0xae0c I/O port register function:
> > static uint64_t pci_read(void *opaque, hwaddr addr, unsigned int size)
> > {
> > ...
> > case PCI_RMV_BASE - PCI_HOTPLUG_ADDR:
> > val = s->pci0_hotplug_enable;
> > break;
> > }
> > s->pci0_hotplug_enable is set by the follow function:
> >
> > static void piix4_update_hotplug(PIIX4PMState *s)
> > {
> > ...
> > s->pci0_hotplug_enable = ~0;
> > s->pci0_slot_device_present = 0;
> >
> > QTAILQ_FOREACH_SAFE(kid, &bus->children, sibling, next) {
> > DeviceState *qdev = kid->child;
> > PCIDevice *pdev = PCI_DEVICE(qdev);
> > PCIDeviceClass *pc = PCI_DEVICE_GET_CLASS(pdev);
> > int slot = PCI_SLOT(pdev->devfn);
> >
> > //setting by PCIDeviceClass *k->no_hotplug
> > if (pc->no_hotplug) {
> > s->pci0_hotplug_enable &= ~(1U << slot);
> > }
> >
> > s->pci0_slot_device_present |= (1U << slot);
> > }
> > }
> >
> > But, on the XEN platform, ACPI DSDT tables is produced by the hvmloader,
> > more details in this patch：
> >
> http://xen.1045712.n5.nabble.com/xen-unstable-hvmloader-acpi-dsdt-Fix-PCI-
> hotplug-with-the-new-qemu-xen-td4947152.html
> >
> > # Node ID 1a912ce93b506a185b54fd97986214e6eff8a0bc
> > # Parent 6bc03e22f921aadfa7e5cebe92100cb01377947d
> > hvmloader/acpi/dsdt: Fix PCI hotplug with the new qemu-xen.
>
> oddly enough you did not CC the author of said patch?
>
> I am doing that for you.
That's my mistake, thank you so much!
> >
> > The ACPI PIIX4 device in QEMU upstream as not the same behavior to
> > handle PCI hotplug. This patch introduce the necessary change to the
> > DSDT ACPI table to behave as expceted by the new QEMU.
> >
> > To switch to this new DSDT table version, there is a new option
> > --dm-version to mk_dsdt.
> >
> > Change are inspired by SeaBIOS DSDT source code.
> >
> > There is few things missing with the new QEMU:
> > - QEMU provide the plugged/unplugged status only per slot (and not
> > per func like qemu-xen-traditionnal.
> > - I did not include the _STA ACPI method that give the status of a
> > device (present, functionning properly) because qemu-xen does not
> > handle it.
> > - I did not include the _RMV method that say if the device can be
> > removed,
> > because the IO port of QEMU that give this status always return
> > true. In
> > SeaBIOS table, they have a specific _RMV method for VGA, ISA that
> > return
> > false. But I'm not sure that we can do the same in Xen.
> >
> >
> > now, I add the _STA method, return the different value according the 0xae08
> I/O port register on read,
> > a pci device allow hotplug return 0x1f, a pci device don't allow return
> > 0x1e.
> > Then the pci devices which don't allow hotplug will not show inside the
> > guest
> OS.
>
> So you are saying that the 'the IO port of QEMU that give this status always
> return
> true. " is no longer correct?
>
Yes, now the RMV bits of pci slot is set by the PCIDeviceClass's no_hotplug
attribute, such as:
static void cirrus_vga_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
k->no_hotplug = 1;
... ...
}
If k->no_hotplug equal 1, the corresponding slot of PIIX4PMState
pci0_hotplug_enable bit will be cleared.
Otherwise the slot's pci0_hotplug_enable bit will be set.
> >
> > Index: tools/firmware/hvmloader/acpi/mk_dsdt.c
> >
> ===
Re: [Qemu-devel] [PATCH v5 1/5] hpet: inverse polarity when pin above ISA_NUM_IRQS
On Sun, Sep 29, 2013 at 3:52 AM, Michael S. Tsirkin wrote:
> On Thu, Sep 12, 2013 at 11:25:14AM +0800, Liu Ping Fan wrote:
>> According to hpet spec, hpet irq is high active. But according to
>> ICH spec, there is inversion before the input of ioapic. So the OS
>> will expect low active on this IRQ line.
>
>
>>(And this is observed on
>> bare metal).
>
> How does one test this on bare metal?
>
If changing the func hpet_timer_set_irq() in linux's hpet driver,
from acpi_register_gsi(NULL, irq, ACPI_LEVEL_SENSITIVE,
ACPI_ACTIVE_LOW); to ACPI_ACTIVE_HIGH, then run hpet_example.c on
bare metal, the modified kernel will complain about spurious irq and
disable the irq line.
>>
>> We fold the emulation of this inversion inside the hpet logic.
>>
>> Signed-off-by: Liu Ping Fan
>
>
> Doesn't this affect cross-version migration?
> E.g. imagine that you migrate between systems
> with/without this fix.
>
No. the changing only affect "route >= ISA_NUM_IRQS", For linux
guest, it use IRQ2/8 for hpet0/hpet1 which is reserved by kernel. It
work without this fix (I think windows is the same). But the
hpet_example.c(in linux) can not work without this fix. So no such
run-time instance before this bug fix.
Regards,
Pingfan
>> ---
>> hw/timer/hpet.c | 14 --
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
>> index fcd22ae..8429eb3 100644
>> --- a/hw/timer/hpet.c
>> +++ b/hw/timer/hpet.c
>> @@ -198,13 +198,23 @@ static void update_irq(struct HPETTimer *timer, int
>> set)
>> if (!set || !timer_enabled(timer) || !hpet_enabled(timer->state)) {
>> s->isr &= ~mask;
>> if (!timer_fsb_route(timer)) {
>> -qemu_irq_lower(s->irqs[route]);
>> +/* fold the ICH PIRQ# pin's internal inversion logic into hpet
>> */
>> +if (route >= ISA_NUM_IRQS) {
>> +qemu_irq_raise(s->irqs[route]);
>> +} else {
>> +qemu_irq_lower(s->irqs[route]);
>> +}
>> }
>> } else if (timer_fsb_route(timer)) {
>> stl_le_phys(timer->fsb >> 32, timer->fsb & 0x);
>> } else if (timer->config & HPET_TN_TYPE_LEVEL) {
>> s->isr |= mask;
>> -qemu_irq_raise(s->irqs[route]);
>> +/* fold the ICH PIRQ# pin's internal inversion logic into hpet */
>> +if (route >= ISA_NUM_IRQS) {
>> +qemu_irq_lower(s->irqs[route]);
>> +} else {
>> +qemu_irq_raise(s->irqs[route]);
>> +}
>> } else {
>> s->isr &= ~mask;
>> qemu_irq_pulse(s->irqs[route]);
>> --
>> 1.8.1.4
>>
Re: [Qemu-devel] [PATCH v5 2/5] hpet: entitle more irq pins for hpet
On Sun, Sep 29, 2013 at 3:56 AM, Michael S. Tsirkin wrote:
> On Thu, Sep 12, 2013 at 11:25:15AM +0800, Liu Ping Fan wrote:
>> On PC, IRQ2/8 can be reserved for hpet timer 0/1. And pin 16~23
>> of ioapic can be dynamically assigned to hpet as guest chooses.
>> (Will enable them after introducing pc 1.6 compat)
>>
>> Signed-off-by: Liu Ping Fan
>> ---
>> hw/timer/hpet.c | 13 +++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
>> index 8429eb3..46903b9 100644
>> --- a/hw/timer/hpet.c
>> +++ b/hw/timer/hpet.c
>> @@ -25,6 +25,7 @@
>> */
>>
>> #include "hw/hw.h"
>> +#include "hw/boards.h"
>> #include "hw/i386/pc.h"
>> #include "ui/console.h"
>> #include "qemu/timer.h"
>> @@ -42,6 +43,12 @@
>>
>> #define HPET_MSI_SUPPORT0
>>
>> +/* For bug compat, using only IRQ2. Soon it will be fixed as
>> + * 0xff0104ULL, i.e using IRQ16~23, IRQ8 and IRQ2
>
> So users are expected to stick a bitmask of legal
> pins here?
> I think that's a bit too much rope to give to users.
> Don't you think?
>
Sorry, not understand your meaning exactly. But the scene will be:
guest kernel polls the ability bitmask, and pick up one pin which is
not occupied or can be shared with the level-trigger and low-active.
So is it rope?
Thanks and regards,
Pingfan
>> after
>> + * introducing pc-1.6 compat.
>> + */
>> +#define HPET_TN_INT_CAP_DEFAULT 0x4ULL
>> +
>> #define TYPE_HPET "hpet"
>> #define HPET(obj) OBJECT_CHECK(HPETState, (obj), TYPE_HPET)
>>
>> @@ -73,6 +80,7 @@ typedef struct HPETState {
>> uint8_t rtc_irq_level;
>> qemu_irq pit_enabled;
>> uint8_t num_timers;
>> +uint32_t intcap;
>> HPETTimer timer[HPET_MAX_TIMERS];
>>
>> /* Memory-mapped, software visible registers */
>> @@ -663,8 +671,8 @@ static void hpet_reset(DeviceState *d)
>> if (s->flags & (1 << HPET_MSI_SUPPORT)) {
>> timer->config |= HPET_TN_FSB_CAP;
>> }
>> -/* advertise availability of ioapic inti2 */
>> -timer->config |= 0x0004ULL << 32;
>> +/* advertise availability of ioapic int */
>> +timer->config |= (uint64_t)s->intcap << 32;
>> timer->period = 0ULL;
>> timer->wrap_flag = 0;
>> }
>> @@ -753,6 +761,7 @@ static void hpet_realize(DeviceState *dev, Error **errp)
>> static Property hpet_device_properties[] = {
>> DEFINE_PROP_UINT8("timers", HPETState, num_timers, HPET_MIN_TIMERS),
>> DEFINE_PROP_BIT("msi", HPETState, flags, HPET_MSI_SUPPORT, false),
>> +DEFINE_PROP_UINT32("intcap", HPETState, intcap,
>> HPET_TN_INT_CAP_DEFAULT),
>> DEFINE_PROP_END_OF_LIST(),
>> };
>>
>> --
>> 1.8.1.4
>>
Re: [Qemu-devel] [PATCH v5 2/5] hpet: entitle more irq pins for hpet
On Sun, Sep 29, 2013 at 11:49:41AM +0800, liu ping fan wrote:
> On Sun, Sep 29, 2013 at 3:56 AM, Michael S. Tsirkin wrote:
> > On Thu, Sep 12, 2013 at 11:25:15AM +0800, Liu Ping Fan wrote:
> >> On PC, IRQ2/8 can be reserved for hpet timer 0/1. And pin 16~23
> >> of ioapic can be dynamically assigned to hpet as guest chooses.
> >> (Will enable them after introducing pc 1.6 compat)
> >>
> >> Signed-off-by: Liu Ping Fan
> >> ---
> >> hw/timer/hpet.c | 13 +++--
> >> 1 file changed, 11 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
> >> index 8429eb3..46903b9 100644
> >> --- a/hw/timer/hpet.c
> >> +++ b/hw/timer/hpet.c
> >> @@ -25,6 +25,7 @@
> >> */
> >>
> >> #include "hw/hw.h"
> >> +#include "hw/boards.h"
> >> #include "hw/i386/pc.h"
> >> #include "ui/console.h"
> >> #include "qemu/timer.h"
> >> @@ -42,6 +43,12 @@
> >>
> >> #define HPET_MSI_SUPPORT0
> >>
> >> +/* For bug compat, using only IRQ2. Soon it will be fixed as
> >> + * 0xff0104ULL, i.e using IRQ16~23, IRQ8 and IRQ2
> >
> > So users are expected to stick a bitmask of legal
> > pins here?
> > I think that's a bit too much rope to give to users.
> > Don't you think?
> >
> Sorry, not understand your meaning exactly. But the scene will be:
> guest kernel polls the ability bitmask, and pick up one pin which is
> not occupied or can be shared with the level-trigger and low-active.
> So is it rope?
I merely say that it's better to make this a bool or bit property.
UINT32 is too much flexibility imho.
> Thanks and regards,
> Pingfan
> >> after
> >> + * introducing pc-1.6 compat.
> >> + */
> >> +#define HPET_TN_INT_CAP_DEFAULT 0x4ULL
> >> +
> >> #define TYPE_HPET "hpet"
> >> #define HPET(obj) OBJECT_CHECK(HPETState, (obj), TYPE_HPET)
> >>
> >> @@ -73,6 +80,7 @@ typedef struct HPETState {
> >> uint8_t rtc_irq_level;
> >> qemu_irq pit_enabled;
> >> uint8_t num_timers;
> >> +uint32_t intcap;
> >> HPETTimer timer[HPET_MAX_TIMERS];
> >>
> >> /* Memory-mapped, software visible registers */
> >> @@ -663,8 +671,8 @@ static void hpet_reset(DeviceState *d)
> >> if (s->flags & (1 << HPET_MSI_SUPPORT)) {
> >> timer->config |= HPET_TN_FSB_CAP;
> >> }
> >> -/* advertise availability of ioapic inti2 */
> >> -timer->config |= 0x0004ULL << 32;
> >> +/* advertise availability of ioapic int */
> >> +timer->config |= (uint64_t)s->intcap << 32;
> >> timer->period = 0ULL;
> >> timer->wrap_flag = 0;
> >> }
> >> @@ -753,6 +761,7 @@ static void hpet_realize(DeviceState *dev, Error
> >> **errp)
> >> static Property hpet_device_properties[] = {
> >> DEFINE_PROP_UINT8("timers", HPETState, num_timers, HPET_MIN_TIMERS),
> >> DEFINE_PROP_BIT("msi", HPETState, flags, HPET_MSI_SUPPORT, false),
> >> +DEFINE_PROP_UINT32("intcap", HPETState, intcap,
> >> HPET_TN_INT_CAP_DEFAULT),
> >> DEFINE_PROP_END_OF_LIST(),
> >> };
> >>
> >> --
> >> 1.8.1.4
> >>
[Qemu-devel] [PATCH v2 2/4] Curling: cmdline interface.
Add an option '-f' to migration cmdline.
Indicating whether to enable fault tolerant or not.
Signed-off-by: Jules Wang
---
hmp-commands.hx | 11 +++
hmp.c | 3 ++-
include/migration/migration.h | 1 +
migration.c | 3 ++-
qapi-schema.json | 3 ++-
qmp-commands.hx | 3 ++-
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 65b7f60..8418d37 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -877,23 +877,26 @@ ETEXI
{
.name = "migrate",
-.args_type = "detach:-d,blk:-b,inc:-i,uri:s",
-.params = "[-d] [-b] [-i] uri",
+.args_type = "detach:-d,blk:-b,inc:-i,ft:-f,uri:s",
+.params = "[-d] [-b] [-i] [-f] uri",
.help = "migrate to URI (using -d to not wait for completion)"
"\n\t\t\t -b for migration without shared storage with"
" full copy of disk\n\t\t\t -i for migration without "
"shared storage with incremental copy of disk "
- "(base image shared between src and destination)",
+ "(base image shared between src and destination)"
+ "\n\t\t\t -f for fault tolerant, this is another "
+ "feature rather than migrate",
.mhandler.cmd = hmp_migrate,
},
STEXI
-@item migrate [-d] [-b] [-i] @var{uri}
+@item migrate [-d] [-b] [-i] [-f] @var{uri}
@findex migrate
Migrate to @var{uri} (using -d to not wait for completion).
-b for migration with full copy of disk
-i for migration with incremental copy of disk (base image is shared)
+ -f for fault tolerant
ETEXI
{
diff --git a/hmp.c b/hmp.c
index fcca6ae..91beae9 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1213,10 +1213,11 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
int detach = qdict_get_try_bool(qdict, "detach", 0);
int blk = qdict_get_try_bool(qdict, "blk", 0);
int inc = qdict_get_try_bool(qdict, "inc", 0);
+int ft = qdict_get_try_bool(qdict, "ft", 0);
const char *uri = qdict_get_str(qdict, "uri");
Error *err = NULL;
-qmp_migrate(uri, !!blk, blk, !!inc, inc, false, false, &err);
+qmp_migrate(uri, !!blk, blk, !!inc, inc, false, false, !!ft, ft, &err);
if (err) {
monitor_printf(mon, "migrate: %s\n", error_get_pretty(err));
error_free(err);
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 140e6b4..fc2b066 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -25,6 +25,7 @@
struct MigrationParams {
bool blk;
+bool ft;
bool shared;
};
diff --git a/migration.c b/migration.c
index 200d404..8989a51 100644
--- a/migration.c
+++ b/migration.c
@@ -394,7 +394,7 @@ void migrate_del_blocker(Error *reason)
void qmp_migrate(const char *uri, bool has_blk, bool blk,
bool has_inc, bool inc, bool has_detach, bool detach,
- Error **errp)
+ bool has_ft, bool ft, Error **errp)
{
Error *local_err = NULL;
MigrationState *s = migrate_get_current();
@@ -403,6 +403,7 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
params.blk = has_blk && blk;
params.shared = has_inc && inc;
+params.ft = has_ft && ft;
if (s->state == MIG_STATE_ACTIVE || s->state == MIG_STATE_SETUP) {
error_set(errp, QERR_MIGRATION_ACTIVE);
diff --git a/qapi-schema.json b/qapi-schema.json
index a51f7d2..a8187cf 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -2420,7 +2420,8 @@
# Since: 0.14.0
##
{ 'command': 'migrate',
- 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool' } }
+ 'data': {'uri': 'str', '*blk': 'bool', '*inc': 'bool', '*detach': 'bool',
+ '*ft': 'bool' } }
# @xen-save-devices-state:
#
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 8a8f342..1fa0e60 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -611,7 +611,7 @@ EQMP
{
.name = "migrate",
-.args_type = "detach:-d,blk:-b,inc:-i,uri:s",
+.args_type = "detach:-d,blk:-b,inc:-i,ft:-f,uri:s",
.mhandler.cmd_new = qmp_marshal_input_migrate,
},
@@ -625,6 +625,7 @@ Arguments:
- "blk": block migration, full disk copy (json-bool, optional)
- "inc": incremental disk copy (json-bool, optional)
+- "ft" : fault tolerant (json-bool, optional)
- "uri": Destination URI (json-string)
Example:
--
1.8.0.1
[Qemu-devel] [PATCH v2 3/4] Curling: the sender
By leveraging live migration feature, the sender simply starts a
new migration when the previous migration is completed.
We need to handle the variables related to live migration very
carefully. So the new migration does not restart from the very
begin of the migration, instead, it continues the previous
migration.
Signed-off-by: Jules Wang
---
arch_init.c | 25 -
include/sysemu/sysemu.h | 3 ++-
migration.c | 25 +++--
savevm.c| 20
4 files changed, 61 insertions(+), 12 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index e47e139..cd0e0b1 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -107,6 +107,7 @@ const uint32_t arch_type = QEMU_ARCH;
static bool mig_throttle_on;
static int dirty_rate_high_cnt;
static void check_guest_throttling(void);
+static MigrationParams ram_mig_params;
/***/
/* ram save/restore */
@@ -596,6 +597,11 @@ static void ram_migration_cancel(void *opaque)
migration_end();
}
+static void ram_set_params(const MigrationParams *params, void *opaque)
+{
+ram_mig_params.ft = params->ft;
+}
+
static void reset_ram_globals(void)
{
last_seen_block = NULL;
@@ -611,10 +617,14 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
{
RAMBlock *block;
int64_t ram_pages = last_ram_offset() >> TARGET_PAGE_BITS;
+bool create = false;
-migration_bitmap = bitmap_new(ram_pages);
-bitmap_set(migration_bitmap, 0, ram_pages);
-migration_dirty_pages = ram_pages;
+if (!ram_mig_params.ft || !migration_bitmap) {
+migration_bitmap = bitmap_new(ram_pages);
+bitmap_set(migration_bitmap, 0, ram_pages);
+migration_dirty_pages = ram_pages;
+create = true;
+}
mig_throttle_on = false;
dirty_rate_high_cnt = 0;
@@ -634,7 +644,9 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
qemu_mutex_lock_iothread();
qemu_mutex_lock_ramlist();
bytes_transferred = 0;
-reset_ram_globals();
+if (!ram_mig_params.ft || create) {
+reset_ram_globals();
+}
memory_global_dirty_log_start();
migration_bitmap_sync();
@@ -744,7 +756,9 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
}
ram_control_after_iterate(f, RAM_CONTROL_FINISH);
-migration_end();
+if (!ram_mig_params.ft) {
+migration_end();
+}
qemu_mutex_unlock_ramlist();
qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
@@ -970,6 +984,7 @@ SaveVMHandlers savevm_ram_handlers = {
.save_live_pending = ram_save_pending,
.load_state = ram_load,
.cancel = ram_migration_cancel,
+.set_params = ram_set_params,
};
struct soundhw {
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index b1aa059..dabade4 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -77,7 +77,8 @@ bool qemu_savevm_state_blocked(Error **errp);
void qemu_savevm_state_begin(QEMUFile *f,
const MigrationParams *params);
int qemu_savevm_state_iterate(QEMUFile *f);
-void qemu_savevm_state_complete(QEMUFile *f);
+void qemu_savevm_state_complete(QEMUFile *f,
+const MigrationParams *params);
void qemu_savevm_state_cancel(void);
uint64_t qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size);
int qemu_loadvm_state(QEMUFile *f);
diff --git a/migration.c b/migration.c
index 8989a51..bf17c63 100644
--- a/migration.c
+++ b/migration.c
@@ -552,6 +552,7 @@ static void *migration_thread(void *opaque)
int64_t max_size = 0;
int64_t start_time = initial_time;
bool old_vm_running = false;
+int time_window = 100;
DPRINTF("beginning savevm\n");
qemu_savevm_state_begin(s->file, &s->params);
@@ -563,6 +564,8 @@ static void *migration_thread(void *opaque)
while (s->state == MIG_STATE_ACTIVE) {
int64_t current_time;
+int64_t time_spent;
+int64_t migration_start_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
uint64_t pending_size;
if (!qemu_file_rate_limit(s->file)) {
@@ -583,7 +586,7 @@ static void *migration_thread(void *opaque)
ret = vm_stop_force_state(RUN_STATE_FINISH_MIGRATE);
if (ret >= 0) {
qemu_file_set_rate_limit(s->file, INT_MAX);
-qemu_savevm_state_complete(s->file);
+qemu_savevm_state_complete(s->file, &s->params);
}
qemu_mutex_unlock_iothread();
@@ -592,10 +595,28 @@ static void *migration_thread(void *opaque)
break;
}
-if (!qemu_file_get_error(s->file)) {
+if (!qemu_file_get_error(s->file) && !s->params.ft) {
migrate_set_state(s, MIG_STATE_ACTIVE,
MIG_STATE_COMPLETED);
break;
}
+
+if (s->params.ft) {
[Qemu-devel] [PATCH v2 1/4] Curling: add doc
Curling provides fault tolerant mechanism for KVM. For more info, see 'doc/curling.txt'. Signed-off-by: Jules Wang --- docs/curling.txt | 51 +++ 1 file changed, 51 insertions(+) create mode 100644 docs/curling.txt diff --git a/docs/curling.txt b/docs/curling.txt new file mode 100644 index 000..f506a77 --- /dev/null +++ b/docs/curling.txt @@ -0,0 +1,51 @@ +KVM Fault Tolerance Specification += + + +Contents: += +* Introduction +* Usage +* Design & Implement +* Performance + +Introduction + +The goal of Curling(sports) is to provide a fault tolerant(ft for short) +mechanism for KVM, so that in the event of a hardware failure, the virtual +machine fails over to the backup in a way that is completely transparent +to the guest operating system. + + +Usage += +The steps of curling are the same as the steps of live migration except the +following: +1. Start ft in the qemu monitor of sender vm by following cmdline: + > migrate_set_speed + > migrate -f tcp:: +2. Connect to the receiver vm by vnc or spice. The screen of the vm is displayed +when ft is ready. +3. Now, the sender vm is protected by ft, When it encounters a failure, +the failover kicks in. + + + +Design & Implement +== +* By leveraging live migration feature, we do endless live migrations between +the sender and receiver, so the two virtual machines are synchronized. + +* The receiver does not load vm state once the migration begins, instead, it +perfetches one whole migration data into a buffer, then loads vm state from +that buffer afterwards. This "all or nothing" approach prevents the +broken-in-the-middle problem Kemari has. + +* The sender sleeps a little while after each migration, to ease the +performance penalty entailed by vm_stop and iothread locks. This is a +tradeoff between performance and accuracy. + + + +Performance +=== -- 1.8.0.1
[Qemu-devel] [PATCH v2 4/4] Curling: the receiver
The receiver does migration loop until the migration connection is
lost. Then, it is started as a backup.
The receiver does not load vm state once the migration begins.
Instead, it perfetches one whole migration data into a buffer,
then loads vm state from that buffer afterwards.
Signed-off-by: Jules Wang
---
include/migration/qemu-file.h | 1 +
include/sysemu/sysemu.h | 2 +
migration.c | 22 --
savevm.c | 158 --
4 files changed, 173 insertions(+), 10 deletions(-)
diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index 0f757fb..f01ff10 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -92,6 +92,7 @@ typedef struct QEMUFileOps {
QEMURamHookFunc *after_ram_iterate;
QEMURamHookFunc *hook_ram_load;
QEMURamSaveFunc *save_page;
+QEMUFileGetBufferFunc *get_prefetch_buffer;
} QEMUFileOps;
QEMUFile *qemu_fopen_ops(void *opaque, const QEMUFileOps *ops);
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index dabade4..0058987 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -82,6 +82,8 @@ void qemu_savevm_state_complete(QEMUFile *f,
void qemu_savevm_state_cancel(void);
uint64_t qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size);
int qemu_loadvm_state(QEMUFile *f);
+int qemu_loadvm_state_ft(QEMUFile *f);
+bool is_ft_migration(QEMUFile *f);
/* SLIRP */
void do_info_slirp(Monitor *mon);
diff --git a/migration.c b/migration.c
index bf17c63..64e7007 100644
--- a/migration.c
+++ b/migration.c
@@ -19,6 +19,7 @@
#include "monitor/monitor.h"
#include "migration/qemu-file.h"
#include "sysemu/sysemu.h"
+#include "sysemu/cpus.h"
#include "block/block.h"
#include "qemu/sockets.h"
#include "migration/block.h"
@@ -101,13 +102,24 @@ static void process_incoming_migration_co(void *opaque)
{
QEMUFile *f = opaque;
int ret;
+int count = 0;
-ret = qemu_loadvm_state(f);
-qemu_fclose(f);
-if (ret < 0) {
-fprintf(stderr, "load of migration failed\n");
-exit(EXIT_FAILURE);
+if (is_ft_migration(f)) {
+while (qemu_loadvm_state_ft(f) >= 0) {
+count++;
+DPRINTF("incoming count %d\r", count);
+}
+qemu_fclose(f);
+DPRINTF("ft connection lost, launching self..\n");
+} else {
+ret = qemu_loadvm_state(f);
+qemu_fclose(f);
+if (ret < 0) {
+fprintf(stderr, "load of migration failed\n");
+exit(EXIT_FAILURE);
+}
}
+cpu_synchronize_all_post_init();
qemu_announce_self();
DPRINTF("successfully loaded vm state\n");
diff --git a/savevm.c b/savevm.c
index 556c0e7..8cb3613 100644
--- a/savevm.c
+++ b/savevm.c
@@ -52,6 +52,8 @@
#define ARP_PTYPE_IP 0x0800
#define ARP_OP_REQUEST_REV 0x3
+#define PREFETCH_BUFFER_SIZE 0x01
+
static int announce_self_create(uint8_t *buf,
uint8_t *mac_addr)
{
@@ -135,6 +137,10 @@ struct QEMUFile {
unsigned int iovcnt;
int last_error;
+
+uint8_t *prefetch_buf;
+uint64_t prefetch_buf_index;
+uint64_t prefetch_buf_size;
};
typedef struct QEMUFileStdio
@@ -193,6 +199,25 @@ static int socket_get_buffer(void *opaque, uint8_t *buf,
int64_t pos, int size)
return len;
}
+static int socket_get_prefetch_buffer(void *opaque, uint8_t *buf,
+ int64_t pos, int size)
+{
+QEMUFile *f = opaque;
+
+if (f->prefetch_buf_size - pos <= 0) {
+return 0;
+}
+
+if (f->prefetch_buf_size - pos < size) {
+size = f->prefetch_buf_size - pos;
+}
+
+memcpy(buf, f->prefetch_buf + pos, size);
+
+return size;
+}
+
+
static int socket_close(void *opaque)
{
QEMUFileSocket *s = opaque;
@@ -440,6 +465,7 @@ QEMUFile *qemu_fdopen(int fd, const char *mode)
static const QEMUFileOps socket_read_ops = {
.get_fd = socket_get_fd,
.get_buffer = socket_get_buffer,
+.get_prefetch_buffer = socket_get_prefetch_buffer,
.close = socket_close
};
@@ -739,6 +765,8 @@ int qemu_fclose(QEMUFile *f)
if (f->last_error) {
ret = f->last_error;
}
+
+g_free(f->prefetch_buf);
g_free(f);
return ret;
}
@@ -822,6 +850,14 @@ void qemu_put_byte(QEMUFile *f, int v)
static void qemu_file_skip(QEMUFile *f, int size)
{
+if (f->prefetch_buf_index + size <= f->prefetch_buf_size) {
+f->prefetch_buf_index += size;
+return;
+} else {
+size -= f->prefetch_buf_size - f->prefetch_buf_index;
+f->prefetch_buf_index = f->prefetch_buf_size;
+}
+
if (f->buf_index + size <= f->buf_size) {
f->buf_index += size;
}
@@ -831,6 +867,23 @@ static int qemu_peek_buffer(QEMUFile *f, uint8_t *buf, int
size, size_t offset)
{
int pending;
int index;
+int done;
+
+if (f->ops->get_prefetch_buffer) {
+if
[Qemu-devel] [PATCH v2 0/4] Curling: KVM Fault Tolerance
v1 -> v2: * cmdline: migrate curling:tcp:: -> migrate -f tcp:: * sender: use QEMU_VM_FILE_MAGIC_FT as the header of the migration to indicate this is a ft migration. * receiver: look for the signature: QEMU_VM_EOF_MAGIC + QEMU_VM_FILE_MAGIC_FT(64bit total) which indicates the end of one migration. -- Jules Wang (4): Curling: add doc Curling: cmdline interface. Curling: the sender Curling: the receiver arch_init.c | 25 -- docs/curling.txt | 51 hmp-commands.hx | 11 ++- hmp.c | 3 +- include/migration/migration.h | 1 + include/migration/qemu-file.h | 1 + include/sysemu/sysemu.h | 5 +- migration.c | 50 ++-- qapi-schema.json | 3 +- qmp-commands.hx | 3 +- savevm.c | 178 +++--- 11 files changed, 301 insertions(+), 30 deletions(-) create mode 100644 docs/curling.txt -- 1.8.0.1
Re: [Qemu-devel] [PATCH v5 1/5] hpet: inverse polarity when pin above ISA_NUM_IRQS
On Sun, Sep 29, 2013 at 11:25:24AM +0800, liu ping fan wrote:
> On Sun, Sep 29, 2013 at 3:52 AM, Michael S. Tsirkin wrote:
> > On Thu, Sep 12, 2013 at 11:25:14AM +0800, Liu Ping Fan wrote:
> >> According to hpet spec, hpet irq is high active. But according to
> >> ICH spec, there is inversion before the input of ioapic. So the OS
> >> will expect low active on this IRQ line.
> >
> >
> >>(And this is observed on
> >> bare metal).
> >
> > How does one test this on bare metal?
> >
> If changing the func hpet_timer_set_irq() in linux's hpet driver,
> from acpi_register_gsi(NULL, irq, ACPI_LEVEL_SENSITIVE,
> ACPI_ACTIVE_LOW); to ACPI_ACTIVE_HIGH, then run hpet_example.c on
> bare metal, the modified kernel will complain about spurious irq and
> disable the irq line.
ok that's useful info for the changelog.
> >>
> >> We fold the emulation of this inversion inside the hpet logic.
> >>
> >> Signed-off-by: Liu Ping Fan
> >
> >
> > Doesn't this affect cross-version migration?
> > E.g. imagine that you migrate between systems
> > with/without this fix.
> >
> No. the changing only affect "route >= ISA_NUM_IRQS", For linux
> guest, it use IRQ2/8 for hpet0/hpet1 which is reserved by kernel. It
> work without this fix (I think windows is the same). But the
> hpet_example.c(in linux) can not work without this fix. So no such
> run-time instance before this bug fix.
>
> Regards,
> Pingfan
aha so the argument is it's already too broken to even mostly work,
we don't need to worry about migrating it to/from old qemu.
> >> ---
> >> hw/timer/hpet.c | 14 --
> >> 1 file changed, 12 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/hw/timer/hpet.c b/hw/timer/hpet.c
> >> index fcd22ae..8429eb3 100644
> >> --- a/hw/timer/hpet.c
> >> +++ b/hw/timer/hpet.c
> >> @@ -198,13 +198,23 @@ static void update_irq(struct HPETTimer *timer, int
> >> set)
> >> if (!set || !timer_enabled(timer) || !hpet_enabled(timer->state)) {
> >> s->isr &= ~mask;
> >> if (!timer_fsb_route(timer)) {
> >> -qemu_irq_lower(s->irqs[route]);
> >> +/* fold the ICH PIRQ# pin's internal inversion logic into
> >> hpet */
> >> +if (route >= ISA_NUM_IRQS) {
> >> +qemu_irq_raise(s->irqs[route]);
> >> +} else {
> >> +qemu_irq_lower(s->irqs[route]);
> >> +}
> >> }
> >> } else if (timer_fsb_route(timer)) {
> >> stl_le_phys(timer->fsb >> 32, timer->fsb & 0x);
> >> } else if (timer->config & HPET_TN_TYPE_LEVEL) {
> >> s->isr |= mask;
> >> -qemu_irq_raise(s->irqs[route]);
> >> +/* fold the ICH PIRQ# pin's internal inversion logic into hpet */
> >> +if (route >= ISA_NUM_IRQS) {
> >> +qemu_irq_lower(s->irqs[route]);
> >> +} else {
> >> +qemu_irq_raise(s->irqs[route]);
> >> +}
> >> } else {
> >> s->isr &= ~mask;
> >> qemu_irq_pulse(s->irqs[route]);
> >> --
> >> 1.8.1.4
> >>
[Qemu-devel] [PULL 00/14] pc,pci,virtio fixes and cleanups
The following changes since commit 2d1fe1873a984d1c2c89ffa3d12949cafc718551: Merge remote-tracking branch 'pmaydell/tags/pull-target-arm-20130910' into staging (2013-09-11 14:46:52 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_anthony for you to fetch changes up to e26d3e734650640fabd7d95ace4f3a6f88725e0b: smbios: Factor out smbios_maybe_add_str() (2013-09-28 23:49:39 +0300) pc,pci,virtio fixes and cleanups This includes pc and pci cleanups and enhancements, and a virtio-net bugfix related to softmac programming. Signed-off-by: Michael S. Tsirkin Hervé Poussineau (1): pci: remove explicit check to 64K ioport size Markus Armbruster (5): smbios: Normalize smbios_entry_add()'s error handling to exit(1) smbios: Convert to QemuOpts smbios: Improve diagnostics for conflicting entries smbios: Make multiple -smbios type= accumulate sanely smbios: Factor out smbios_maybe_add_str() Michael S. Tsirkin (8): q35: make pci window address/size match guest cfg range: add Range to typedefs range: add min/max operations on ranges pci: add helper to retrieve the 64-bit range q35: use 64 bit window programmed by guest piix: use 64 bit window programmed by guest piix4: disable io on reset virtio-net: fix up HMP NIC info string on reset include/hw/i386/smbios.h | 5 +- include/hw/pci/pci.h | 1 + include/qemu/range.h | 20 ++- include/qemu/typedefs.h| 1 + include/sysemu/arch_init.h | 2 +- include/sysemu/sysemu.h| 1 + arch_init.c| 9 +- hw/acpi/piix4.c| 1 + hw/i386/smbios.c | 339 - hw/net/virtio-net.c| 1 + hw/pci-host/piix.c | 14 +- hw/pci-host/q35.c | 24 +++- hw/pci/pci.c | 56 +++- vl.c | 5 +- 14 files changed, 359 insertions(+), 120 deletions(-) -- MST
[Qemu-devel] [PULL 07/14] piix4: disable io on reset
io base register at 0x40 is cleared on reset, but io is not disabled until some other event happens to call pm_io_space_update. Invoke pm_io_space_update directly to make this consistent. Cc: qemu-sta...@nongnu.org Signed-off-by: Michael S. Tsirkin --- hw/acpi/piix4.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c index 0b8d1d9..b46bd5e 100644 --- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -380,6 +380,7 @@ static void piix4_reset(void *opaque) /* Mark SMM as already inited (until KVM supports SMM). */ pci_conf[0x5B] = 0x02; } +pm_io_space_update(s); piix4_update_hotplug(s); } -- MST
[Qemu-devel] [PULL 09/14] virtio-net: fix up HMP NIC info string on reset
When mac is updated on reset, info string has stale data. Fix it up. Signed-off-by: Michael S. Tsirkin --- hw/net/virtio-net.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c index dd41008..22dbd05 100644 --- a/hw/net/virtio-net.c +++ b/hw/net/virtio-net.c @@ -314,6 +314,7 @@ static void virtio_net_reset(VirtIODevice *vdev) n->mac_table.uni_overflow = 0; memset(n->mac_table.macs, 0, MAC_TABLE_ENTRIES * ETH_ALEN); memcpy(&n->mac[0], &n->nic->conf->macaddr, sizeof(n->mac)); +qemu_format_nic_info_str(qemu_get_queue(n->nic), n->mac); memset(n->vlans, 0, MAX_VLAN >> 3); } -- MST
[Qemu-devel] [PULL 01/14] q35: make pci window address/size match guest cfg
For Q35, MMCFG address and size are guest configurable.
Update w32 property to make it behave accordingly.
Signed-off-by: Michael S. Tsirkin
---
hw/pci-host/q35.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 5473504..72f6b72 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -214,6 +214,16 @@ static void mch_update_pciexbar(MCHPCIState *mch)
}
addr = pciexbar & addr_mask;
pcie_host_mmcfg_update(pehb, enable, addr, length);
+/* Leave enough space for the MCFG BAR */
+/*
+ * TODO: this matches current bios behaviour, but it's not a power of two,
+ * which means an MTRR can't cover it exactly.
+ */
+if (enable) {
+mch->pci_info.w32.begin = addr + length;
+} else {
+mch->pci_info.w32.begin = MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT;
+}
}
/* PAM */
--
MST
