Re: [Qemu-devel] [PATCH] block: Produce zeros when protocols reading beyond end of file
On Fri, Aug 16, 2013 at 10:41:36AM +0200, Stefan Hajnoczi wrote:
> On Mon, Aug 5, 2013 at 10:11 AM, Asias He wrote:
> > From: MORITA Kazutaka
> >
> > While Asias is debugging an issue creating qcow2 images on top of
> > non-file protocols. It boils down to this example using NBD:
> >
> > $ qemu-io -c 'open -g nbd+unix:///?socket=/tmp/nbd.sock' -c 'read -v 0 512'
> >
> > Notice the open -g option to set bs->growable. This means you can
> > read/write beyond end of file. Reading beyond end of file is supposed
> > to produce zeroes.
> >
> > We rely on this behavior in qcow2_create2() during qcow2 image
> > creation. We create a new file and then write the qcow2 header
> > structure using bdrv_pwrite(). Since QCowHeader is not a multiple of
> > sector size, block.c first uses bdrv_read() on the empty file to fetch
> > the first sector (should be all zeroes).
> >
> > Here is the output from the qemu-io NBD example above:
> >
> > $ qemu-io -c 'open -g nbd+unix:///?socket=/tmp/nbd.sock' -c 'read -v 0 512'
> > : ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> > 0010: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> > 0020: ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> > ...
> >
> > We are not zeroing the buffer! As a result qcow2 image creation on top
> > of protocols is not guaranteed to work even when file creation is
> > supported by the protocol.
> >
> > Signed-off-by: MORITA Kazutaka
> > Signed-off-by: Asias He
> > ---
> > block.c | 30 +-
> > 1 file changed, 29 insertions(+), 1 deletion(-)
> >
> > diff --git a/block.c b/block.c
> > index 01b66d8..deaf0a0 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -2544,7 +2544,35 @@ static int coroutine_fn
> > bdrv_co_do_readv(BlockDriverState *bs,
> > }
> > }
> >
> > -ret = drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
> > +if (!bs->drv->protocol_name) {
> > +ret = drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
> > +} else {
> > +/* NBD doesn't support reading beyond end of file. */
> > +int64_t len, total_sectors, max_nb_sectors;
> > +
> > +len = bdrv_getlength(bs);
> > +if (len < 0) {
> > +ret = len;
> > +goto out;
> > +}
> > +
> > +total_sectors = len >> BDRV_SECTOR_BITS;
> > +max_nb_sectors = MAX(0, total_sectors - sector_num);
> > +if (max_nb_sectors > 0) {
> > +ret = drv->bdrv_co_readv(bs, sector_num,
> > + MIN(nb_sectors, max_nb_sectors),
> > qiov);
> > +} else {
> > +ret = 0;
> > +}
> > +
> > +/* Reading beyond end of file is supposed to produce zeroes */
> > +if (ret == 0 && total_sectors < sector_num + nb_sectors) {
> > +size_t offset = MAX(0, total_sectors - sector_num);
> > +size_t bytes = (sector_num + nb_sectors - offset) *
> > +BDRV_SECTOR_SIZE;
> > +qemu_iovec_memset(qiov, offset * BDRV_SECTOR_SIZE, 0, bytes);
> > +}
> > +}
>
> This patch breaks qemu-iotests ./check -qcow2 022. This happens
> because qcow2 temporarily sets ->growable = 1 for vmstate accesses
> (which are stored beyond the end of regular image data).
I am a bit confused. This is from the other mail:
"""
> > I think it would break qcow2_load_vmstate(), which is basically a
> >
> > bdrv_pread() after the end of the image.
> >
>
>
> I see, then only protocols have to zeroing the buffer? In case of
>
> protocols, I think bdrv_getlength() returns the underlying file
>
> length, so qcow2_load_vmstate() would be a bdrv_pread() within the
>
> result of bdrv_getlength().
>
Limiting it to protocols solves the problem, I think.
"""
And in v1 of this patch, Kevin wanted bs->growable check instad of the
protocol_name one.
"""
> -ret = drv->bdrv_co_readv(bs, sector_num, nb_sectors, qiov);
>
> +if (!bs->drv->protocol_name) {
>
I think !bs->growable is the right check.
Checking for the protocol name is always a hack and most times wrong.
"""
Switching back to the protocol_name check, ./check -q
[Qemu-devel] [Bug 1213797] Re: Guest hang after live migration
Hi, qemu-kvm no longer exists as it has been merged into qemu. You might want to have a try with the lastest upstream/master qemu tree, or pre-release versions of it. :) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1213797 Title: Guest hang after live migration Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git Commit:205befd9a5c701b56f569434045821f413f08f6d qemu-kvm uq/master Commit:ca916d3729564d0eb3c2374a96903f7e8aced8a7 Host Kernel Version:3.11.0-rc1 Hardware:Romley_EP, Ivytown_EP Bug detailed description: -- after guest live migration, the guest will hang, and ping IP fail note: 1. after guest save/restore, the guest will hang, and ping IP fail 2. This should be a qemu-kvm bug. kvm + qemu-kvm = result 205befd9 + ca916d37 = bad 205befd9 + f03d07d4 = good Reproduce steps: 1.Start a TCP daemon for migration qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -net nic,macaddr=00:12:34:56:13:45 -net tap,script=/etc/kvm/qemu-ifup rhel6u2.qcow -incoming tcp:localhost: 2. create guest qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -net nic,macaddr=00:12:34:56:13:45 -net tap,script=/etc/kvm/qemu-ifup rhel6u2.qcow 3. migrate tcp:localhost: Current result: guest hang Expected result: after live/migration or save/restore, the guest works fine To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1213797/+subscriptions
[Qemu-devel] [Bug 1213797] [NEW] Guest hang after live migration
Public bug reported: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git Commit:205befd9a5c701b56f569434045821f413f08f6d qemu-kvm uq/master Commit:ca916d3729564d0eb3c2374a96903f7e8aced8a7 Host Kernel Version:3.11.0-rc1 Hardware:Romley_EP, Ivytown_EP Bug detailed description: -- after guest live migration, the guest will hang, and ping IP fail note: 1. after guest save/restore, the guest will hang, and ping IP fail 2. This should be a qemu-kvm bug. kvm + qemu-kvm = result 205befd9 + ca916d37 = bad 205befd9 + f03d07d4 = good Reproduce steps: 1.Start a TCP daemon for migration qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -net nic,macaddr=00:12:34:56:13:45 -net tap,script=/etc/kvm/qemu-ifup rhel6u2.qcow -incoming tcp:localhost: 2. create guest qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -net nic,macaddr=00:12:34:56:13:45 -net tap,script=/etc/kvm/qemu-ifup rhel6u2.qcow 3. migrate tcp:localhost: Current result: guest hang Expected result: after live/migration or save/restore, the guest works fine ** Affects: qemu Importance: Undecided Status: New ** Attachment added: "guest serial log" https://bugs.launchpad.net/bugs/1213797/+attachment/3777611/+files/guest_serial.log -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1213797 Title: Guest hang after live migration Status in QEMU: New Bug description: Environment: Host OS (ia32/ia32e/IA64):ia32e Guest OS (ia32/ia32e/IA64):ia32e Guest OS Type (Linux/Windows):Linux kvm.git Commit:205befd9a5c701b56f569434045821f413f08f6d qemu-kvm uq/master Commit:ca916d3729564d0eb3c2374a96903f7e8aced8a7 Host Kernel Version:3.11.0-rc1 Hardware:Romley_EP, Ivytown_EP Bug detailed description: -- after guest live migration, the guest will hang, and ping IP fail note: 1. after guest save/restore, the guest will hang, and ping IP fail 2. This should be a qemu-kvm bug. kvm + qemu-kvm = result 205befd9 + ca916d37 = bad 205befd9 + f03d07d4 = good Reproduce steps: 1.Start a TCP daemon for migration qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -net nic,macaddr=00:12:34:56:13:45 -net tap,script=/etc/kvm/qemu-ifup rhel6u2.qcow -incoming tcp:localhost: 2. create guest qemu-system-x86_64 -enable-kvm -m 2G -smp 2 -net nic,macaddr=00:12:34:56:13:45 -net tap,script=/etc/kvm/qemu-ifup rhel6u2.qcow 3. migrate tcp:localhost: Current result: guest hang Expected result: after live/migration or save/restore, the guest works fine To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1213797/+subscriptions
[Qemu-devel] [PATCH v3 6/8] xics-kvm: Support for in-kernel XICS interrupt controller
From: David Gibson
Recent (host) kernels support emulating the PAPR defined "XICS" interrupt
controller system within KVM. This patch allows qemu to initialize and
configure the in-kernel XICS, and keep its state in sync with qemu's XICS
state as necessary.
This should give considerable performance improvements. e.g. on a simple
IPI ping-pong test between hardware threads, using qemu XICS gives us
around 5,000 irqs/second, whereas the in-kernel XICS gives us around
70,000 irqs/s on the same hardware configuration.
Signed-off-by: David Gibson
[Mike Qiu : fixed mistype which caused
ics_set_kvm_state() to fail]
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* ics_kvm_realize() now is a realize callback rather than initfn callback
* asserts replaced with Error**
* KVM_ICS is created now in KVM_XICS's initfn rather than in the nr_irqs
property setter
* added KVM_XICS_GET_PARENT_CLASS() to get the common XICS class - needed
for xics_kvm_cpu_setup() to call parent's cpu_setup()
* fixed some indentations, removed some \n from error_report()
---
default-configs/ppc64-softmmu.mak | 1 +
hw/intc/Makefile.objs | 1 +
hw/intc/xics_kvm.c| 492 ++
hw/ppc/spapr.c| 23 +-
include/hw/ppc/xics.h | 13 +
5 files changed, 528 insertions(+), 2 deletions(-)
create mode 100644 hw/intc/xics_kvm.c
diff --git a/default-configs/ppc64-softmmu.mak
b/default-configs/ppc64-softmmu.mak
index 7831c2b..116f4ca 100644
--- a/default-configs/ppc64-softmmu.mak
+++ b/default-configs/ppc64-softmmu.mak
@@ -47,6 +47,7 @@ CONFIG_E500=y
CONFIG_OPENPIC_KVM=$(and $(CONFIG_E500),$(CONFIG_KVM))
# For pSeries
CONFIG_XICS=$(CONFIG_PSERIES)
+CONFIG_XICS_KVM=$(and $(CONFIG_PSERIES),$(CONFIG_KVM))
# For PReP
CONFIG_I82378=y
CONFIG_I8259=y
diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 2851eed..47ac442 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -23,3 +23,4 @@ obj-$(CONFIG_OMAP) += omap_intc.o
obj-$(CONFIG_OPENPIC_KVM) += openpic_kvm.o
obj-$(CONFIG_SH4) += sh_intc.o
obj-$(CONFIG_XICS) += xics.o
+obj-$(CONFIG_XICS_KVM) += xics_kvm.o
diff --git a/hw/intc/xics_kvm.c b/hw/intc/xics_kvm.c
new file mode 100644
index 000..4ed4f33
--- /dev/null
+++ b/hw/intc/xics_kvm.c
@@ -0,0 +1,492 @@
+/*
+ * QEMU PowerPC pSeries Logical Partition (aka sPAPR) hardware System Emulator
+ *
+ * PAPR Virtualized Interrupt System, aka ICS/ICP aka xics, in-kernel emulation
+ *
+ * Copyright (c) 2013 David Gibson, IBM Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ */
+
+#include "hw/hw.h"
+#include "trace.h"
+#include "hw/ppc/spapr.h"
+#include "hw/ppc/xics.h"
+#include "kvm_ppc.h"
+#include "qemu/config-file.h"
+#include "qemu/error-report.h"
+
+#include
+
+typedef struct KVMXICSState {
+XICSState parent_obj;
+
+uint32_t set_xive_token;
+uint32_t get_xive_token;
+uint32_t int_off_token;
+uint32_t int_on_token;
+int kernel_xics_fd;
+} KVMXICSState;
+
+/*
+ * ICP-KVM
+ */
+static void icp_get_kvm_state(ICPState *ss)
+{
+uint64_t state;
+struct kvm_one_reg reg = {
+.id = KVM_REG_PPC_ICP_STATE,
+.addr = (uintptr_t)&state,
+};
+int ret;
+
+/* ICP for this CPU thread is not in use, exiting */
+if (!ss->cs) {
+return;
+}
+
+ret = kvm_vcpu_ioctl(ss->cs, KVM_GET_ONE_REG, ®);
+if (ret != 0) {
+error_report("Unable to retrieve KVM interrupt controller state"
+" for CPU %d: %s", ss->cs->cpu_index, strerror(errno));
+exit(1);
+}
+
+ss->xirr = state >> KVM_REG_PPC_ICP_XISR_SHIFT;
+ss->mfrr = (state >> KVM_REG_PPC_ICP_MFRR_SHIFT)
+& KVM_REG_PPC_ICP_MFRR_MASK;
+ss->pending_priority = (state >> KVM_REG_PPC_ICP_PPRI_SHIFT)
+& KVM_REG_PPC_ICP_PPRI_MASK;
+}
+
+static int icp_set_kvm_state(ICPState *ss, int version_id)
+{
+uint64_t state;
+
[Qemu-devel] [PATCH v3 5/8] xics: split to xics and xics-common
The upcoming XICS-KVM support will use bits of emulated XICS code.
So this introduces new level of hierarchy - "xics-common" class. Both
emulated XICS and XICS-KVM will inherit from it and override class
callbacks when required.
The new "xics-common" class implements:
1. replaces static "nr_irqs" and "nr_servers" properties with
the dynamic ones and adds callbacks to be executed when properties
are set.
2. xics_cpu_setup() callback renamed to xics_common_cpu_setup() as
it is a common part for both XICS'es
3. xics_reset() renamed to xics_common_reset() for the same reason.
The emulated XICS changes:
1. the part of xics_realize() which creates ICPs is moved to
the "nr_servers" property callback as realize() is too late to
create/initialize devices and instance_init() is too early to create
devices as the number of child devices comes via the "nr_servers"
property.
2. added ics_initfn() which does a little part of what xics_realize() did.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* added getters for dynamic properties
* fixed some indentations, added some comments
* moved ICS allocation from the nr_irqs property setter to XICS initfn
(where it was initially after Anthony's rework)
---
hw/intc/xics.c| 213 ++
include/hw/ppc/xics.h | 11 ++-
2 files changed, 175 insertions(+), 49 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 4d08c58..f439e8d 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -30,6 +30,143 @@
#include "hw/ppc/spapr.h"
#include "hw/ppc/xics.h"
#include "qemu/error-report.h"
+#include "qapi/visitor.h"
+
+/*
+ * XICS Common class - parent for emulated XICS and KVM-XICS
+ */
+
+static void xics_common_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
+{
+CPUState *cs = CPU(cpu);
+CPUPPCState *env = &cpu->env;
+ICPState *ss = &icp->ss[cs->cpu_index];
+
+assert(cs->cpu_index < icp->nr_servers);
+
+switch (PPC_INPUT(env)) {
+case PPC_FLAGS_INPUT_POWER7:
+ss->output = env->irq_inputs[POWER7_INPUT_INT];
+break;
+
+case PPC_FLAGS_INPUT_970:
+ss->output = env->irq_inputs[PPC970_INPUT_INT];
+break;
+
+default:
+error_report("XICS interrupt controller does not support this CPU "
+ "bus model");
+/* Called from machine_init only so no point in Error**, just abort */
+abort();
+}
+}
+
+static void xics_prop_get_nr_irqs(Object *obj, Visitor *v,
+ void *opaque, const char *name, Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+int64_t value = icp->nr_irqs;
+
+visit_type_int(v, &value, name, errp);
+}
+
+static void xics_prop_set_nr_irqs(Object *obj, Visitor *v,
+ void *opaque, const char *name, Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+XICSStateClass *info = XICS_COMMON_GET_CLASS(icp);
+Error *error = NULL;
+int64_t value;
+
+visit_type_int(v, &value, name, &error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
+if (icp->nr_irqs) {
+error_setg(errp, "Number of interrupts is already set to %u",
+ icp->nr_irqs);
+return;
+}
+
+assert(info->set_nr_irqs);
+assert(icp->ics);
+info->set_nr_irqs(icp, value, errp);
+}
+
+static void xics_prop_get_nr_servers(Object *obj, Visitor *v,
+ void *opaque, const char *name,
+ Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+int64_t value = icp->nr_servers;
+
+visit_type_int(v, &value, name, errp);
+}
+
+static void xics_prop_set_nr_servers(Object *obj, Visitor *v,
+ void *opaque, const char *name,
+ Error **errp)
+{
+XICSState *icp = XICS_COMMON(obj);
+XICSStateClass *info = XICS_COMMON_GET_CLASS(icp);
+Error *error = NULL;
+int64_t value;
+
+visit_type_int(v, &value, name, &error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
+if (icp->nr_servers) {
+error_setg(errp, "Number of servers is already set to %u",
+ icp->nr_servers);
+return;
+}
+
+assert(info->set_nr_servers);
+info->set_nr_servers(icp, value, errp);
+}
+
+static void xics_common_initfn(Object *obj)
+{
+object_property_add(obj, "nr_irqs", "int",
+xics_prop_get_nr_irqs, xics_prop_set_nr_irqs,
+NULL, NULL, NULL);
+object_property_add(obj, "nr_servers", "int",
+xics_prop_get_nr_servers, xics_prop_set_nr_servers,
+NULL, NULL, NULL);
+}
+
+static void xics_common_reset(DeviceState *d)
+{
+XICSState *icp = XICS_COMMON(d);
+int i;
+
+for (i = 0; i < icp->nr_servers; i++) {
+device_reset(DEVICE(&icp->ss[i]));
+}
+
+device_reset(DEVICE(
[Qemu-devel] [PATCH v3 2/8] xics: add pre_save/post_load/cpu_setup dispatchers
The upcoming support of in-kernel XICS will redefine migration callbacks
for both ICS and ICP so classes and callback pointers are added.
This adds a cpu_setup callback to the XICS device class (as XICS-KVM
will do it different) and xics_dispatch_cpu_setup(). This also moves
the place where xics_dispatch_cpu_setup() is called a bit further to
have VCPU initialized (required for XICS-KVM).
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* fixed local variables names
---
hw/intc/xics.c| 61 +++
hw/ppc/spapr.c| 4 ++--
include/hw/ppc/xics.h | 46 +-
3 files changed, 104 insertions(+), 7 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index 6b3c071..e3a957d 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -153,11 +153,35 @@ static void icp_irq(XICSState *icp, int server, int nr,
uint8_t priority)
}
}
+static void icp_dispatch_pre_save(void *opaque)
+{
+ICPState *ss = opaque;
+ICPStateClass *info = ICP_GET_CLASS(ss);
+
+if (info->pre_save) {
+info->pre_save(ss);
+}
+}
+
+static int icp_dispatch_post_load(void *opaque, int version_id)
+{
+ICPState *ss = opaque;
+ICPStateClass *info = ICP_GET_CLASS(ss);
+
+if (info->post_load) {
+return info->post_load(ss, version_id);
+}
+
+return 0;
+}
+
static const VMStateDescription vmstate_icp_server = {
.name = "icp/server",
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
+.pre_save = icp_dispatch_pre_save,
+.post_load = icp_dispatch_post_load,
.fields = (VMStateField []) {
/* Sanity check */
VMSTATE_UINT32(xirr, ICPState),
@@ -192,6 +216,7 @@ static TypeInfo icp_info = {
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICPState),
.class_init = icp_class_init,
+.class_size = sizeof(ICPStateClass),
};
/*
@@ -353,10 +378,9 @@ static void ics_reset(DeviceState *dev)
}
}
-static int ics_post_load(void *opaque, int version_id)
+static int ics_post_load(ICSState *ics, int version_id)
{
int i;
-ICSState *ics = opaque;
for (i = 0; i < ics->icp->nr_servers; i++) {
icp_resend(ics->icp, i);
@@ -365,6 +389,28 @@ static int ics_post_load(void *opaque, int version_id)
return 0;
}
+static void ics_dispatch_pre_save(void *opaque)
+{
+ICSState *ics = opaque;
+ICSStateClass *info = ICS_GET_CLASS(ics);
+
+if (info->pre_save) {
+info->pre_save(ics);
+}
+}
+
+static int ics_dispatch_post_load(void *opaque, int version_id)
+{
+ICSState *ics = opaque;
+ICSStateClass *info = ICS_GET_CLASS(ics);
+
+if (info->post_load) {
+return info->post_load(ics, version_id);
+}
+
+return 0;
+}
+
static const VMStateDescription vmstate_ics_irq = {
.name = "ics/irq",
.version_id = 1,
@@ -384,7 +430,8 @@ static const VMStateDescription vmstate_ics = {
.version_id = 1,
.minimum_version_id = 1,
.minimum_version_id_old = 1,
-.post_load = ics_post_load,
+.pre_save = ics_dispatch_pre_save,
+.post_load = ics_dispatch_post_load,
.fields = (VMStateField []) {
/* Sanity check */
VMSTATE_UINT32_EQUAL(nr_irqs, ICSState),
@@ -409,10 +456,12 @@ static int ics_realize(DeviceState *dev)
static void ics_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
+ICSStateClass *isc = ICS_CLASS(klass);
dc->init = ics_realize;
dc->vmsd = &vmstate_ics;
dc->reset = ics_reset;
+isc->post_load = ics_post_load;
}
static TypeInfo ics_info = {
@@ -420,6 +469,7 @@ static TypeInfo ics_info = {
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICSState),
.class_init = ics_class_init,
+.class_size = sizeof(ICSStateClass),
};
/*
@@ -612,7 +662,7 @@ static void xics_reset(DeviceState *d)
device_reset(DEVICE(icp->ics));
}
-void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
+static void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
{
CPUState *cs = CPU(cpu);
CPUPPCState *env = &cpu->env;
@@ -674,10 +724,12 @@ static Property xics_properties[] = {
static void xics_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
+XICSStateClass *k = XICS_CLASS(oc);
dc->realize = xics_realize;
dc->props = xics_properties;
dc->reset = xics_reset;
+k->cpu_setup = xics_cpu_setup;
spapr_rtas_register("ibm,set-xive", rtas_set_xive);
spapr_rtas_register("ibm,get-xive", rtas_get_xive);
@@ -694,6 +746,7 @@ static const TypeInfo xics_info = {
.name = TYPE_XICS,
.parent= TYPE_SYS_BUS_DEVICE,
.instance_size = sizeof(XICSState),
+.class_size = sizeof(XICSStateClass),
.class_init= xics_class_init,
.instance_init = xics_initfn,
};
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 16bfab9..432f0d2 100644
--- a/hw/ppc/
[Qemu-devel] [PATCH v3 3/8] xics: move registration of global state to realize()
Registration of global state belongs into realize so move it there.
Signed-off-by: Alexey Kardashevskiy
Reviewed-by: Andreas Färber
---
hw/intc/xics.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index e3a957d..c80fa80 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -692,6 +692,17 @@ static void xics_realize(DeviceState *dev, Error **errp)
ICSState *ics = icp->ics;
int i;
+/* Registration of global state belongs into realize */
+spapr_rtas_register("ibm,set-xive", rtas_set_xive);
+spapr_rtas_register("ibm,get-xive", rtas_get_xive);
+spapr_rtas_register("ibm,int-off", rtas_int_off);
+spapr_rtas_register("ibm,int-on", rtas_int_on);
+
+spapr_register_hypercall(H_CPPR, h_cppr);
+spapr_register_hypercall(H_IPI, h_ipi);
+spapr_register_hypercall(H_XIRR, h_xirr);
+spapr_register_hypercall(H_EOI, h_eoi);
+
ics->nr_irqs = icp->nr_irqs;
ics->offset = XICS_IRQ_BASE;
ics->icp = icp;
@@ -730,16 +741,6 @@ static void xics_class_init(ObjectClass *oc, void *data)
dc->props = xics_properties;
dc->reset = xics_reset;
k->cpu_setup = xics_cpu_setup;
-
-spapr_rtas_register("ibm,set-xive", rtas_set_xive);
-spapr_rtas_register("ibm,get-xive", rtas_get_xive);
-spapr_rtas_register("ibm,int-off", rtas_int_off);
-spapr_rtas_register("ibm,int-on", rtas_int_on);
-
-spapr_register_hypercall(H_CPPR, h_cppr);
-spapr_register_hypercall(H_IPI, h_ipi);
-spapr_register_hypercall(H_XIRR, h_xirr);
-spapr_register_hypercall(H_EOI, h_eoi);
}
static const TypeInfo xics_info = {
--
1.8.3.2
[Qemu-devel] [PATCH v3 4/8] xics: minor changes and cleanups
Before XICS-KVM comes, it makes sense to clean up the emulated XICS a bit.
This does:
1. add assert in ics_realize()
2. change variable names from "k" to more informative ones
3. add "const" to every TypeInfo
4. replace fprintf(stderr, ..."\n") with error_report
5. replace old style qdev_init_nofail() with new style
object_property_set_bool().
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* ics_realize() fixed to be actual realize callback rather than initfn
* asserts replaced with Error**
---
hw/intc/xics.c | 42 ++
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/hw/intc/xics.c b/hw/intc/xics.c
index c80fa80..4d08c58 100644
--- a/hw/intc/xics.c
+++ b/hw/intc/xics.c
@@ -29,6 +29,7 @@
#include "trace.h"
#include "hw/ppc/spapr.h"
#include "hw/ppc/xics.h"
+#include "qemu/error-report.h"
/*
* ICP: Presentation layer
@@ -211,7 +212,7 @@ static void icp_class_init(ObjectClass *klass, void *data)
dc->vmsd = &vmstate_icp_server;
}
-static TypeInfo icp_info = {
+static const TypeInfo icp_info = {
.name = TYPE_ICP,
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICPState),
@@ -442,15 +443,17 @@ static const VMStateDescription vmstate_ics = {
},
};
-static int ics_realize(DeviceState *dev)
+static void ics_realize(DeviceState *dev, Error **errp)
{
ICSState *ics = ICS(dev);
+if (!ics->nr_irqs) {
+error_setg(errp, "Number of interrupts needs to be greater 0");
+return;
+}
ics->irqs = g_malloc0(ics->nr_irqs * sizeof(ICSIRQState));
ics->islsi = g_malloc0(ics->nr_irqs * sizeof(bool));
ics->qirqs = qemu_allocate_irqs(ics_set_irq, ics, ics->nr_irqs);
-
-return 0;
}
static void ics_class_init(ObjectClass *klass, void *data)
@@ -458,13 +461,14 @@ static void ics_class_init(ObjectClass *klass, void *data)
DeviceClass *dc = DEVICE_CLASS(klass);
ICSStateClass *isc = ICS_CLASS(klass);
-dc->init = ics_realize;
+dc->realize = ics_realize;
dc->vmsd = &vmstate_ics;
dc->reset = ics_reset;
isc->post_load = ics_post_load;
+isc->post_load = ics_post_load;
}
-static TypeInfo ics_info = {
+static const TypeInfo ics_info = {
.name = TYPE_ICS,
.parent = TYPE_DEVICE,
.instance_size = sizeof(ICSState),
@@ -680,8 +684,8 @@ static void xics_cpu_setup(XICSState *icp, PowerPCCPU *cpu)
break;
default:
-fprintf(stderr, "XICS interrupt controller does not support this CPU "
-"bus model\n");
+error_report("XICS interrupt controller does not support this CPU "
+"bus model");
abort();
}
}
@@ -690,8 +694,14 @@ static void xics_realize(DeviceState *dev, Error **errp)
{
XICSState *icp = XICS(dev);
ICSState *ics = icp->ics;
+Error *error = NULL;
int i;
+if (!icp->nr_servers) {
+error_setg(errp, "Number of servers needs to be greater 0");
+return;
+}
+
/* Registration of global state belongs into realize */
spapr_rtas_register("ibm,set-xive", rtas_set_xive);
spapr_rtas_register("ibm,get-xive", rtas_get_xive);
@@ -706,7 +716,11 @@ static void xics_realize(DeviceState *dev, Error **errp)
ics->nr_irqs = icp->nr_irqs;
ics->offset = XICS_IRQ_BASE;
ics->icp = icp;
-qdev_init_nofail(DEVICE(ics));
+object_property_set_bool(OBJECT(icp->ics), true, "realized", &error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
icp->ss = g_malloc0(icp->nr_servers*sizeof(ICPState));
for (i = 0; i < icp->nr_servers; i++) {
@@ -714,7 +728,11 @@ static void xics_realize(DeviceState *dev, Error **errp)
object_initialize(&icp->ss[i], TYPE_ICP);
snprintf(buffer, sizeof(buffer), "icp[%d]", i);
object_property_add_child(OBJECT(icp), buffer, OBJECT(&icp->ss[i]),
NULL);
-qdev_init_nofail(DEVICE(&icp->ss[i]));
+object_property_set_bool(OBJECT(&icp->ss[i]), true, "realized",
&error);
+if (error) {
+error_propagate(errp, error);
+return;
+}
}
}
@@ -735,12 +753,12 @@ static Property xics_properties[] = {
static void xics_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
-XICSStateClass *k = XICS_CLASS(oc);
+XICSStateClass *xsc = XICS_CLASS(oc);
dc->realize = xics_realize;
dc->props = xics_properties;
dc->reset = xics_reset;
-k->cpu_setup = xics_cpu_setup;
+xsc->cpu_setup = xics_cpu_setup;
}
static const TypeInfo xics_info = {
--
1.8.3.2
[Qemu-devel] [PATCH v3 1/8] target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN
From: David Gibson
Recent PowerKVM allows the kernel to intercept some RTAS calls from the
guest directly. This is used to implement the more efficient in-kernel
XICS for example. qemu is still responsible for assigning the RTAS token
numbers however, and needs to tell the kernel which RTAS function name is
assigned to a given token value. This patch adds a convenience wrapper for
the KVM_PPC_RTAS_DEFINE_TOKEN ioctl() which is used for this purpose.
Signed-off-by: David Gibson
Signed-off-by: Alexey Kardashevskiy
---
target-ppc/kvm.c | 14 ++
target-ppc/kvm_ppc.h | 7 +++
2 files changed, 21 insertions(+)
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index eea8c09..ab46aaa 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1792,6 +1792,20 @@ static int kvm_ppc_register_host_cpu_type(void)
return 0;
}
+int kvmppc_define_rtas_token(uint32_t token, const char *function)
+{
+struct kvm_rtas_token_args args = {
+.token = token,
+};
+
+if (!kvm_check_extension(kvm_state, KVM_CAP_PPC_RTAS)) {
+return -ENOENT;
+}
+
+strncpy(args.name, function, sizeof(args.name));
+
+return kvm_vm_ioctl(kvm_state, KVM_PPC_RTAS_DEFINE_TOKEN, &args);
+}
int kvmppc_get_htab_fd(bool write)
{
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index 4ae7bf2..12564ef 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -38,6 +38,7 @@ uint64_t kvmppc_rma_size(uint64_t current_size, unsigned int
hash_shift);
#endif /* !CONFIG_USER_ONLY */
int kvmppc_fixup_cpu(PowerPCCPU *cpu);
bool kvmppc_has_cap_epr(void);
+int kvmppc_define_rtas_token(uint32_t token, const char *function);
int kvmppc_get_htab_fd(bool write);
int kvmppc_save_htab(QEMUFile *f, int fd, size_t bufsize, int64_t max_ns);
int kvmppc_load_htab_chunk(QEMUFile *f, int fd, uint32_t index,
@@ -164,6 +165,12 @@ static inline bool kvmppc_has_cap_epr(void)
return false;
}
+static inline int kvmppc_define_rtas_token(uint32_t token,
+ const char *function)
+{
+return -1;
+}
+
static inline int kvmppc_get_htab_fd(bool write)
{
return -1;
--
1.8.3.2
[Qemu-devel] [PATCH v3 0/8] xics: reworks and in-kernel support
Yet another try with XICS-KVM. v2->v3: Addressed multiple comments from Andreas; Added 2 patches for XICS from Ben - I included them into the series as they are about XICS and they won't rebase automatically if moved before XICS rework so it seemed to me that it would be better to carry them toghether. If it is wrong, please let me know, I'll repost them separately. v1->v2: The main change is this adds "xics-common" parent for emulated XICS and XICS-KVM. And many, many small changes, mostly to address Andreas comments. Migration from XICS to XICS-KVM and vice versa still works. Alexey Kardashevskiy (4): xics: add pre_save/post_load/cpu_setup dispatchers xics: move registration of global state to realize() xics: minor changes and cleanups xics: split to xics and xics-common Benjamin Herrenschmidt (2): xics: Add H_IPOLL implementation xics: Implement H_XIRR_X David Gibson (2): target-ppc: Add helper for KVM_PPC_RTAS_DEFINE_TOKEN xics-kvm: Support for in-kernel XICS interrupt controller default-configs/ppc64-softmmu.mak | 1 + hw/intc/Makefile.objs | 1 + hw/intc/xics.c| 358 +-- hw/intc/xics_kvm.c| 492 ++ hw/ppc/spapr.c| 27 ++- include/hw/ppc/spapr.h| 3 +- include/hw/ppc/xics.h | 68 +- target-ppc/kvm.c | 14 ++ target-ppc/kvm_ppc.h | 7 + 9 files changed, 894 insertions(+), 77 deletions(-) create mode 100644 hw/intc/xics_kvm.c -- 1.8.3.2
Re: [Qemu-devel] [PATCH 0/2 v4] kvm irqfd: support msimessage to irq translation in PHB
On 08/07/2013 06:51 PM, Alexey Kardashevskiy wrote: > Yet another try to push IRQFD support for sPAPR. > This includes rework for QEMU and enablement for sPAPR PCI. Ping, anyone, please? > Alexey Kardashevskiy (2): > kvm irqfd: support msimessage to irq translation in PHB > pseries: enable irqfd for pci > > hw/i386/kvm/pci-assign.c | 4 ++-- > hw/intc/xics_kvm.c | 5 + > hw/misc/vfio.c | 4 ++-- > hw/pci/pci.c | 9 + > hw/ppc/spapr_pci.c | 6 ++ > hw/virtio/virtio-pci.c | 2 +- > include/hw/pci/pci.h | 2 ++ > include/hw/pci/pci_bus.h | 1 + > kvm-all.c| 3 +++ > 9 files changed, 31 insertions(+), 5 deletions(-) > -- Alexey
[Qemu-devel] [RFC PATCH v4] powerpc: add PVR mask support
IBM POWERPC processors encode PVR as a CPU family in higher 16 bits and
a CPU version in lower 16 bits. Since there is no significant change
in behavior between versions, there is no point to add every single CPU
version in QEMU's CPU list. Also, new CPU versions of already supported
CPU won't break the existing code.
This does the following:
1. add a PVR mask support for a CPU family (in this patch for POWER7 only);
2. make CPU family not abstract;
3. add a @pvr_default (probably bad name) - the idea when QEMU instantiates
POWERPC CPU from a CPU family class, this value will be written to PVR
before the guest starts; KVM uses this to pass the actual PVR value to
the guest if QEMU was started with -cpu host.
As CPU family class name for POWER7 is "POWER7-family", there is no need
to touch aliases.
Cc: Andreas Färber
Signed-off-by: Alexey Kardashevskiy
---
This does not pretend to be the final valid patch which can go to any tree
(at least because it does need a POWER7+ family difinition and some bits
for POWER8 family), it is me again asking stupid question in order to
reduce my ignorance and get some understanding if anyone going to care of
the PVR masks problem. Thank you for comments.
ps. :)
---
Changes:
v4:
* removed bogus layer from hierarchy
v3:
* renamed macros to describe the functionality better
* added default PVR value for the powerpc cpu family (what alias used to do)
v2:
* aliases are replaced with another level in class hierarchy
---
target-ppc/cpu-models.c | 2 ++
target-ppc/cpu-models.h | 7 +++
target-ppc/cpu-qom.h| 2 ++
target-ppc/kvm.c| 2 ++
target-ppc/translate_init.c | 9 +++--
5 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/target-ppc/cpu-models.c b/target-ppc/cpu-models.c
index 8dea560..5ae88a5 100644
--- a/target-ppc/cpu-models.c
+++ b/target-ppc/cpu-models.c
@@ -44,6 +44,8 @@
PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc); \
\
pcc->pvr = _pvr; \
+pcc->pvr_default = 0; \
+pcc->pvr_mask = CPU_POWERPC_DEFAULT_MASK; \
pcc->svr = _svr; \
dc->desc = _desc; \
} \
diff --git a/target-ppc/cpu-models.h b/target-ppc/cpu-models.h
index d9145d1..2233053 100644
--- a/target-ppc/cpu-models.h
+++ b/target-ppc/cpu-models.h
@@ -39,6 +39,7 @@ extern PowerPCCPUAlias ppc_cpu_aliases[];
/*/
/* PVR definitions for most known PowerPC*/
enum {
+CPU_POWERPC_DEFAULT_MASK = 0x,
/* PowerPC 401 family */
/* Generic PowerPC 401 */
#define CPU_POWERPC_401 CPU_POWERPC_401G2
@@ -557,6 +558,12 @@ enum {
CPU_POWERPC_POWER7_v23 = 0x003F0203,
CPU_POWERPC_POWER7P_v21= 0x004A0201,
CPU_POWERPC_POWER8_v10 = 0x004B0100,
+CPU_POWERPC_POWER7 = 0x003F,
+CPU_POWERPC_POWER7_MASK= 0x,
+CPU_POWERPC_POWER7P= 0x004A,
+CPU_POWERPC_POWER7P_MASK = 0x,
+CPU_POWERPC_POWER8 = 0x004B,
+CPU_POWERPC_POWER8_MASK= 0x,
CPU_POWERPC_970= 0x00390202,
CPU_POWERPC_970FX_v10 = 0x00391100,
CPU_POWERPC_970FX_v20 = 0x003C0200,
diff --git a/target-ppc/cpu-qom.h b/target-ppc/cpu-qom.h
index f3c710a..a1a712c 100644
--- a/target-ppc/cpu-qom.h
+++ b/target-ppc/cpu-qom.h
@@ -54,6 +54,8 @@ typedef struct PowerPCCPUClass {
void (*parent_reset)(CPUState *cpu);
uint32_t pvr;
+uint32_t pvr_default;
+uint32_t pvr_mask;
uint32_t svr;
uint64_t insns_flags;
uint64_t insns_flags2;
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 30a870e..315e499 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -1731,6 +1731,8 @@ static void kvmppc_host_cpu_class_init(ObjectClass *oc,
void *data)
uint32_t dcache_size = kvmppc_read_int_cpu_dt("d-cache-size");
uint32_t icache_size = kvmppc_read_int_cpu_dt("i-cache-size");
+pcc->pvr_default = mfpvr();
+
/* Now fix up the class with information we can query from the host */
if (vmx != -1) {
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 13b290c..dfe398d 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3104,7 +3104,6 @@ static int check_pow_hid0_74xx (CPUPPCState *env)
glue(glue(ppc_, _name), _cpu_family_type_info) = { \
.name = stringify(_name) "-family-" TYPE_POWERPC_CPU, \
.parent = TYPE_
[Qemu-devel] [PATCH v3] spapr-pci: fix config space access to support bridges
spapr-pci config space accessors use find_dev() to find a PCI device.
However find_dev() only searched on a primary bus and did not do
recursive search through secondary buses so config space access was not
possible for devices other that on a primary bus.
This fixed find_dev() by using the PCI API pci_find_device() function.
This effectively enabled pci bridges on spapr.
Signed-off-by: Alexey Kardashevskiy
---
Changes:
v3:
* added temporary variable for bus number
v2:
* fixed coding style
* config space access traces moved out
---
hw/ppc/spapr_pci.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 1ca35a0..65be265 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -65,22 +65,14 @@ static PCIDevice *find_dev(sPAPREnvironment *spapr,
uint64_t buid,
{
sPAPRPHBState *sphb = find_phb(spapr, buid);
PCIHostState *phb = PCI_HOST_BRIDGE(sphb);
-BusState *bus = BUS(phb->bus);
-BusChild *kid;
+int bus_num = (config_addr >> 16) & 0xFF;
int devfn = (config_addr >> 8) & 0xFF;
if (!phb) {
return NULL;
}
-QTAILQ_FOREACH(kid, &bus->children, sibling) {
-PCIDevice *dev = (PCIDevice *)kid->child;
-if (dev->devfn == devfn) {
-return dev;
-}
-}
-
-return NULL;
+return pci_find_device(phb->bus, bus_num, devfn);
}
static uint32_t rtas_pci_cfgaddr(uint32_t arg)
--
1.8.3.2
[Qemu-devel] [Bug 1180777] Re: Windows 7 VM freeze on Ubuntu 12.04 KVM
Hi, I reported the #1212051 (https://bugs.launchpad.net/ubuntu/+source/qemu- kvm/+bug/1212051) bug with Windows XP, but reading this case i think it could be the same issue. I connect via RDP to my windows XP VM and after a while it seems to freeze, then, I connect via VNC an without doing anything the communications are restored between the VM and the outside world. So i can connect again with RDP. Even more, if i leave an open connection with VNC (minimized because is more slow than RDP), connecting via RDP has no trouble and no problem of freeze (lost of communications) occurs. f3a97, Could you do this test and tell if you have the same experience than i?, If so, my bug is the same of this. Thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1180777 Title: Windows 7 VM freeze on Ubuntu 12.04 KVM Status in QEMU: New Status in “qemu-kvm” package in Ubuntu: Confirmed Bug description: Hi, I have recently setup a Windows 7 VM on KVM and started using it through remote desktop. What happens is that, after some hours of usage, the remote desktop connection freezes. I thought it was a remmina bug, as the it was enough to kill and restart it to successfully connect again to the VM. However, today I've switched to a different RDP client (2X Client chromium app) and the freeze just happened again! Some information: - the host and the VM are completely idle when the freeze occurs - I've tried sniffing the network packets toward the RDP port during the freeze and found that the client is sending packets but no packet is sent back Could this be a KVM issue? How can I further debug this one (I expect the freeze to happen again...)? ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: kvm 1:84+dfsg-0ubuntu16+1.0+noroms+0ubuntu14.8 ProcVersionSignature: Ubuntu 3.2.0-41.66-generic 3.2.42 Uname: Linux 3.2.0-41-generic x86_64 ApportVersion: 2.0.1-0ubuntu17.2 Architecture: amd64 Date: Thu May 16 14:12:40 2013 MachineType: Hewlett-Packard HP ProBook 4520s MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-41-generic root=UUID=D2E20BC3E20BAAB5 loop=/hostname/disks/root.disk ro quiet splash vt.handoff=7 SourcePackage: qemu-kvm UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 08/26/2010 dmi.bios.vendor: Hewlett-Packard dmi.bios.version: 68AZZ Ver. F.0A dmi.board.name: 1411 dmi.board.vendor: Hewlett-Packard dmi.board.version: KBC Version 57.30 dmi.chassis.type: 10 dmi.chassis.vendor: Hewlett-Packard dmi.modalias: dmi:bvnHewlett-Packard:bvr68AZZVer.F.0A:bd08/26/2010:svnHewlett-Packard:pnHPProBook4520s:pvr:rvnHewlett-Packard:rn1411:rvrKBCVersion57.30:cvnHewlett-Packard:ct10:cvr: dmi.product.name: HP ProBook 4520s dmi.sys.vendor: Hewlett-Packard To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1180777/+subscriptions
Re: [Qemu-devel] [PATCH v2 1/4] vmdk: fix L1 and L2 table size in vmdk3 open
On Sun, 08/18 17:19, Paolo Bonzini wrote: > Il 13/08/2013 03:21, Fam Zheng ha scritto: > > VMDK3 header has the field l1dir_size, but vmdk_open_vmdk3 hardcoded the > > value. This patch honors the header field. > > > > And the L2 table size is 4096 according to VMDK spec[1], instead of > > 1 << 9 (512). > > I'm not sure from the VMDK spec that _only_ 4096 is supported for VMDK3 > files. The way I read it, VMDK3 files in hosted products are supposed > to have 2K grain tables (as specified by vmdk_open_vmdk3). I presume "COWD" is only specified in "ESXi Host Sparse Extents" section, which is also in practice the only known use case to me. There it says "Grain tables have 4096 entries." I think you meant 2KB grain table specified in section "Hosted Sparse Extent Metadata", with 512 entries. If so, it should be for VMDK4 with "KDMV" magic bytes, so doesn't affect "COWD". Fam > > Perhaps we can check if L1size * 64 is enough to cover the whole file, > and if not use 4096? > > Paolo > > > [1]: > > http://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf?src=vmdk >
[Qemu-devel] [PATCH] kvm: shoten the parameter list for get_real_device()
get_real_device() has 5 parameters with the last 4 is contained in the first
structure.
This patch removes the last 4 parameters and directly use them from the first
parameter.
Signed-off-by: Wei Yang
---
hw/i386/kvm/pci-assign.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/i386/kvm/pci-assign.c b/hw/i386/kvm/pci-assign.c
index 5618173..011764f 100644
--- a/hw/i386/kvm/pci-assign.c
+++ b/hw/i386/kvm/pci-assign.c
@@ -568,8 +568,7 @@ static int get_real_device_id(const char *devpath, uint16_t
*val)
return get_real_id(devpath, "device", val);
}
-static int get_real_device(AssignedDevice *pci_dev, uint16_t r_seg,
- uint8_t r_bus, uint8_t r_dev, uint8_t r_func)
+static int get_real_device(AssignedDevice *pci_dev)
{
char dir[128], name[128];
int fd, r = 0, v;
@@ -582,7 +581,8 @@ static int get_real_device(AssignedDevice *pci_dev,
uint16_t r_seg,
dev->region_number = 0;
snprintf(dir, sizeof(dir), "/sys/bus/pci/devices/%04x:%02x:%02x.%x/",
- r_seg, r_bus, r_dev, r_func);
+ pci_dev->host.domain, pci_dev->host.bus,
+ pci_dev->host.slot, pci_dev->host.function);
snprintf(name, sizeof(name), "%sconfig", dir);
@@ -1769,8 +1769,7 @@ static int assigned_initfn(struct PCIDevice *pci_dev)
memcpy(dev->emulate_config_write, dev->emulate_config_read,
sizeof(dev->emulate_config_read));
-if (get_real_device(dev, dev->host.domain, dev->host.bus,
-dev->host.slot, dev->host.function)) {
+if (get_real_device(dev)) {
error_report("pci-assign: Error: Couldn't get real device (%s)!",
dev->dev.qdev.id);
goto out;
--
1.7.5.4
[Qemu-devel] [Bug 688085] Re: Guest kernel hang during boot when KVM is active on i386 host
This release has reached end-of-life [0]. [0] https://wiki.ubuntu.com/Releases ** Changed in: linux (Ubuntu Maverick) Status: New => Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/688085 Title: Guest kernel hang during boot when KVM is active on i386 host Status in meego project: Fix Released Status in QEMU: Fix Released Status in qemu-kvm: Fix Released Status in “kvm” package in Ubuntu: Invalid Status in “linux” package in Ubuntu: Fix Released Status in “qemu” package in Ubuntu: Invalid Status in “qemu-kvm” package in Ubuntu: Invalid Status in “kvm” source package in Maverick: New Status in “linux” source package in Maverick: Invalid Status in “qemu” source package in Maverick: New Status in “qemu-kvm” source package in Maverick: New Bug description: Binary package hint: qemu Guest kernel hang during boot when KVM is active on i386 host See the patch. http://www.spinics.net/lists/kvm/msg40800.html How to reproduce: 1. install Maversick x86 (not amd64) 2. ensure you have kvm support in processor 3. kvm -kernel /boot/initrd.img-2.6.35-24-generic-pae 4. kvm -no-kvm -kernel /boot/initrd.img-2.6.35-24-generic-pae works OK. SRU Justification: Impact: Users cannot boot KVM guests on i386 hosts 2. How bug addressed: The upstream commit at http://www.spinics.net/lists/kvm/msg40800.html fixed it 3. Patch: A kernel patch is attached to this bug. 4. Reproduce: boot an i386 kernel on a kvm-capable host. Try to boot a kvm guest. 5. Regression potential: since this is cherrypicking a commit from a future upstream which had already been changed, regression is possible. However if there is a regression, it should only affect users of KVM on i386 hosts, which currently fail anyway. To manage notifications about this bug go to: https://bugs.launchpad.net/meego/+bug/688085/+subscriptions
Re: [Qemu-devel] [PATCH for-1.6] adlib: sort offsets in portio registration
Ping.
CCing stable too.
Hervé
Hervé Poussineau a écrit :
This fixes the following assert when -device adlib is used:
ioport.c:240: portio_list_add: Assertion `pio->offset >= off_last' failed.
Signed-off-by: Hervé Poussineau
---
hw/audio/adlib.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/audio/adlib.c b/hw/audio/adlib.c
index 0421d47..db4a953 100644
--- a/hw/audio/adlib.c
+++ b/hw/audio/adlib.c
@@ -284,9 +284,9 @@ static void Adlib_fini (AdlibState *s)
}
static MemoryRegionPortio adlib_portio_list[] = {
-{ 0x388, 4, 1, .read = adlib_read, .write = adlib_write, },
{ 0, 4, 1, .read = adlib_read, .write = adlib_write, },
{ 0, 2, 1, .read = adlib_read, .write = adlib_write, },
+{ 0x388, 4, 1, .read = adlib_read, .write = adlib_write, },
PORTIO_END_OF_LIST(),
};
Re: [Qemu-devel] [PATCH for-1.6] isa: fix documentation of isa_register_portio_list
Ping. Hervé Poussineau a écrit : Signed-off-by: Hervé Poussineau --- include/hw/isa/isa.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/hw/isa/isa.h b/include/hw/isa/isa.h index 495bcf3..fa45a5b 100644 --- a/include/hw/isa/isa.h +++ b/include/hw/isa/isa.h @@ -78,7 +78,7 @@ void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start); * @dev: the ISADevice against which these are registered; may be NULL. * @start: the base I/O port against which the portio->offset is applied. * @portio: the ports, sorted by offset. - * @opaque: passed into the old_portio callbacks. + * @opaque: passed into the portio callbacks. * @name: passed into memory_region_init_io. */ void isa_register_portio_list(ISADevice *dev, uint16_t start,
Re: [Qemu-devel] [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
Am 18.08.2013 20:23, schrieb Liu, Jinsong: > From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001 > From: Liu Jinsong > Date: Mon, 19 Aug 2013 09:33:30 +0800 > Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL > > This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623 > > IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to > cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs > or kvm_get_msrs. > > Signed-off-by: Liu Jinsong > --- > target-i386/kvm.c | 16 ++-- > 1 files changed, 14 insertions(+), 2 deletions(-) > Hello, please check your patch with scripts/checkpatch.pl before sending it to the list. For boolean operands, the boolean or (||) is better than the bitwise or (|). Regards, Stefan
[Qemu-devel] [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
>From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Mon, 19 Aug 2013 09:33:30 +0800
Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623
IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.
Signed-off-by: Liu Jinsong
---
target-i386/kvm.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 84ac00a..7facbfe 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -65,6 +65,7 @@ static bool has_msr_star;
static bool has_msr_hsave_pa;
static bool has_msr_tsc_adjust;
static bool has_msr_tsc_deadline;
+static bool has_msr_feature_control;
static bool has_msr_async_pf_en;
static bool has_msr_pv_eoi_en;
static bool has_msr_misc_enable;
@@ -644,6 +645,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
qemu_add_vm_change_state_handler(cpu_update_state, env);
+c = cpuid_find_entry(&cpuid_data.cpuid, 1, 0);
+if (c)
+has_msr_feature_control = !!(c->ecx & CPUID_EXT_VMX) |
+ !!(c->ecx & CPUID_EXT_SMX);
+
cpuid_data.cpuid.padding = 0;
r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, &cpuid_data);
if (r) {
@@ -1121,7 +1127,10 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
if (hyperv_vapic_recommended()) {
kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
}
-kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
env->msr_ia32_feature_control);
+if (has_msr_feature_control) {
+kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
+ env->msr_ia32_feature_control);
+}
}
if (env->mcg_cap) {
int i;
@@ -1346,7 +1355,9 @@ static int kvm_get_msrs(X86CPU *cpu)
if (has_msr_misc_enable) {
msrs[n++].index = MSR_IA32_MISC_ENABLE;
}
-msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+if (has_msr_feature_control) {
+msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+}
if (!env->tsc_valid) {
msrs[n++].index = MSR_IA32_TSC;
@@ -1447,6 +1458,7 @@ static int kvm_get_msrs(X86CPU *cpu)
break;
case MSR_IA32_FEATURE_CONTROL:
env->msr_ia32_feature_control = msrs[i].data;
+break;
default:
if (msrs[i].index >= MSR_MC0_CTL &&
msrs[i].index < MSR_MC0_CTL + (env->mcg_cap & 0xff) * 4) {
--
1.7.1
0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
Description: 0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
[Qemu-devel] (no subject)
>From 1273f8b2e5464ec987facf9942fd3ccc0b69087e Mon Sep 17 00:00:00 2001
From: Liu Jinsong
Date: Mon, 19 Aug 2013 09:33:30 +0800
Subject: [PATCH] qemu-kvm bugfix for IA32_FEATURE_CONTROL
This patch is to fix the bug https://bugs.launchpad.net/qemu-kvm/+bug/1207623
IA32_FEATURE_CONTROL is pointless if not expose VMX or SMX bits to
cpuid.1.ecx of vcpu. Current qemu-kvm will error return when kvm_put_msrs
or kvm_get_msrs.
Signed-off-by: Liu Jinsong
---
target-i386/kvm.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 84ac00a..7facbfe 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -65,6 +65,7 @@ static bool has_msr_star;
static bool has_msr_hsave_pa;
static bool has_msr_tsc_adjust;
static bool has_msr_tsc_deadline;
+static bool has_msr_feature_control;
static bool has_msr_async_pf_en;
static bool has_msr_pv_eoi_en;
static bool has_msr_misc_enable;
@@ -644,6 +645,11 @@ int kvm_arch_init_vcpu(CPUState *cs)
qemu_add_vm_change_state_handler(cpu_update_state, env);
+c = cpuid_find_entry(&cpuid_data.cpuid, 1, 0);
+if (c)
+has_msr_feature_control = !!(c->ecx & CPUID_EXT_VMX) |
+ !!(c->ecx & CPUID_EXT_SMX);
+
cpuid_data.cpuid.padding = 0;
r = kvm_vcpu_ioctl(cs, KVM_SET_CPUID2, &cpuid_data);
if (r) {
@@ -1121,7 +1127,10 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
if (hyperv_vapic_recommended()) {
kvm_msr_entry_set(&msrs[n++], HV_X64_MSR_APIC_ASSIST_PAGE, 0);
}
-kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
env->msr_ia32_feature_control);
+if (has_msr_feature_control) {
+kvm_msr_entry_set(&msrs[n++], MSR_IA32_FEATURE_CONTROL,
+ env->msr_ia32_feature_control);
+}
}
if (env->mcg_cap) {
int i;
@@ -1346,7 +1355,9 @@ static int kvm_get_msrs(X86CPU *cpu)
if (has_msr_misc_enable) {
msrs[n++].index = MSR_IA32_MISC_ENABLE;
}
-msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+if (has_msr_feature_control) {
+msrs[n++].index = MSR_IA32_FEATURE_CONTROL;
+}
if (!env->tsc_valid) {
msrs[n++].index = MSR_IA32_TSC;
@@ -1447,6 +1458,7 @@ static int kvm_get_msrs(X86CPU *cpu)
break;
case MSR_IA32_FEATURE_CONTROL:
env->msr_ia32_feature_control = msrs[i].data;
+break;
default:
if (msrs[i].index >= MSR_MC0_CTL &&
msrs[i].index < MSR_MC0_CTL + (env->mcg_cap & 0xff) * 4) {
--
1.7.1
0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
Description: 0001-qemu-kvm-bugfix-for-IA32_FEATURE_CONTROL.patch
[Qemu-devel] [PATCH] misc: Fix some typos in names and comments
Most typos were found using a modified version of codespell:
accross -> across
issueing -> issuing
TICNT_THRESHHOLD -> TICNT_THRESHOLD
bandwith -> bandwidth
VCARD_7816_PROPIETARY -> VCARD_7816_PROPRIETARY
occured -> occurred
gaurantee -> guarantee
sofware -> software
Signed-off-by: Stefan Weil
---
Existing violations of the QEMU coding style (tabulators)
were not fixed, so checkpatch.pl reports six errors.
Regards,
Stefan
block/backup.c |2 +-
hw/s390x/css.c |2 +-
hw/timer/exynos4210_rtc.c|4 ++--
include/hw/bt.h |8
libcacard/card_7816.c|2 +-
libcacard/card_7816t.h |2 +-
linux-headers/asm-powerpc/epapr_hcalls.h |4 ++--
migration-rdma.c |6 +++---
8 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/block/backup.c b/block/backup.c
index 6ae8a05..a55a960 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -290,7 +290,7 @@ static void coroutine_fn backup_run(void *opaque)
for (i = 0; i < BACKUP_SECTORS_PER_CLUSTER;) {
/* bdrv_co_is_allocated() only returns true/false based
- * on the first set of sectors it comes accross that
+ * on the first set of sectors it comes across that
* are are all in the same state.
* For that reason we must verify each sector in the
* backup cluster length. We end up copying more than
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 93b0b97..101da63 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -124,7 +124,7 @@ static void sch_handle_clear_func(SubchDev *sch)
/* Path management: In our simple css, we always choose the only path. */
path = 0x80;
-/* Reset values prior to 'issueing the clear signal'. */
+/* Reset values prior to 'issuing the clear signal'. */
p->lpum = 0;
p->pom = 0xff;
s->flags &= ~SCSW_FLAGS_MASK_PNO;
diff --git a/hw/timer/exynos4210_rtc.c b/hw/timer/exynos4210_rtc.c
index 3f2c8c5..026f81a 100644
--- a/hw/timer/exynos4210_rtc.c
+++ b/hw/timer/exynos4210_rtc.c
@@ -67,7 +67,7 @@
#define CURTICNT0x0090
#define TICK_TIMER_ENABLE 0x0100
-#define TICNT_THRESHHOLD2
+#define TICNT_THRESHOLD 2
#define RTC_ENABLE 0x0001
@@ -429,7 +429,7 @@ static void exynos4210_rtc_write(void *opaque, hwaddr
offset,
s->reg_rtccon = value;
break;
case TICCNT:
-if (value > TICNT_THRESHHOLD) {
+if (value > TICNT_THRESHOLD) {
s->reg_ticcnt = value;
} else {
fprintf(stderr,
diff --git a/include/hw/bt.h b/include/hw/bt.h
index 830af94..3f365bc 100644
--- a/include/hw/bt.h
+++ b/include/hw/bt.h
@@ -640,8 +640,8 @@ typedef struct {
#define OCF_SETUP_SYNC_CONN0x0028
typedef struct {
uint16_t handle;
-uint32_t tx_bandwith;
-uint32_t rx_bandwith;
+uint32_t tx_bandwidth;
+uint32_t rx_bandwidth;
uint16_t max_latency;
uint16_t voice_setting;
uint8_tretrans_effort;
@@ -652,8 +652,8 @@ typedef struct {
#define OCF_ACCEPT_SYNC_CONN_REQ 0x0029
typedef struct {
bdaddr_t bdaddr;
-uint32_t tx_bandwith;
-uint32_t rx_bandwith;
+uint32_t tx_bandwidth;
+uint32_t rx_bandwidth;
uint16_t max_latency;
uint16_t voice_setting;
uint8_tretrans_effort;
diff --git a/libcacard/card_7816.c b/libcacard/card_7816.c
index 8d06326..c28bb60 100644
--- a/libcacard/card_7816.c
+++ b/libcacard/card_7816.c
@@ -232,7 +232,7 @@ vcard_apdu_set_class(VCardAPDU *apdu) {
case 0xf0:
default:
apdu->a_gen_type =
-(apdu->a_cla == 0xff) ? VCARD_7816_PTS : VCARD_7816_PROPIETARY;
+(apdu->a_cla == 0xff) ? VCARD_7816_PTS : VCARD_7816_PROPRIETARY;
break;
}
return VCARD7816_STATUS_SUCCESS;
diff --git a/libcacard/card_7816t.h b/libcacard/card_7816t.h
index 9333285..8eef0ce 100644
--- a/libcacard/card_7816t.h
+++ b/libcacard/card_7816t.h
@@ -43,7 +43,7 @@ typedef enum {
VCARD_7816_ISO,
VCARD_7816_RFU,
VCARD_7816_PTS,
-VCARD_7816_PROPIETARY
+VCARD_7816_PROPRIETARY
} VCardAPDUType;
diff --git a/linux-headers/asm-powerpc/epapr_hcalls.h
b/linux-headers/asm-powerpc/epapr_hcalls.h
index 06f7247..33b3f89 100644
--- a/linux-headers/asm-powerpc/epapr_hcalls.h
+++ b/linux-headers/asm-powerpc/epapr_hcalls.h
@@ -78,7 +78,7 @@
#define EV_SUCCESS 0
#define EV_EPERM 1 /* Operation not permitted */
#define EV_ENOENT 2 /* Entry Not Found */
-#define EV_EIO 3 /* I/O error occured */
+#define EV_EIO 3 /* I/O error occurred */
#define EV_EAGAIN 4 /* The operation had insufficient
Re: [Qemu-devel] [PATCH] powerpc iommu: enable multiple TCE requests
Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto:
> With KVM, we could fall back to the qemu implementation
>> + * when KVM doesn't support them, but that would be much slower
>> + * than just using the KVM implementations of the single TCE
>> + * hypercalls. */
>> +if (kvmppc_spapr_use_multitce()) {
>> +_FDT((fdt_property(fdt, "ibm,hypertas-functions", hypertas_propm,
>> + sizeof(hypertas_propm;
>> +} else {
>> +_FDT((fdt_property(fdt, "ibm,hypertas-functions", hypertas_prop,
>> + sizeof(hypertas_prop;
>> +}
This prevents migration from newer kernel to older kernel. Can you
ensure that the fallback to the QEMU implementation works, even though
it is not used in practice?
Paolo
Re: [Qemu-devel] [PATCH v2 1/4] vmdk: fix L1 and L2 table size in vmdk3 open
Il 13/08/2013 03:21, Fam Zheng ha scritto: > VMDK3 header has the field l1dir_size, but vmdk_open_vmdk3 hardcoded the > value. This patch honors the header field. > > And the L2 table size is 4096 according to VMDK spec[1], instead of > 1 << 9 (512). I'm not sure from the VMDK spec that _only_ 4096 is supported for VMDK3 files. The way I read it, VMDK3 files in hosted products are supposed to have 2K grain tables (as specified by vmdk_open_vmdk3). Perhaps we can check if L1size * 64 is enough to cover the whole file, and if not use 4096? Paolo > [1]: > http://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf?src=vmdk
Re: [Qemu-devel] [PATCH v2 4/4] timer: make qemu_clock_enable sync between disable and timer's cb
Il 14/08/2013 02:34, liu ping fan ha scritto:
> On Tue, Aug 13, 2013 at 10:53 PM, Paolo Bonzini wrote:
>>
>> Il 13/08/2013 07:43, Liu Ping Fan ha scritto:
>>> After disabling the QemuClock, we should make sure that no QemuTimers
>>> are still in flight. To implement that with light overhead, we resort
>>> to QemuEvent. The caller of disabling will wait on QemuEvent of each
>>> timerlist.
>>>
>>> Note, qemu_clock_enable(foo,false) can _not_ be called from timer's cb.
>>> And the callers of qemu_clock_enable() should be sync by themselves,
>>> not protected by this patch.
>>>
>>> Signed-off-by: Liu Ping Fan
>>> ---
>>> include/qemu/timer.h | 4
>>> qemu-timer.c | 53
>>> +++-
>>> 2 files changed, 56 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/qemu/timer.h b/include/qemu/timer.h
>>> index 829c005..2b755c9 100644
>>> --- a/include/qemu/timer.h
>>> +++ b/include/qemu/timer.h
>>> @@ -184,6 +184,10 @@ void qemu_clock_notify(QEMUClockType type);
>>> * @enabled: true to enable, false to disable
>>> *
>>> * Enable or disable a clock
>>> + * Disabling the clock will wait for related timerlists to stop
>>> + * executing qemu_run_timers. Thus, this functions should not
>>> + * be used from the callback of a timer that is based on @clock.
>>> + * Doing so would cause a deadlock.
>>> */
>>> void qemu_clock_enable(QEMUClockType type, bool enabled);
>>>
>>> diff --git a/qemu-timer.c b/qemu-timer.c
>>> index 5b9a722..8b32e92 100644
>>> --- a/qemu-timer.c
>>> +++ b/qemu-timer.c
>>> @@ -48,6 +48,12 @@ typedef struct QEMUClock {
>>> QLIST_HEAD(, QEMUTimerList) timerlists;
>>>
>>> NotifierList reset_notifiers;
>>> +/* While the reader holds this lock, it may block on events_list.
>>> + * So the modifier should be carefuly not to reset the event before
>>> + * holding this lock. Otherwise, deadlock.
>>> + */
>>> +QemuMutex events_list_lock;
>>> +GList *events_list;
>>
>> No need for a separate list. Just use the timerlists list; if
>> events_list needs a lock, timerlists needs one too.
>>
> Here is a ugly pattern issue, we hold events_list_lock and wait for
> QemuEvent set. If the modifier reset the QemuEvent and then try to
> hold the events_list_lock, then _deadlock_. To eliminate the
> possibility, using @events_list_lock, and you can see the modifier
> can not reset QemuEvent while trying to own the lock. On the other
> handle, if using lock on timerlists, since many entrance to access the
> lock, we are not sure of avoiding deadlock
But does timerlists need a lock, or does the BQL suffice? If it
doesn't, there is no need for events_list_lock either. Is
qemu_clock_enable called outside the BQL?
Paolo
> Regards,
> Pingfan
>>> int64_t last;
>>>
>>> QEMUClockType type;
>>> @@ -70,6 +76,8 @@ struct QEMUTimerList {
>>> QLIST_ENTRY(QEMUTimerList) list;
>>> QEMUTimerListNotifyCB *notify_cb;
>>> void *notify_opaque;
>>> +/* light weight method to mark the end of timerlist's running */
>>> +QemuEvent *ev;
>>
>> Also no need to malloc this one.
>>
>> Paolo
>>
>>> };
>>>
>>> /**
>>> @@ -90,6 +98,25 @@ static bool timer_expired_ns(QEMUTimer *timer_head,
>>> int64_t current_time)
>>> return timer_head && (timer_head->expire_time <= current_time);
>>> }
>>>
>>> +static QemuEvent *qemu_clock_new_qemu_event(QEMUClock *clock)
>>> +{
>>> +QemuEvent *ev = g_malloc(sizeof(QemuEvent));
>>> +
>>> +qemu_event_init(ev, true);
>>> +qemu_mutex_lock(&clock->events_list_lock);
>>> +clock->events_list = g_list_append(clock->events_list, ev);
>>> +qemu_mutex_unlock(&clock->events_list_lock);
>>> +return ev;
>>> +}
>>> +
>>> +static void qemu_clock_free_qemu_event(QEMUClock *clock, QemuEvent *ev)
>>> +{
>>> +qemu_mutex_lock(&clock->events_list_lock);
>>> +clock->events_list = g_list_remove(clock->events_list, ev);
>>> +qemu_mutex_unlock(&clock->events_list_lock);
>>> +qemu_event_destroy(ev);
>>> +}
>>> +
>>> QEMUTimerList *timerlist_new(QEMUClockType type,
>>> QEMUTimerListNotifyCB *cb,
>>> void *opaque)
>>> @@ -98,6 +125,7 @@ QEMUTimerList *timerlist_new(QEMUClockType type,
>>> QEMUClock *clock = qemu_clock_ptr(type);
>>>
>>> timer_list = g_malloc0(sizeof(QEMUTimerList));
>>> +timer_list->ev = qemu_clock_new_qemu_event(clock);
>>> timer_list->clock = clock;
>>> timer_list->notify_cb = cb;
>>> timer_list->notify_opaque = opaque;
>>> @@ -109,6 +137,7 @@ void timerlist_free(QEMUTimerList *timer_list)
>>> {
>>> assert(!timerlist_has_timers(timer_list));
>>> if (timer_list->clock) {
>>> +qemu_clock_free_qemu_event(timer_list->clock, timer_list->ev);
>>> QLIST_REMOVE(timer_list, list);
>>> }
>>> g_free(timer_list);
>>> @@ -122,6 +151,7 @@ static void qemu_clock_init(QEMUClockType type)
>>> clock->enabled = true;
>>>
Re: [Qemu-devel] [PATCH for-1.6] pc: fix up pc initialization
Il 13/08/2013 17:57, Andreas Färber ha scritto: > Am 13.08.2013 17:27, schrieb Paolo Bonzini: >> All that should happen is that after migration you will not get panic >> notifications on the destination. > > Well, how does the Linux driver cope with pvpanic device present on boot > but not present on panic? ISA PIO is not usually expected to be > hot-unplugged. ;) On panic, the driver does a single "outb". That outb will simply go to the bitbucket. Paolo
Re: [Qemu-devel] [PATCH 1/1] mc146818rtc: correct UIP hold length
Il 14/08/2013 16:10, James Hogan ha scritto:
> The UIP (update in progress) hold time was set to 8 32.768KHz clock
> cycles (around 244uS). However the timing diagram in the datasheet
> (Figure 16) shows that the UIP bit is held for both the update cycle
> time (either 248uS or 1984uS depending on the clock source), and the
> minimum time before update cycle (244uS).
>
> It's clear from periodic_timer_update() that only a 32.768KHz clock
> source is expected, so correct the hold time to 244uS + 1984uS = 73
> 32.768KHz clock cycles.
I am not sure if this time would actually go from t-244us to t+1984us on
real hardware? You could measure this using a divider reset and
sampling PF and UF.
The emulation right now does "instant" updates, which elegantly
sidesteps the problem. :)
> Signed-off-by: James Hogan
> Cc: Andreas Färber
> Cc: Anthony Liguori
> Cc: Igor Mammedov
> Cc: Paolo Bonzini
> Cc: Yang Zhang
> ---
> hw/timer/mc146818rtc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
> index 3c3baac..6000feb 100644
> --- a/hw/timer/mc146818rtc.c
> +++ b/hw/timer/mc146818rtc.c
> @@ -55,7 +55,7 @@
>
> #define RTC_REINJECT_ON_ACK_COUNT 20
> #define RTC_CLOCK_RATE32768
> -#define UIP_HOLD_LENGTH (8 * NSEC_PER_SEC / 32768)
> +#define UIP_HOLD_LENGTH (73 * NSEC_PER_SEC / 32768)
>
> #define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
>
> @@ -597,7 +597,7 @@ static int update_in_progress(RTCState *s)
> }
>
> guest_nsec = get_guest_rtc_ns(s);
> -/* UIP bit will be set at last 244us of every second. */
> +/* UIP bit will be set at last 1984us + 244us of every second. */
> if ((guest_nsec % NSEC_PER_SEC) >= (NSEC_PER_SEC - UIP_HOLD_LENGTH)) {
> return 1;
> }
>
Re: [Qemu-devel] [PATCH 7/7] switch raw block driver from "raw.o" to "raw_bsd.o"
Il 16/08/2013 16:15, Laszlo Ersek ha scritto:
> +static int raw_reopen_prepare(BDRVReopenState *reopen_state,
> + BlockReopenQueue *queue, Error **errp)
> {
> -return bdrv_reopen_prepare(bs->file);
> +BDRVReopenState tmp = *reopen_state;
> +
> +tmp.bs = tmp.bs->file;
> +return bdrv_reopen_prepare(&tmp, queue, errp);
> }
This should just return zero, my fault.
Paolo
Re: [Qemu-devel] [PATCH 0/7] introduce BSD-licensed block driver for "raw"
Il 16/08/2013 16:59, Anthony Liguori ha scritto: > Laszlo Ersek writes: > >> Paolo asked me to write such a driver based on his textual specification >> alone. The first patch captures his email in full, the rest re-quotes >> parts that are being implemented. >> >> The tree compiles at each patch. The series passes "make check-block". >> >> "block/raw.c" is not removed because I wanted to keep it out of my >> series and out of my brain. >> >> Disclaimer: I couldn't care less if the raw block driver was public >> domain or AGPLv3+, as long as it qualifies as free software. I'm only >> trying to do what Paolo asked of me. > > Generally speaking, rewriting parts of QEMU to be !GPL is something I > would strongly, strongly oppose. > > I believe that Paolo had a good reason for this though. The reason is that Christoph said his original version of block/raw.c was meant to be GPLv2-only. I don't care if the file is BSD or LGPLv2+, but most of the block layer is BSD, which is why I went for BSD. It's been a while since I audited the files that would go into libqemublock, but I remember the only problematic files were block/raw.c (unlicensed) and block/vdi.c (GPLv2+). Not having VirtualBox support wouldn't be a big deal. Paolo
Re: [Qemu-devel] [PATCH] pc: cleanup 1.4 compat support
Am 18.08.2013 15:50, schrieb Michael S. Tsirkin: > Make 1.4 compat code call the 1.6 one, reducing > code duplication. Add comment explaining why we can't > make 1.4 call 1.5 as usual. > > Signed-off-by: Michael S. Tsirkin > --- > hw/i386/pc_piix.c | 4 ++-- > hw/i386/pc_q35.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Andreas Färber 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] minimal linux distribution for qemu
good to know. I was working back in 2005-2006 with a company that had a 4MB kernel. At that time I was too inexperienced to work at that level but I thought now I could reproduce their work with some help. Anyhow for the moment I'll go for 256 MB of ram board just so that I don't worry too much about things that are not yet relevant for me. But thanks again for the warning. But since you helped me soo much I have another question. Is it fisible to change the emulator so that I may visualize the following aspects: _ address of the currently executed instruction from the guest system _ if this instruction is a form of jump like call return conditional jump. _ the address or range of addresses read by this instruction _ the address or range of addresses written by this instruction I read some things about the emulator and if I understood it correctly the emulator breaks the instructions of the gurest platform in micro ops which are then executed on the host operation system. So I'm asking the question above in the idea that maybe there is also somekind of reordering of these micro instructions. best regards, dacian From: Rob Landley To: Herbei Dacian Cc: Peter Maydell ; QEmu Devel Sent: Sunday, 18 August 2013, 8:00 Subject: Re: [Qemu-devel] minimal linux distribution for qemu On 08/16/2013 11:17:06 AM, Herbei Dacian wrote: > my system should run in far less memory. something like 2-4MB. > but first I need to have a system running so that I can monitor with > qemu the addresses accessed for read execute and write by the code > run by the emulator. > if I reach that is a real big deal. > dacian Linux 2.6 and later won't run in 2 megs at all. You can trim it down to 4 megs on a nommu system (the page tables take up too much ram otherwise), but won't be able to do much. Really, things like kobjects in the modern kernel take up too much space. Getting anything to work in 4 megs requires diabling all the printk strings at compile time. (The last time I saw somebody do a 4 meg system was CELF in 2006. 32 bit x86.) Look at the uClinux project. Or try to bolt your app onto uboot and run it on the bare metal. Rob
[Qemu-devel] [PATCH] pc: cleanup 1.4 compat support
Make 1.4 compat code call the 1.6 one, reducing
code duplication. Add comment explaining why we can't
make 1.4 call 1.5 as usual.
Signed-off-by: Michael S. Tsirkin
---
hw/i386/pc_piix.c | 4 ++--
hw/i386/pc_q35.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 15c932e..86cfadc 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -272,8 +272,8 @@ static void pc_init_pci_1_4(QEMUMachineInitArgs *args)
{
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
x86_cpu_compat_set_features("Westmere", FEAT_1_ECX, 0,
CPUID_EXT_PCLMULQDQ);
-has_pci_info = false;
-pc_init_pci(args);
+/* 1.5 was special - it enabled pvpanic in builtin machine */
+pc_init_pci_1_6(args);
}
static void pc_init_pci_1_3(QEMUMachineInitArgs *args)
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 09d8183..8d62700 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -239,8 +239,8 @@ static void pc_q35_init_1_4(QEMUMachineInitArgs *args)
{
x86_cpu_compat_set_features("n270", FEAT_1_ECX, 0, CPUID_EXT_MOVBE);
x86_cpu_compat_set_features("Westmere", FEAT_1_ECX, 0,
CPUID_EXT_PCLMULQDQ);
-has_pci_info = false;
-pc_q35_init(args);
+/* 1.5 was special - it enabled pvpanic in builtin machine */
+pc_q35_init_1_6(args);
}
static QEMUMachine pc_q35_machine_v1_6 = {
--
MST
Re: [Qemu-devel] [PATCH v3 0/2] future proof rom loading for cross versiom migration
On Tue, Aug 13, 2013 at 01:43:29AM +0300, Michael S. Tsirkin wrote: > Changes from v2: address comments on v2 by Peter Maydell > - switch from global constant to function > - use memory_region_init_ram instead of _ram_ptr > - disable for 1.6 > > Changes from v1: address comments by Peter Maydell > - drop useless data=data line > - rename target_page_size to migration_page_size to make use clear > Peter, you also suggested somehow hiding this within memory core. > I don't see a clean way to do this without lots of code > changes, I think what I propose here is acceptable for now > and we can always rework APIs without wire format changes. > > Please review, and consider for merging. Ping. Any more comments? Also - which tree can this go in through? Mine? > Original cover letter below. > > > ROM files that are put in FW CFG are copied to guest ram, by BIOS, but > they are not backed by RAM so they don't get migrated. > > Each time we'll change at least two bytes in such a ROM this will break > cross-version migration: since we can migrate after BIOS has read the first > byte but before it has read the second one, getting an inconsistent state. > > This patchset makes QEMU future-proof against such changes. > > Naturally, this only helps for -M 1.6 and up, older machine types > will still have the cross-version migration bug. > > I think this should be applied for 1.6, this way we won't > have this problem from 1.7 and on. > > Michael S. Tsirkin (2): > memory: export migration page size > loader: put FW CFG ROM files into RAM > > arch_init.c | 6 ++ > hw/core/loader.c | 54 > --- > hw/i386/pc_piix.c | 2 ++ > hw/i386/pc_q35.c | 2 ++ > include/exec/memory.h | 1 + > include/hw/loader.h | 1 + > 6 files changed, 63 insertions(+), 3 deletions(-) > > -- > MST >
[Qemu-devel] How to write a backend receiving routine
Hi, all I'm a beginner with QEMU. I'm trying to write a CAN device and also a backend. However while I try to write a backend receiving routine, some thing confuse me. I hope I can get some help here. Actually, I try to figure out how backend udp works at first, also a serial pci acts as a frontend. The functions qemu_set_fd_handler2() and qemu_chr_add_handlers() are used for backend udp and frontend serial pci seperatly to register the necessary routines. In the function main_loop_wait() in main-loop.c will check whether we need to receive some data, if needed, data will be read from backend. Following is the question. I change serial_can_receive1()-hw/serial.c which is registered to test if we need data to return 1 always. So that means we always need data. In main_loop_wait() which actually call main_loop_wait()->os_host_main_loop_wait()->select(), I have checked that before select() called the udp file descriptor has set in rfds. So, if we send some data to the udp backend, the bit in rfds should be set and finally the receive routine we register though qemu_chr_add_handlers() should be called. However, the receiving routine has never been called. I do not know why? And then I try to start QEMU with the following commands, -serial none -chardev udp,id=UDPserial,port=3334 -device pci-serial,chardev=UDPserial and connect it with "nc -u -l -p 3334". Before I insert the linux driver, I try to send some data to qemu, the receiving routine still never be called. After the driver has been inserted, input command "echo test>/dev/ttyS0" then the receiving routine is called. Why? When input "cat /dev/ttyS0" and input some characters in host, the receiving routine is also called. I think this is correct. So what is the correct routine to receive some data from backend? How does this work? Can anyone help me with that. I will appreciate it very much. Thanks, Jin Yang
[Qemu-devel] [PATCH] gtk: Remove unused include statements which are not portable
These include files don't exist for MinGW and are not needed for Linux (and hopefully for other hosts as well), so remove them. Signed-off-by: Stefan Weil --- ui/gtk.c |4 1 file changed, 4 deletions(-) diff --git a/ui/gtk.c b/ui/gtk.c index c38146f..b5f4f0b 100644 --- a/ui/gtk.c +++ b/ui/gtk.c @@ -51,10 +51,6 @@ #include #include #include -#include -#include -#include -#include #include #include "ui/console.h" -- 1.7.10.4
