Re: [Qemu-devel] [PATCH] block/vpc: check that the image has not been truncated
On 10/22/2013 07:43 AM, Peter Lieven wrote:
> this adds a check that a dynamic VHD file has not been
> accidently truncated (e.g. during transfer or upload).
>
> Signed-off-by: Peter Lieven
> ---
> block/vpc.c |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/block/vpc.c b/block/vpc.c
> index 1acc1d4..921364e 100644
> --- a/block/vpc.c
> +++ b/block/vpc.c
> @@ -269,6 +269,13 @@ static int vpc_open(BlockDriverState *bs, QDict
> *options, int flags,
> }
> }
>
> +if (s->free_data_block_offset > bdrv_getlength(bs->file)) {
> +ret = -EINVAL;
> +fprintf(stderr, "block-vpc: free_data_block_offset points after"
> +"the end of file. the image has been
> truncated.\n");
Why fprintf() instead of using the errp argument?
Also, s/afterthe/after the/; s/file\. the/file. The/
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH v1 3/3] x86: move apic_state field from CPUX86State to X86CPU
Signed-off-by: Chen Fan
---
cpu-exec.c| 2 +-
cpus.c| 5 ++---
hw/i386/kvmvapic.c| 8 +++-
hw/i386/pc.c | 17 -
hw/intc/apic.c| 8
target-i386/cpu-qom.h | 4
target-i386/cpu.c | 22 ++
target-i386/cpu.h | 4
target-i386/helper.c | 9 -
target-i386/kvm.c | 23 ++-
target-i386/misc_helper.c | 8
11 files changed, 50 insertions(+), 60 deletions(-)
diff --git a/cpu-exec.c b/cpu-exec.c
index 30cfa2a..2711c58 100644
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -320,7 +320,7 @@ int cpu_exec(CPUArchState *env)
#if !defined(CONFIG_USER_ONLY)
if (interrupt_request & CPU_INTERRUPT_POLL) {
cpu->interrupt_request &= ~CPU_INTERRUPT_POLL;
-apic_poll_irq(env->apic_state);
+apic_poll_irq(x86_env_get_cpu(env)->apic_state);
}
#endif
if (interrupt_request & CPU_INTERRUPT_INIT) {
diff --git a/cpus.c b/cpus.c
index e566297..4ace860 100644
--- a/cpus.c
+++ b/cpus.c
@@ -1383,12 +1383,11 @@ void qmp_inject_nmi(Error **errp)
CPU_FOREACH(cs) {
X86CPU *cpu = X86_CPU(cs);
-CPUX86State *env = &cpu->env;
-if (!env->apic_state) {
+if (!cpu->apic_state) {
cpu_interrupt(cs, CPU_INTERRUPT_NMI);
} else {
-apic_deliver_nmi(env->apic_state);
+apic_deliver_nmi(cpu->apic_state);
}
}
#elif defined(TARGET_S390X)
diff --git a/hw/i386/kvmvapic.c b/hw/i386/kvmvapic.c
index 1c2dbf5..9fa346b 100644
--- a/hw/i386/kvmvapic.c
+++ b/hw/i386/kvmvapic.c
@@ -366,7 +366,7 @@ static int vapic_enable(VAPICROMState *s, X86CPU *cpu)
(((hwaddr)cpu_number) << VAPIC_CPU_SHIFT);
cpu_physical_memory_rw(vapic_paddr + offsetof(VAPICState, enabled),
(void *)&enabled, sizeof(enabled), 1);
-apic_enable_vapic(cpu->env.apic_state, vapic_paddr);
+apic_enable_vapic(cpu->apic_state, vapic_paddr);
s->state = VAPIC_ACTIVE;
@@ -496,12 +496,10 @@ static void vapic_enable_tpr_reporting(bool enable)
};
CPUState *cs;
X86CPU *cpu;
-CPUX86State *env;
CPU_FOREACH(cs) {
cpu = X86_CPU(cs);
-env = &cpu->env;
-info.apic = env->apic_state;
+info.apic = cpu->apic_state;
run_on_cpu(cs, vapic_do_enable_tpr_reporting, &info);
}
}
@@ -697,7 +695,7 @@ static void vapic_write(void *opaque, hwaddr addr, uint64_t
data,
default:
case 4:
if (!kvm_irqchip_in_kernel()) {
-apic_poll_irq(env->apic_state);
+apic_poll_irq(cpu->apic_state);
}
break;
}
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0c313fe..832c9b2 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -169,13 +169,14 @@ void cpu_smm_update(CPUX86State *env)
int cpu_get_pic_interrupt(CPUX86State *env)
{
int intno;
+X86CPU *cpu = x86_env_get_cpu(env);
-intno = apic_get_interrupt(env->apic_state);
+intno = apic_get_interrupt(cpu->apic_state);
if (intno >= 0) {
return intno;
}
/* read the irq from the PIC */
-if (!apic_accept_pic_intr(env->apic_state)) {
+if (!apic_accept_pic_intr(cpu->apic_state)) {
return -1;
}
@@ -187,15 +188,13 @@ static void pic_irq_request(void *opaque, int irq, int
level)
{
CPUState *cs = first_cpu;
X86CPU *cpu = X86_CPU(cs);
-CPUX86State *env = &cpu->env;
DPRINTF("pic_irqs: %s irq %d\n", level? "raise" : "lower", irq);
-if (env->apic_state) {
+if (cpu->apic_state) {
CPU_FOREACH(cs) {
cpu = X86_CPU(cs);
-env = &cpu->env;
-if (apic_accept_pic_intr(env->apic_state)) {
-apic_deliver_pic_intr(env->apic_state, level);
+if (apic_accept_pic_intr(cpu->apic_state)) {
+apic_deliver_pic_intr(cpu->apic_state, level);
}
}
} else {
@@ -890,7 +889,7 @@ DeviceState *cpu_get_current_apic(void)
{
if (current_cpu) {
X86CPU *cpu = X86_CPU(current_cpu);
-return cpu->env.apic_state;
+return cpu->apic_state;
} else {
return NULL;
}
@@ -984,7 +983,7 @@ void pc_cpus_init(const char *cpu_model, DeviceState
*icc_bridge)
}
/* map APIC MMIO area if CPU has APIC */
-if (cpu && cpu->env.apic_state) {
+if (cpu && cpu->apic_state) {
/* XXX: what if the base changes? */
sysbus_mmio_map_overlap(SYS_BUS_DEVICE(icc_bridge), 0,
APIC_DEFAULT_ADDRESS, 0x1000);
diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index fc18600..74edf81 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
@@ -201,7 +201,7 @@ static void apic_external_nmi(APICCommonState *s)
CPUState *cpu;\
int __i, __j, __mask;\
CPU_FOREACH(
[Qemu-devel] [PATCH v1 1/3] Change apic/kvm/xen to use QOM typing
Get rid of unused icc_device_realize()
Signed-off-by: Chen Fan
---
hw/cpu/icc_bus.c| 17 -
hw/i386/kvm/apic.c | 10 --
hw/intc/apic.c | 18 --
hw/intc/apic_common.c | 17 +++--
hw/xen/xen_apic.c | 11 +--
include/hw/cpu/icc_bus.h| 1 -
include/hw/i386/apic_internal.h | 3 ++-
7 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/hw/cpu/icc_bus.c b/hw/cpu/icc_bus.c
index 9a4ea7e..5038836 100644
--- a/hw/cpu/icc_bus.c
+++ b/hw/cpu/icc_bus.c
@@ -38,27 +38,10 @@ static const TypeInfo icc_bus_info = {
.instance_init = icc_bus_init,
};
-
-/* icc-device implementation */
-
-static void icc_device_realize(DeviceState *dev, Error **errp)
-{
-ICCDevice *id = ICC_DEVICE(dev);
-ICCDeviceClass *idc = ICC_DEVICE_GET_CLASS(id);
-
-if (idc->init) {
-if (idc->init(id) < 0) {
-error_setg(errp, "%s initialization failed.",
- object_get_typename(OBJECT(dev)));
-}
-}
-}
-
static void icc_device_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
-dc->realize = icc_device_realize;
dc->bus_type = TYPE_ICC_BUS;
}
diff --git a/hw/i386/kvm/apic.c b/hw/i386/kvm/apic.c
index 5609063..ba30599 100644
--- a/hw/i386/kvm/apic.c
+++ b/hw/i386/kvm/apic.c
@@ -171,21 +171,27 @@ static const MemoryRegionOps kvm_apic_io_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void kvm_apic_init(APICCommonState *s)
+static void kvm_apic_realize(DeviceState *dev, Error **errp)
{
+APICCommonState *s = APIC_COMMON(dev);
+APICCommonClass *acc = APIC_COMMON_GET_CLASS(s);
+
memory_region_init_io(&s->io_memory, NULL, &kvm_apic_io_ops, s,
"kvm-apic-msi",
APIC_SPACE_SIZE);
if (kvm_has_gsi_routing()) {
msi_supported = true;
}
+acc->parent_realize(dev, errp);
}
static void kvm_apic_class_init(ObjectClass *klass, void *data)
{
APICCommonClass *k = APIC_COMMON_CLASS(klass);
+DeviceClass *dc = DEVICE_CLASS(klass);
-k->init = kvm_apic_init;
+k->parent_realize = dc->realize;
+dc->realize = kvm_apic_realize;
k->set_base = kvm_apic_set_base;
k->set_tpr = kvm_apic_set_tpr;
k->get_tpr = kvm_apic_get_tpr;
diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index a913186..8080e20 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
@@ -871,22 +871,36 @@ static const MemoryRegionOps apic_io_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void apic_init(APICCommonState *s)
+static void apic_realize(DeviceState *dev, Error **errp)
{
+APICCommonState *s = APIC_COMMON(dev);
+APICCommonClass *acc = APIC_COMMON_GET_CLASS(s);
+static int apic_no;
+
+if (apic_no >= MAX_APICS) {
+error_setg(errp, "the new apic number: %d "
+ "exceeded max apic number", apic_no);
+return;
+}
+
memory_region_init_io(&s->io_memory, OBJECT(s), &apic_io_ops, s,
"apic-msi",
APIC_SPACE_SIZE);
s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, apic_timer, s);
+s->idx = apic_no++;
local_apics[s->idx] = s;
msi_supported = true;
+acc->parent_realize(dev, errp);
}
static void apic_class_init(ObjectClass *klass, void *data)
{
APICCommonClass *k = APIC_COMMON_CLASS(klass);
+DeviceClass *dc = DEVICE_CLASS(klass);
-k->init = apic_init;
+k->parent_realize = dc->realize;
+dc->realize = apic_realize;
k->set_base = apic_set_base;
k->set_tpr = apic_set_tpr;
k->get_tpr = apic_get_tpr;
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index a0beb10..eac538f 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -284,21 +284,13 @@ static int apic_load_old(QEMUFile *f, void *opaque, int
version_id)
return 0;
}
-static int apic_init_common(ICCDevice *dev)
+static void apic_common_realize(DeviceState *dev, Error **errp)
{
APICCommonState *s = APIC_COMMON(dev);
-APICCommonClass *info;
+APICCommonClass *info = APIC_COMMON_GET_CLASS(s);
static DeviceState *vapic;
-static int apic_no;
static bool mmio_registered;
-if (apic_no >= MAX_APICS) {
-return -1;
-}
-s->idx = apic_no++;
-
-info = APIC_COMMON_GET_CLASS(s);
-info->init(s);
if (!mmio_registered) {
ICCBus *b = ICC_BUS(qdev_get_parent_bus(DEVICE(dev)));
memory_region_add_subregion(b->apic_address_space, 0, &s->io_memory);
@@ -314,8 +306,6 @@ static int apic_init_common(ICCDevice *dev)
if (apic_report_tpr_access && info->enable_tpr_reporting) {
info->enable_tpr_reporting(s, true);
}
-
-return 0;
}
static void apic_dispatch_pre_save(void *opaque)
@@ -381,14 +371,13 @@ static Property apic_properties_common[] = {
static void apic_common_class_init(ObjectClass *klass, void *data)
{
-ICCDeviceClass
[Qemu-devel] [PATCH v1 2/3] Using CPU_FOREACH() instead of scanning local_apics
And dropping MAX_APICS cast macro altogether.
Signed-off-by: Chen Fan
---
hw/intc/apic.c | 82 +
include/hw/i386/apic_internal.h | 2 -
2 files changed, 33 insertions(+), 51 deletions(-)
diff --git a/hw/intc/apic.c b/hw/intc/apic.c
index 8080e20..fc18600 100644
--- a/hw/intc/apic.c
+++ b/hw/intc/apic.c
@@ -32,8 +32,6 @@
#define SYNC_TO_VAPIC 0x2
#define SYNC_ISR_IRR_TO_VAPIC 0x4
-static APICCommonState *local_apics[MAX_APICS + 1];
-
static void apic_set_irq(APICCommonState *s, int vector_num, int trigger_mode);
static void apic_update_irq(APICCommonState *s);
static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
@@ -200,18 +198,15 @@ static void apic_external_nmi(APICCommonState *s)
#define foreach_apic(apic, deliver_bitmask, code) \
{\
+CPUState *cpu;\
int __i, __j, __mask;\
-for(__i = 0; __i < MAX_APIC_WORDS; __i++) {\
+CPU_FOREACH(cpu) {\
+apic = APIC_COMMON(X86_CPU(cpu)->env.apic_state);\
+__i = apic->idx / 32;\
+__j = apic->idx % 32;\
__mask = deliver_bitmask[__i];\
-if (__mask) {\
-for(__j = 0; __j < 32; __j++) {\
-if (__mask & (1 << __j)) {\
-apic = local_apics[__i * 32 + __j];\
-if (apic) {\
-code;\
-}\
-}\
-}\
+if (__mask & (1 << __j)) {\
+code;\
}\
}\
}
@@ -235,9 +230,13 @@ static void apic_bus_deliver(const uint32_t
*deliver_bitmask,
}
}
if (d >= 0) {
-apic_iter = local_apics[d];
-if (apic_iter) {
-apic_set_irq(apic_iter, vector_num, trigger_mode);
+CPUState *cpu;
+CPU_FOREACH(cpu) {
+apic_iter = APIC_COMMON(X86_CPU(cpu)->env.apic_state);
+if (apic_iter->idx == d) {
+apic_set_irq(apic_iter, vector_num, trigger_mode);
+break;
+}
}
}
}
@@ -422,18 +421,14 @@ static void apic_eoi(APICCommonState *s)
static int apic_find_dest(uint8_t dest)
{
-APICCommonState *apic = local_apics[dest];
-int i;
-
-if (apic && apic->id == dest)
-return dest; /* shortcut in case apic->id == apic->idx */
+APICCommonState *apic;
+CPUState *cpu;
-for (i = 0; i < MAX_APICS; i++) {
-apic = local_apics[i];
- if (apic && apic->id == dest)
-return i;
-if (!apic)
-break;
+CPU_FOREACH(cpu) {
+apic = APIC_COMMON(X86_CPU(cpu)->env.apic_state);
+if (apic->id == dest) {
+return apic->idx;
+}
}
return -1;
@@ -443,7 +438,7 @@ static void apic_get_delivery_bitmask(uint32_t
*deliver_bitmask,
uint8_t dest, uint8_t dest_mode)
{
APICCommonState *apic_iter;
-int i;
+CPUState *cpu;
if (dest_mode == 0) {
if (dest == 0xff) {
@@ -457,20 +452,17 @@ static void apic_get_delivery_bitmask(uint32_t
*deliver_bitmask,
} else {
/* XXX: cluster mode */
memset(deliver_bitmask, 0x00, MAX_APIC_WORDS * sizeof(uint32_t));
-for(i = 0; i < MAX_APICS; i++) {
-apic_iter = local_apics[i];
-if (apic_iter) {
-if (apic_iter->dest_mode == 0xf) {
-if (dest & apic_iter->log_dest)
-apic_set_bit(deliver_bitmask, i);
-} else if (apic_iter->dest_mode == 0x0) {
-if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) &&
-(dest & apic_iter->log_dest & 0x0f)) {
-apic_set_bit(deliver_bitmask, i);
-}
+CPU_FOREACH(cpu) {
+apic_iter = APIC_COMMON(X86_CPU(cpu)->env.apic_state);
+if (apic_iter->dest_mode == 0xf) {
+if (dest & apic_iter->log_dest) {
+apic_set_bit(deliver_bitmask, apic_iter->idx);
+}
+} else if (apic_iter->dest_mode == 0x0) {
+if ((dest & 0xf0) == (apic_iter->log_dest & 0xf0) &&
+(dest & apic_iter->log_dest & 0x0f)) {
+apic_set_bit(deliver_bitmask, apic_iter->idx);
}
-} else {
-break;
}
}
}
@@ -875,20 +867,12 @@ static void apic_realize(DeviceState *dev, Error **errp)
{
APICCommonState *s = APIC_COMMON(dev);
APICCommonClass *acc = APIC_COMMON_GET_CLASS(s);
-static int apic_no;
-
-if (apic_no >= MAX_APICS) {
-error_setg(errp, "the new apic number: %d "
- "exceeded max apic number", apic_no);
-return;
-}
[Qemu-devel] [PATCH v1 0/3] refactor x86 apic to QOM typing
In order to implement 'cpu-del' in the furture. at first, needing to refactor x86 apic codes. this converts apic/kvm/xen 's init() callbacks to realize() and dropping local_apics[] from file hw/intc/apic.c. moving apic_state field from CPUX86State to X86CPU. Chen Fan (3): Change apic/kvm/xen to use QOM typing Using CPU_FOREACH() instead of scanning local_apics x86: move apic_state field from CPUX86State to X86CPU cpu-exec.c | 2 +- cpus.c | 5 +-- hw/cpu/icc_bus.c| 17 - hw/i386/kvm/apic.c | 10 - hw/i386/kvmvapic.c | 8 ++-- hw/i386/pc.c| 17 - hw/intc/apic.c | 84 - hw/intc/apic_common.c | 17 ++--- hw/xen/xen_apic.c | 11 +- include/hw/cpu/icc_bus.h| 1 - include/hw/i386/apic_internal.h | 5 +-- target-i386/cpu-qom.h | 4 ++ target-i386/cpu.c | 22 +-- target-i386/cpu.h | 4 -- target-i386/helper.c| 9 ++--- target-i386/kvm.c | 23 +-- target-i386/misc_helper.c | 8 ++-- 17 files changed, 109 insertions(+), 138 deletions(-) -- 1.8.1.4
Re: [Qemu-devel] [PATCH] block/vpc: check that the image has not been truncated
On 22.10.2013 08:59, Eric Blake wrote:
On 10/22/2013 07:43 AM, Peter Lieven wrote:
this adds a check that a dynamic VHD file has not been
accidently truncated (e.g. during transfer or upload).
Signed-off-by: Peter Lieven
---
block/vpc.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/block/vpc.c b/block/vpc.c
index 1acc1d4..921364e 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -269,6 +269,13 @@ static int vpc_open(BlockDriverState *bs, QDict *options,
int flags,
}
}
+if (s->free_data_block_offset > bdrv_getlength(bs->file)) {
+ret = -EINVAL;
+fprintf(stderr, "block-vpc: free_data_block_offset points after"
+"the end of file. the image has been
truncated.\n");
Why fprintf() instead of using the errp argument?
wasn't aware. a few lines earlier fprintf(stderr, ...) was used.
if the others are otherwise happy with the patch I will send a v2.
Peter
Re: [Qemu-devel] [PATCH 14/17] add new RanState RAN_STATE_FLIPPING_MIGRATE
On 10/22/2013 11:51 AM, Eric Blake wrote:
On 10/22/2013 04:25 AM, Lei Li wrote:
Introduce new RanState RAN_STATE_FLIPPING_MIGRATE and
add it to runstate_needs_reset().
Signed-off-by: Lei Li
---
qapi-schema.json | 11 +++
vl.c | 12 +++-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/qapi-schema.json b/qapi-schema.json
index 523a5b2..8178d0c 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -176,12 +176,15 @@
# @watchdog: the watchdog action is configured to pause and has been triggered
#
# @guest-panicked: guest has been panicked as a result of guest OS panic
+#
+# @flipping-migrate: guest is paused to start unix_page_flipping migration
+# process
We probably ought to enhance the docs to mention '(since 1.8)' for this
field (and likewise for other enum values added after the original
introduction of the enum).
Hi Eric,
Sure, will do.
BTW, I was hoping this feature could be accepted and merged to QEMU 1.7
release.
Last time we added a new user-visible runstate, it broke migration with
older libvirt versions that weren't prepared to see the new state (hmm,
I need to check if libvirt has fixed that in the meantime; adding a
cc...). Paolo's advice at the time was that it is okay to require a new
libvirt when using a new qemu, and that libvirt should be taught to
treat all unknown RunState as if they were 'running'; although for this
particular addition it might be nicer to have libvirt lump 'inmigrate'
and 'flipping-migrate' to the same usage.
I am not sure whether these two runstate could be lumped with same usage
in libvirt. Whatever, looks like 'inmigrate' has a transition from 'prelaunch'
to it in QEMU, which reminds me that it may need to add another transition
from 'prelaunch' to 'flipping-migrate' too.
##
{ 'enum': 'RunState',
- 'data': [ 'debug', 'inmigrate', 'internal-error', 'io-error', 'paused',
-'postmigrate', 'prelaunch', 'finish-migrate', 'restore-vm',
-'running', 'save-vm', 'shutdown', 'suspended', 'watchdog',
-'guest-panicked' ] }
+ 'data': [ 'debug', 'flipping-migrate', 'inmigrate', 'internal-error',
+'io-error', 'paused', 'postmigrate', 'prelaunch', 'finish-migrate',
+'restore-vm', 'running', 'save-vm', 'shutdown', 'suspended',
+'watchdog', 'guest-panicked' ] }
--
Lei
Re: [Qemu-devel] make use of copy_policy
On Wed, Oct 16, 2013 at 03:38:36PM +0800, Liu Yuan wrote: > This patch set makes use of copy_policy in struct SheepdogInode in order to > support recently introduced erasure coding in sheepdog. > > Thanks > Yuan Ping ?
Re: [Qemu-devel] [Xen-devel] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching
>>> On 22.10.13 at 06:08, "Gonglei (Arei)" wrote:
> Hi, guys. The new patch has been modified based on the principles you
> suggested, thank you so much.
> Last time I test the patch based on the codes of 4.3.0.
> This time, I found that the system based on the codes of trunk causes the VM
> reboot again and again, which I have not found out the reason.
> So i can not test the patch based on the codes of trunk (details in
> EJ0_ACPI_PCI_Hotplug.patch)..
I'm afraid we will need you to figure out that problem first, and
then do the verification on -unstable. Even if the code shouldn't
be that different from 4.3, we still don't want to apply completely
untested stuff.
> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/firmware/hvmloader/acpi/Makefile
> @@ -24,30 +24,46 @@ OBJS = $(patsubst %.c,%.o,$(C_SRC))
> CFLAGS += $(CFLAGS_xeninclude)
>
> vpath iasl $(PATH)
> +vpath python $(PATH)
Iirc this ought to be $(PYTHON) (also further down).
> +
> +.DELETE_ON_ERROR:$(filter dsdt_%.c,$(C_SRC))
Missing blank after ":".
> dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
> - awk 'NR > 1 {print s} {s=$$0}' $< > $@
> - ./mk_dsdt --dm-version qemu-xen >> $@
> -
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@.tmp
> + sed -i 's/AmlCode/dsdt_anycpu_qemu_xen/g' $@.tmp
> + ./mk_dsdt --dm-version qemu-xen >> $@.tmp
> + sed -i 's/aml_ej0_name/dsdt_anycpu_qemu_xen_aml_ej0_name/g' $@.tmp
> + sed -i 's/aml_adr_dword/dsdt_anycpu_qemu_xen_aml_adr_dword/g' $@.tmp
> + $(call move-if-changed,$@.tmp $@)
> +
Line containing just a tab.
> # NB. awk invocation is a portable alternative to 'head -n -1'
> dsdt_%cpu.asl: dsdt.asl mk_dsdt
> - awk 'NR > 1 {print s} {s=$$0}' $< > $@
> - ./mk_dsdt --maxcpu $* >> $@
> + awk 'NR > 1 {print s} {s=$$0}' $< > $@.tmp
> + sed -i 's/AmlCode/dsdt_$*cpu/g' $@.tmp
> + ./mk_dsdt --maxcpu $* >> $@.tmp
> + $(call move-if-changed,$@.tmp $@)
>
> -$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
> - iasl -vs -p $* -tc $*.asl
> - sed -e 's/AmlCode/$*/g' $*.hex >$@
> - echo "int $*_len=sizeof($*);" >>$@
> - rm -f $*.aml $*.hex
> +$(filter dsdt_%.c,$(C_SRC)): %.c: iasl python %.asl
As you need to touch this anyway, please adjust it to match
common style: The input file should come first in the list of
dependencies, allowing you ...
> + cpp -P $*.asl > $*.asl.i.orig
... use $< here (and further down where applicable) in favor of $*.
> + python ../tools/acpi_extract_preprocess.py $*.asl.i.orig > $*.asl.i
Please be consistent in whether you put a blank after ">" and ">>".
> + iasl -vs -l -tc -p $* $*.asl.i
> + python ../tools/acpi_extract.py $*.lst > $@.tmp
> + echo "int $*_len=sizeof($*);" >>$@.tmp
> + if grep -q "$*_aml_ej0_name" $@.tmp; then echo "int
> $*_aml_ej0_name_len=sizeof($*_aml_ej0_name);" >>$@.tmp; fi
> + if grep -q "$*_aml_adr_dword" $@.tmp; then echo "int
> $*_aml_adr_dword_len=sizeof($*_aml_adr_dword);" >>$@.tmp;fi
Missing blank before "fi".
> +python:
> + @echo
> + @echo "python is needed"
> + @echo
> + @exit 1
What is this good for? For one, the tools build already requires
Python. And then such a dependency would belong into the
configure scripts, not here.
> --- a/tools/firmware/hvmloader/acpi/build.c
> +++ b/tools/firmware/hvmloader/acpi/build.c
There are various coding style issues in the changes to this file.
Please make sure you match the style found elsewhere in here.
> @@ -30,6 +30,9 @@
> #define align16(sz)(((sz) + 15) & ~15)
> #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
>
> +
> +#define PCI_RMV_BASE 0xae0c
> +
> extern struct acpi_20_rsdp Rsdp;
> extern struct acpi_20_rsdt Rsdt;
> extern struct acpi_20_xsdt Xsdt;
> @@ -404,6 +407,7 @@ void acpi_build_tables(struct acpi_config *config,
> unsigned int physical)
> unsigned char *dsdt;
> unsigned longsecondary_tables[ACPI_MAX_SECONDARY_TABLES];
> int nr_secondaries, i;
> +unsigned int rmvc_pcrm = 0;
Pointless initializer. You'd be better off moving the declaration to
the first use point anyway (and then it can have a proper initializer
right away).
> @@ -438,9 +442,27 @@ void acpi_build_tables(struct acpi_config *config,
> unsigned int physical)
> dsdt = mem_alloc(config->dsdt_anycpu_len, 16);
> if (!dsdt) goto oom;
> memcpy(dsdt, config->dsdt_anycpu, config->dsdt_anycpu_len);
> -nr_processor_objects = HVM_MAX_VCPUS;
The movement to this assignment is clearly wrong, as it now
overwrites the different value stored when using the <= 15 CPUs
path.
This also raises the question of why you do the adjustment below
only in the >= 16 CPUs code path.
I also don't see how this adjustment is in line with mk_dsdt.c's
handling of the qemu-traditional case. Or is that building on
SeaBIOS only ever being used with upstream qemu?
> +if(config->aml_adr_dword_len && config->aml_ej0_nam
Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance
> On Tue, Oct 15, 2013 at 03:26:19PM +0800, Jules Wang wrote: > > v2 -> v3: > > * add documentation of new option in qapi-schema. > > > > * long option name: ft -> fault-tolerant > > > > 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 > First of all, thanks for your superb and spot-on comments. > It would be helpful to clarify the status of Curling in the cover letter > email so reviewers know what to expect. OK, but I'm not quite clear about how to clarify the status, would you pls give me an example? > > This series does not address I/O or failover. I guess you are aware of > the missing topics that I mentioned, here are my thoughts on them: > > I/O needs to be held back until the destination host has acknowledged > receiving the last full migration state. The outside world cannot > witness state changes in the guest until the migration state has been > successfully transferred to the destination host. Otherwise the guest > may appear to act incorrectly when resuming execution from the last > snapshot. > > The time period used by the FT sender thread determines how much latency > is added to I/O requests. Yes, there is the latency. That is inevitable. I guess you mean the following situation: If a msg 'hello' is sent to the chat room server just a few seconds before the failover happens, there is a possibility that the msg will be sent to the others twice or be lost. Am I right? > > Failover functionality is missing from these patches. We cannot simply > start executing on the destination host when the migration connection > ends. If the guest disk image is located on shared storage then > split-brain occurs when a network error terminates the migration > connection - > will both hosts begin accessing the shared disk? YES > I have a simple way to handle that. In one word, the third point --gateway. Both the sender and the receiver check the connectivity to the gateway every X seconds. Let's use A and B stand for whether the sender and the receiver are connected to the gateway respectively. When the connection between the sender and the receiver is down. A && B is false. If A is false, the vm instance at the sender will be stopped. If B is false, the vm instance at the receiver will not be started. a.A false B false: 0 vm run b.A false B true: 1 vm run c.A true B false: 1 vm run d.A true B true : 1 vm run (normal case) It becomes complicated when we consider the state transitions in these four states. I suggest adding this feature to libvirt instead of qemu. > What is your plan to address these issues? > > Stefan >
Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
Am 21.10.2013 um 22:19 hat Anthony Liguori geschrieben: > On Mon, Oct 21, 2013 at 2:26 PM, Stefan Hajnoczi wrote: > > There are a number of contributors who maintain block drivers (image > > formats and protocols). They should be listed in the MAINTAINERS file > > so that get_maintainer.pl lists them. > > > > Note that commits are still merged through Kevin or Stefan's block tree > > but the block driver sub-maintainers are usually the ones to review > > patches. > > > > Acked-by: Kevin Wolf > > Signed-off-by: Stefan Hajnoczi > > Acked-by: Anthony Liguori > > Although you certainly don't need it. I assume everything is still > going to flow through the block tree or are you guys looking for these > folks to submit their own pull requests to me? No, at this point it's just about getting the right people CCed if you use get_maintainer.pl. Stefan and I will still apply the patches to our trees (though in many of these areas I would usually ask for the ACK of the maintainer instead of reviewing myself if he isn't the patch author). Kevin
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
On 21 October 2013 21:03, Peter Maydell wrote: > Ken: I think this should work (and it doesn't break building with > old makes), but I don't have a make 4.0 to hand; if you could > test it I'd appreciate it. Forwarding a message from Ken (whose mail client is apparently not very good :-): Ken wrote: # I applied it to 1.6.1 - some fuzz and large offsets, but it # completed the default build (i.e. just ./configure so all targets) # and also a DESTDIR install. Ken -- any chance you could test git master? I think it would be more interesting to make sure that 1.7 works with Make 4.0: I don't know if anybody will care enough to backport this patch to 1.6.x. thanks -- PMM
[Qemu-devel] [PATCH] qemu-img: add special exit code if bdrv_check is not supported
currently it is not possible to distinguish by exitcode if there
has been an error or if bdrv_check is not supported by the image
format. Change the exitcode from 1 to 255 for the latter case.
Signed-off-by: Peter Lieven
---
qemu-img.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-img.c b/qemu-img.c
index 9fb3016..163aa3f 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -609,7 +609,7 @@ static int img_check(int argc, char **argv)
if (output_format == OFORMAT_HUMAN) {
error_report("This image format does not support checks");
}
-ret = 1;
+ret = 255;
goto fail;
}
--
1.7.9.5
Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
Hi:
I have run windows2008r2 guest with qemu-1.5.1/1.6(I have not test the the newer
version) for long time, the issue (guest in hangup state) will come out.When
guest
in hangup state, QEMU main thread is blocked in g_poll loop.
> 398c398,399
> < uint32_t timeout = UINT32_MAX;
> ---
>> /* uint32_t timeout = UINT32_MAX; */
>> uint32_t timeout = 1000;
>
It seems can fix the problem, and rtc/hpet interrupt can inject into guest
again
because of the "timeout", and guest will wake up . But maybe the issue is also
exist,
because during the time before timeout , guest also will lose rtc/hpet ticks.
Regards
xiexiangyou
-Original Message-
From: Alex Bligh [mailto:a...@alex.org.uk]
Sent: Monday, October 21, 2013 10:56 PM
To: Matthew Anderson; Xiexiangyou
Cc: qemu-devel@nongnu.org; Alex Bligh; Stefan Hajnoczi
Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
--On 16 October 2013 14:56:12 + Matthew Anderson
wrote:
> Hi Xiangyouxie,
>
> I personally haven't tried to solve the problem as yet but I've been in
> contact with Anders Fudali who was able to find the issue with the help
> of one of his developers.
>
> See below for his comments. I've love to hear from any of the devs that
> can explain the issue further because as far as I know it's still an
> issue although I haven't with tried any releases past 1.4.1.
It would be interesting to know whether this happens on a current qemu
(i.e. master/1.7/whatever, not 1.6).
The timeout code in main-loop.c has been changed. For context, in
1.4.2, this does:
395 int main_loop_wait(int nonblocking)
396 {
397 int ret;
398 uint32_t timeout = UINT32_MAX;
399
400 if (nonblocking) {
401 timeout = 0;
402 }
403
and I can promise that code has been changed. This might have fixed
things or (in other cases) made an existing bug more obvious.
I'm not sure whether the RTC is meant to be generating some sort of
qemu_notify() here, or using a timer, or what, but it should be doing
something to break out of the select() loop. Stefan - any idea?
Alex
>
>
> We use QEMU-1.4.2 and Kernel-3.8.8 on our host machines. During the
> latest "RTC-freeze" we managed to strace the affected QEMU-process and
> one of our developers figured out that a file descriptor selector loops
> with a NULL value for timeout... we adjusted the source code for the
> file: main-loop.c and replaced UINT32_MAX with the value: 1000, see the
> diff below:
>
> 398c398,399
> < uint32_t timeout = UINT32_MAX;
> ---
>> /* uint32_t timeout = UINT32_MAX; */
>> uint32_t timeout = 1000;
>
> I'm not sure IF this might have some other undesirable effects or
> consequence and why only Windows guests seems to be affected, but we've
> been running with this "fix" for > 3 days now and haven't seen the
> problem since.
>
> Thought to share this with you.
>
> Regards
>
> Anders Fudali
>
> --
>
> From: Xiexiangyou [mailto:xiexiang...@huawei.com]
> Sent: Tuesday, 8 October 2013 5:39 PM
> To: Matthew Anderson
> Cc: qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
>
> Hi:
> I have met the same bug that windows2008 guest stop
> receive the RTC ticks when it in idle status by fortuitous. When vnc
> connect, guest will resume to receive RTC ticks and the time run fast
> because of the coalesced timer
>
> HPET is diabled, and RTC is set "catchup", as following:
>
>
>
>
>
> My kvm module is version3.6. Should I upgrade it to latest version. Any
> suggestion is welcome !
>
> Thanks!
>
> --xiangyouxie
>
>
> On Thu, Feb 21, 2013 at 06:16:10PM +, Matthew Anderson wrote:
>> If this isn't the correct list just let me know,
>>
>> I've run into a bug whereby a Windows guest (tested on Server 2008R2 and
>> 2012) no longer receives RTC ticks when it has been idle for a random
>> amount of time. HPET is disabled and the guest is running Hyper-V
>> relaxed timers (same situation without hv_relaxed). The guest clock
>> stands still and the qemu process uses very little CPU (<0.5%, normally
>> it's >5% when the guest is idle) . Eventually the guest stops
>> responding to network requests but if you open the guest console via
>> VNC and move the mouse around it comes back to life and QEMU replays
>> the lost RTC ticks and the guest recovers. I've also been able to make
>> it recover by querying the clock over the network via the net time
>> command, you can see the clock stand still for 30 seconds then it
>> replays the ticks and catches up.
>>
>> I've tried to reproduce the issue but it seems fairly illusive, the only
>> way I've been able to reproduce it is by letting the VM's idle and
>> waiting. Sometimes it's hours and sometimes minutes. Can anyone suggest
>> a way to narrow the issue down?
>>
>> Qemu command line is-
>> /usr/bin/
Re: [Qemu-devel] [PATCH] qemu-img: add special exit code if bdrv_check is not supported
On 10/22/2013 09:26 AM, Peter Lieven wrote:
> currently it is not possible to distinguish by exitcode if there
> has been an error or if bdrv_check is not supported by the image
> format. Change the exitcode from 1 to 255 for the latter case.
Why 255? Sure, 'xargs' handles $?=255 differently than most other
status, but in general, $? > 128 starts to be ambiguous with death by
signal (on the other hand, most systems stop at 64 signals rather than
128). Most applications that use differentiated exit status just use 1
and 2, rather than 1 and 255.
>
> Signed-off-by: Peter Lieven
> ---
> qemu-img.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
But I don't care strongly enough to reject this, so if no one else
complains about the choice:
Reviewed-by: Eric Blake
>
> diff --git a/qemu-img.c b/qemu-img.c
> index 9fb3016..163aa3f 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -609,7 +609,7 @@ static int img_check(int argc, char **argv)
> if (output_format == OFORMAT_HUMAN) {
> error_report("This image format does not support checks");
> }
> -ret = 1;
> +ret = 255;
> goto fail;
> }
>
>
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH_v2 9/9] target-openrisc: Correct carry flagcheck of l.addc and l.addic test casess
sebast...@macke.de writes: > The test cases did not correctly test for the carry flag. Out of interest how are you building your test cases, cross-compiling or from within the emulated environment? I want to clean-up and resurrect the TCG tests but one of the challenges is all the non-x86 targets need to be built somehow. Cheers, -- Alex Bennée
Re: [Qemu-devel] [PATCH] qemu-img: add special exit code if bdrv_check is not supported
On 22.10.2013 10:34, Eric Blake wrote: On 10/22/2013 09:26 AM, Peter Lieven wrote: currently it is not possible to distinguish by exitcode if there has been an error or if bdrv_check is not supported by the image format. Change the exitcode from 1 to 255 for the latter case. Why 255? Sure, 'xargs' handles $?=255 differently than most other status, but in general, $? > 128 starts to be ambiguous with death by signal (on the other hand, most systems stop at 64 signals rather than 128). Most applications that use differentiated exit status just use 1 and 2, rather than 1 and 255. I would also be fine with 63. Someone started to make some choices for check->leaks, check->corruptions using 2,3, ... I wanted to avoid conflicts if someone adds a 4,5,6 ... Peter
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS sowe can build with GNU Make 4.00
peter.mayd...@linaro.org writes: > Our rules.mak adds '-rR' to MAKEFLAGS to indicate that we will be > explicitly specifying everything and not relying on any default > variables or rules. s/sowe/so we/ Otherwise good. Reviewed-by: Alex Bennée -- Alex Bennée
Re: [Qemu-devel] [PATCH 14/17] add new RanState RAN_STATE_FLIPPING_MIGRATE
On 10/22/2013 07:28 AM, Lei Li wrote: >>> # @guest-panicked: guest has been panicked as a result of guest OS >>> panic >>> +# >>> +# @flipping-migrate: guest is paused to start unix_page_flipping >>> migration >>> +# process >> We probably ought to enhance the docs to mention '(since 1.8)' for this >> field (and likewise for other enum values added after the original >> introduction of the enum). > > Hi Eric, > > Sure, will do. > > BTW, I was hoping this feature could be accepted and merged to QEMU 1.7 > release. http://wiki.qemu.org/Planning/1.7 Soft freeze has already happened, so it's up to the maintainers whether there is still time to be adding this feature in 1.7 - but yes, that would affect the tag you list in your docs. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 6/6] qapi: add doc for QEvent
于 2013/10/22 5:00, Eric Blake 写道:
On 10/21/2013 03:16 AM, Wenchao Xia wrote:
Signed-off-by: Wenchao Xia
---
qapi-schema.json | 56 ++
1 files changed, 56 insertions(+), 0 deletions(-)
Incomplete. Now that you are actually using the enum (see the spot I
pointed out in 5/6), you ALSO need to change:
-{ 'type': 'EventInfo', 'data': {'name': 'str'} }
+{ 'type': 'EventInfo', 'data': {'name': 'QEvent'} }
and make use of the enum in the QAPI documentation.
I just found QEvent is a int(enum) so this change can't be done.
Is there a way to tell use QEvent's correspond string? Add a new
way to specify enum's correspond string automatically? for example:
{ 'type': 'EventInfo', 'data': {'name': '&QEvent'}
Re: [Qemu-devel] [PATCH 6/6] qapi: add doc for QEvent
On 10/22/2013 07:55 AM, Wenchao Xia wrote:
> 于 2013/10/22 5:00, Eric Blake 写道:
>> On 10/21/2013 03:16 AM, Wenchao Xia wrote:
>>> Signed-off-by: Wenchao Xia
>>> ---
>>> qapi-schema.json | 56
>>> ++
>>> 1 files changed, 56 insertions(+), 0 deletions(-)
>> Incomplete. Now that you are actually using the enum (see the spot I
>> pointed out in 5/6), you ALSO need to change:
>>
>> -{ 'type': 'EventInfo', 'data': {'name': 'str'} }
>> +{ 'type': 'EventInfo', 'data': {'name': 'QEvent'} }
>>
>> and make use of the enum in the QAPI documentation.
>>
> I just found QEvent is a int(enum) so this change can't be done.
Huh? That's the whole point of qapi enums - they are stored as int
constants in C code, but sent as strings over QMP.
> Is there a way to tell use QEvent's correspond string? Add a new
> way to specify enum's correspond string automatically? for example:
>
> { 'type': 'EventInfo', 'data': {'name': '&QEvent'}
No, QAPI does it for you already, no change in syntax needed.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v4 1/5] Fix configure script for LTTng 2.x
mohamad.ge...@polymtl.ca writes: > On 13-10-18 10:05 AM, Stefan Hajnoczi wrote: >> Please switch to pkg-config instead of hardcoding particular flags. I >> checked that Fedora and Debian ship the pkg-config file. > Unfortunately, some missing files in the Ubuntu package make it > impossible to use pkg-config for versions of Ubuntu older than 13.10 > (like Ubuntu 12.04 which is a LTS). Would you be okay with these flags? Hmm this is tricky because pkg-config really should be the portable way to get at these flags. Perhaps we could just fall back to sensible defaults if pkg-config fails? On my 12.04 system (with the lttng PPA) it works fine: $>pkg-config --libs lttng-ust -llttng-ust -ldl $>pkg-config --cflags lttng-ust -I/usr/include/x86_64-linux-gnu Is there a bug raised with the Ubuntu upstream to fix their stable LTTNG package? -- Alex Bennée
Re: [Qemu-devel] [PULL 4/4] net: disallow to specify multicast MAC address
On Sat, Oct 19, 2013 at 12:08:14AM +0400, Dmitry Krivenok wrote:
> > Duplicate, we already have is_multicast_ether_addr() in include/net/eth.h
>
> I tried to #include "net/eth.h" in net/net.c, but it didn't work:
>
> diff --git a/net/net.c b/net/net.c
> index c330c9a..870d3bb 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -27,6 +27,7 @@
> #include "clients.h"
> #include "hub.h"
> #include "net/slirp.h"
> +#include "net/eth.h"
> #include "util.h"
>
> #include "monitor/monitor.h"
> @@ -689,6 +690,11 @@ static int net_init_nic(const NetClientOptions
> *opts, const char *name,
> error_report("invalid syntax for ethernet address");
> return -1;
> }
> +if (nic->has_macaddr &&
> +is_multicast_ether_addr(nd->macaddr.a)) {
> +error_report("NIC cannot have multicast MAC address (odd 1st byte)");
> +return -1;
> +}
> qemu_macaddr_default_if_unset(&nd->macaddr);
>
> if (nic->has_vectors) {
>
> $ make
> CCnet/net.o
> In file included from /home/krivenok/qemu/include/qemu/sockets.h:18,
> from net/net.c:35:
> /usr/include/netinet/in.h:199: error: redefinition of 'struct in6_addr'
> make: *** [net/net.o] Error 1
> $
Hi Dmitry,
"struct in6_addr" exists in , you can remove the
definition in eth.h
diff --git a/include/net/eth.h b/include/net/eth.h
index 1d48e06..1cce570 100644
--- a/include/net/eth.h
+++ b/include/net/eth.h
@@ -28,6 +28,7 @@
#include
#include
+#include
#include "qemu/bswap.h"
#include "qemu/iov.h"
@@ -83,13 +84,6 @@ typedef struct ip_pseudo_header {
uint16_t ip_payload;
} ip_pseudo_header;
-/* IPv6 address */
-struct in6_addr {
-union {
-uint8_t __u6_addr8[16];
-} __in6_u;
-};
-
struct ip6_header {
union {
struct ip6_hdrctl {
>
> eth.h seems to be used only in vmware specific code and likely needs
> to be fixed to be used in other places.
> Other option is to move is_*_ether_addr() functions to another header
> and include it in both places.
--
Amos.
Re: [Qemu-devel] [PATCH] audio/mixeng_template.h: fix inline declaration
ping
I think this is should go to qemu-trivial
--On 6 August 2013 19:45:13 +0100 Alex Bligh wrote:
Fix error: ‘inline’ is not at beginning of declaration
[-Werror=old-style-declaration]
Signed-off-by: Alex Bligh
---
audio/mixeng_template.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/audio/mixeng_template.h b/audio/mixeng_template.h
index 30849a6..77cc89b 100644
--- a/audio/mixeng_template.h
+++ b/audio/mixeng_template.h
@@ -35,7 +35,7 @@
#define IN_T glue (glue (ITYPE, BSIZE), _t)
#ifdef FLOAT_MIXENG
-static mixeng_real inline glue (conv_, ET) (IN_T v)
+static inline mixeng_real glue (conv_, ET) (IN_T v)
{
IN_T nv = ENDIAN_CONVERT (v);
@@ -54,7 +54,7 @@ static mixeng_real inline glue (conv_, ET) (IN_T v)
#endif
}
-static IN_T inline glue (clip_, ET) (mixeng_real v)
+static inline IN_T glue (clip_, ET) (mixeng_real v)
{
if (v >= 0.5) {
return IN_MAX;
--
1.7.9.5
--
Alex Bligh
Re: [Qemu-devel] BUG: RTC issue when Windows guest is idle
--On 22 October 2013 08:28:08 + Xiexiangyou wrote: Hi: I have run windows2008r2 guest with qemu-1.5.1/1.6(I have not test the the newer version) for long time, the issue (guest in hangup state) will come out.When guest in hangup state, QEMU main thread is blocked in g_poll loop. 398c398,399 < uint32_t timeout = UINT32_MAX; --- /* uint32_t timeout = UINT32_MAX; */ uint32_t timeout = 1000; It seems can fix the problem, and rtc/hpet interrupt can inject into guest again because of the "timeout", and guest will wake up . But maybe the issue is also exist, because during the time before timeout , guest also will lose rtc/hpet ticks. I do not think that is the correct fix for 1.5.1/1.6; what you are basically doing is limiting the wait in the mainloop to one second (1.5.1/1.6 are in milliseconds); however, I believe there may be other code that looks for infinite timeouts. Either there is some other bug that this is masking (in which case it may or may not be fixed in master / 1.7), or its a bug in the timer stuff in 1.5.1/1.6 (which would not surprise me) which is likely to have been fixed in master / 1.7. -- Alex Bligh
Re: [Qemu-devel] [PATCH] audio/mixeng_template.h: fix inline declaration
On 6 August 2013 19:45, Alex Bligh wrote: > Fix error: ‘inline’ is not at beginning of declaration > [-Werror=old-style-declaration] > > Signed-off-by: Alex Bligh Reviewed-by: Peter Maydell -- PMM
Re: [Qemu-devel] [PULL 4/4] net: disallow to specify multicast MAC address
This was my original intention, but I noticed that structs defined differently and standard one may be bigger depending on some #defines. So I renamed in6_addr to in6_address in include/net/eth.h (see v2 patch I sent yesterday). In case qemu version is not supposed to be a different struct, then your change is definitely right.
[Qemu-devel] [REMINDER] Key Signing Party at KVM Forum
Hi, We'll be hosting a key signing party at KVM Forum on Wednesday during the Hackathon. More information is at: http://wiki.qemu.org/KeySigningParty2013 Here is the set of people who have sent me their fingerprints so far: http://wiki.qemu.org/download/keysigning.txt If you plan on participating, please make sure you key is in this list and if it is not, send me the output of gpg --fingerprint for the key you wish to use. I may have missed your mail so even if you sent me something, please check again. Make sure you bring proper ID too. Passports are the best form of ID. Please note that the key server on the wiki is currently down so please ignore that part of the howto. Regards, Anthony Liguori
[Qemu-devel] [PATCH for-1.7] atomic.h: Fix build with clang
clang defines __ATOMIC_SEQ_CST but its implementation of the
__atomic_exchange() builtin differs from that of gcc. Move the
__clang__ branch of the ifdef ladder to the top and fix its
implementation (there is no such builtin as __sync_exchange),
so we can compile with clang again.
Signed-off-by: Peter Maydell
---
I don't have access to a Linux box with clang, so this is only
tested on MacOSX clang, but I believe it to be both required
and correct for all clang platforms.
include/qemu/atomic.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/qemu/atomic.h b/include/qemu/atomic.h
index 0aa8913..492bce1 100644
--- a/include/qemu/atomic.h
+++ b/include/qemu/atomic.h
@@ -168,14 +168,14 @@
#endif
#ifndef atomic_xchg
-#ifdef __ATOMIC_SEQ_CST
+#if defined(__clang__)
+#define atomic_xchg(ptr, i)__sync_swap(ptr, i)
+#elif defined(__ATOMIC_SEQ_CST)
#define atomic_xchg(ptr, i)({ \
typeof(*ptr) _new = (i), _old; \
__atomic_exchange(ptr, &_new, &_old, __ATOMIC_SEQ_CST); \
_old; \
})
-#elif defined __clang__
-#define atomic_xchg(ptr, i)__sync_exchange(ptr, i)
#else
/* __sync_lock_test_and_set() is documented to be an acquire barrier only. */
#define atomic_xchg(ptr, i)(smp_mb(), __sync_lock_test_and_set(ptr, i))
--
1.7.11.4
Re: [Qemu-devel] [REMINDER] Key Signing Party at KVM Forum
You must bring a physical copy of your own key fingerprint. I will not allow folks to use their laptops during the key signing. There are pens and pads of paper in the conference rooms. If you don't already have a print out, write your fingerprint on a piece of paper before tomorrow and bring that with you. Do not trust that I have reproduced your key accurately. Regards, Anthony Liguori On Tue, Oct 22, 2013 at 10:56 AM, Anthony Liguori wrote: > Hi, > > We'll be hosting a key signing party at KVM Forum on Wednesday during > the Hackathon. > > More information is at: > > http://wiki.qemu.org/KeySigningParty2013 > > Here is the set of people who have sent me their fingerprints so far: > > http://wiki.qemu.org/download/keysigning.txt > > If you plan on participating, please make sure you key is in this list > and if it is not, send me the output of gpg --fingerprint for the key > you wish to use. I may have missed your mail so even if you sent me > something, please check again. > > Make sure you bring proper ID too. Passports are the best form of ID. > > Please note that the key server on the wiki is currently down so > please ignore that part of the howto. > > Regards, > > Anthony Liguori
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
Hello, Eric Blake, le Mon 21 Oct 2013 22:04:23 +0100, a écrit : > > +'*ip6_prefix': 'str', > > Why is this a str instead of an integer? prefix would be e.g. fc00::1/64. Samuel
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
On 10/22/2013 11:22 AM, Samuel Thibault wrote: > Hello, > > Eric Blake, le Mon 21 Oct 2013 22:04:23 +0100, a écrit : >>> +'*ip6_prefix': 'str', >> >> Why is this a str instead of an integer? > > prefix would be e.g. fc00::1/64. That requires me to post-parse it. Would it be smarter to represent this as two elements, one for the "fc00::1" string, and another for the 64 width, so that I don't have to post-parse? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
Hello, Eric Blake, le Tue 22 Oct 2013 11:27:27 +0100, a écrit : > On 10/22/2013 11:22 AM, Samuel Thibault wrote: > > Eric Blake, le Mon 21 Oct 2013 22:04:23 +0100, a écrit : > >>> +'*ip6_prefix': 'str', > >> > >> Why is this a str instead of an integer? > > > > prefix would be e.g. fc00::1/64. > > That requires me to post-parse it. Would it be smarter to represent this > as two elements, one for the "fc00::1" string, and another for the 64 > width, so that I don't have to post-parse? It makes sense, yes, the syntax would be [ip6-prefix=net[/netsize]] . I just don't know how to express that in qapi :) Samuel
Re: [Qemu-devel] why no progress shown after introduce NBD migration cookie
Hi, all Could someone make a detailed statement for the buggy implementation of traditional storage-migration method that migrating the storage in iteration way? Thanks, Zhang Haoyu hi Michal, I used libvirt-1.0.3, ran below command to perform live migration, why no progress shown up? virsh migrate --live --verbose --copy-storage-all qemu+tcp:///system If replacing libvirt-1.0.3 with libvirt-1.0.2, the migration progress shown up, if performing migration without "--copy-storage-all", the migration progress shown up, too. Thanks, Zhang Haoyu >>> >>> Because since 1.0.3 we are using NBD to migrate storage. Truth is, >>> qemu is reporting progress of storage migration, however, there is no >>> generic formula to combine storage migration and internal state migration >>> into one number. With NBD the process is something like this: >> >> How to use NBD to migrate storage? >> Does NBD server in destination start automatically as soon as migration >> initiated, or some other configurations needed? >> What's the advantages of using NBD to migrate storage over traditional >> method that migrating the storage in iteration way, just like the way in >> which migrating the memory? >> Sorry for my poor knowledge in NBD, by which I used to implement shared >> storage for live migration without storage. > >NBD is used whenever both src and dst of migration is new enough to use it. >That is, libvirt >= 1.0.3 and qemu >= 1.0.3. The NBD is turned on by libvirt >whenever the conditions are met. User has no control over this. >The advantage is: only specified disks can be transferred (currently not >supported in libvirt), the previous implementation was buggy (according to >some qemu developers), the storage is migrated via separate channel (a new >connection) so it can be possible (in the future) to split migration of RAM + >internal state and storage. > >So frankly speaking, there's no real advantage for users now - besides not >using buggy implementation. > >Michal > >BTW: It's better to ask these kind of info on the libvir-list next time, >others might contribute with much more info as well (e.g. some qemu developers >tend to watch the libvir-list too).
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
On 10/22/2013 11:31 AM, Samuel Thibault wrote: > Hello, > > Eric Blake, le Tue 22 Oct 2013 11:27:27 +0100, a écrit : >> On 10/22/2013 11:22 AM, Samuel Thibault wrote: >>> Eric Blake, le Mon 21 Oct 2013 22:04:23 +0100, a écrit : > +'*ip6_prefix': 'str', Why is this a str instead of an integer? >>> >>> prefix would be e.g. fc00::1/64. >> >> That requires me to post-parse it. Would it be smarter to represent this >> as two elements, one for the "fc00::1" string, and another for the 64 >> width, so that I don't have to post-parse? > > It makes sense, yes, the syntax would be [ip6-prefix=net[/netsize]] . I > just don't know how to express that in qapi :) '*ip6_net':'str', '*ip6_netsize':'int' passed on the wire as: "ip6_net":"fc00::1", "ip6_netsize":64 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
Eric Blake, le Tue 22 Oct 2013 11:33:52 +0100, a écrit : > On 10/22/2013 11:31 AM, Samuel Thibault wrote: > > Hello, > > > > Eric Blake, le Tue 22 Oct 2013 11:27:27 +0100, a écrit : > >> On 10/22/2013 11:22 AM, Samuel Thibault wrote: > >>> Eric Blake, le Mon 21 Oct 2013 22:04:23 +0100, a écrit : > > +'*ip6_prefix': 'str', > > Why is this a str instead of an integer? > >>> > >>> prefix would be e.g. fc00::1/64. > >> > >> That requires me to post-parse it. Would it be smarter to represent this > >> as two elements, one for the "fc00::1" string, and another for the 64 > >> width, so that I don't have to post-parse? > > > > It makes sense, yes, the syntax would be [ip6-prefix=net[/netsize]] . I > > just don't know how to express that in qapi :) > > '*ip6_net':'str', '*ip6_netsize':'int' > > passed on the wire as: > > "ip6_net":"fc00::1", "ip6_netsize":64 Err, so that means that the user would have to pass "ip6-net=fc00::1,ip6_netsize=64"? This would look awkward, compared to the ipv4 situation, which is a mere "net=10.0.2.2/24". Samuel
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
On 10/22/2013 11:45 AM, Samuel Thibault wrote: >>> It makes sense, yes, the syntax would be [ip6-prefix=net[/netsize]] . I >>> just don't know how to express that in qapi :) >> >> '*ip6_net':'str', '*ip6_netsize':'int' >> >> passed on the wire as: >> >> "ip6_net":"fc00::1", "ip6_netsize":64 > > Err, so that means that the user would have to pass > "ip6-net=fc00::1,ip6_netsize=64"? This would look awkward, compared to > the ipv4 situation, which is a mere "net=10.0.2.2/24". Err, yes. QMP is machine-parseable. HMP can let the user abbreviate to net=10.0.2.2/24, but QMP should not require reparsing. So what if it's longer, it's easier for machines to manipulate if it's already broken into parts. Trust me - I wouldn't be asking you to split it into two fields unless I thought that libvirt would much rather send it to you as two fields. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [RFC v5 4/5] hw/arm/digic: add UART support
On Thu, 17 Oct 2013 18:54:28 +0100 Peter Maydell wrote: > On 7 September 2013 08:04, Antony Pavlov wrote: > > Signed-off-by: Antony Pavlov > > --- a/hw/arm/digic_boards.c > > +++ b/hw/arm/digic_boards.c > > @@ -26,6 +26,13 @@ > > #include "hw/boards.h" > > #include "exec/address-spaces.h" > > #include "hw/arm/digic.h" > > +#include "hw/block/flash.h" > > +#include "hw/loader.h" > > +#include "sysemu/sysemu.h" > > + > > +#define DIGIC4_ROM0_BASE 0xf000 > > +#define DIGIC4_ROM1_BASE 0xf800 > > +# define DIGIC4_ROM_MAX_SIZE 0x0800 > > Stray extra spaces here. If you fix those then: > Reviewed-by: Peter Maydell Yes, my bad! But this fragment (defining DIGIC4_ROM* macros) is misplaced. It will go to the "add NOR ROM support" in the next patchseries version. -- -- Best regards, Antony Pavlov
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
On 10/22/2013 11:48 AM, Eric Blake wrote: > On 10/22/2013 11:45 AM, Samuel Thibault wrote: > It makes sense, yes, the syntax would be [ip6-prefix=net[/netsize]] . I just don't know how to express that in qapi :) >>> >>> '*ip6_net':'str', '*ip6_netsize':'int' >>> >>> passed on the wire as: >>> >>> "ip6_net":"fc00::1", "ip6_netsize":64 >> >> Err, so that means that the user would have to pass >> "ip6-net=fc00::1,ip6_netsize=64"? This would look awkward, compared to >> the ipv4 situation, which is a mere "net=10.0.2.2/24". > > Err, yes. QMP is machine-parseable. HMP can let the user abbreviate to > net=10.0.2.2/24, but QMP should not require reparsing. So what if it's > longer, it's easier for machines to manipulate if it's already broken > into parts. Trust me - I wouldn't be asking you to split it into two > fields unless I thought that libvirt would much rather send it to you as > two fields. The command line, just like HMP, can use shorthand for convenience. I guess you do have a point about consistency of ipv4's @net requiring post-processing, but that doesn't mean we have to repeat the mistake for IPv6. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 1/7] Declare and Enable VSX
From: Tom Musta
This patch adds the flag POWERPC_FLAG_VSX to the list of defined
flags and also adds this flag to the list of supported features of
the Power7 and Power8 CPUs. Additionally, the VSX instructions
are added to the list of TCG-enabled instruction.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/cpu.h
===
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -549,6 +549,8 @@ enum {
POWERPC_FLAG_BUS_CLK = 0x0002,
/* Has CFAR */
POWERPC_FLAG_CFAR = 0x0004,
+/* Has VSX */
+POWERPC_FLAG_VSX = 0x0008,
};
/*/
@@ -1870,7 +1872,8 @@ enum {
/* Book I 2.05 PowerPC specification */
PPC2_ISA205= 0x0020ULL,
-#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_PRCNTL | PPC2_DBRX | PPC2_ISA205)
+#define PPC_TCG_INSNS2 (PPC2_BOOKE206 | PPC2_VSX | PPC2_PRCNTL | PPC2_DBRX | \
+ PPC2_ISA205)
};
/*/
Index: b/target-ppc/translate_init.c
===
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7242,7 +7242,8 @@ POWERPC_FAMILY(POWER7)(ObjectClass *oc,
pcc->bfd_mach = bfd_mach_ppc64;
pcc->flags = POWERPC_FLAG_VRE | POWERPC_FLAG_SE |
POWERPC_FLAG_BE | POWERPC_FLAG_PMM |
- POWERPC_FLAG_BUS_CLK | POWERPC_FLAG_CFAR;
+ POWERPC_FLAG_BUS_CLK | POWERPC_FLAG_CFAR |
+ POWERPC_FLAG_VSX;
pcc->l1_dcache_size = 0x8000;
pcc->l1_icache_size = 0x8000;
}
@@ -7276,7 +7277,8 @@ POWERPC_FAMILY(POWER8)(ObjectClass *oc,
pcc->bfd_mach = bfd_mach_ppc64;
pcc->flags = POWERPC_FLAG_VRE | POWERPC_FLAG_SE |
POWERPC_FLAG_BE | POWERPC_FLAG_PMM |
- POWERPC_FLAG_BUS_CLK | POWERPC_FLAG_CFAR;
+ POWERPC_FLAG_BUS_CLK | POWERPC_FLAG_CFAR |
+ POWERPC_FLAG_VSX;
pcc->l1_dcache_size = 0x8000;
pcc->l1_icache_size = 0x8000;
}
[Qemu-devel] [PATCH 2/7] Add MSR VSX and Associated Exception
From: Tom Musta
This patch adds support for the VSX bit of the PowerPC Machine
State Register (MSR) as well as the corresponding VSX Unavailable
exception.
The VSX bit is added to the defined bits masks of the Power7 and
Power8 CPU models.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/cpu.h
===
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -236,6 +236,8 @@ enum {
POWERPC_EXCP_NMEXTBR = 91, /* Non maskable external breakpoint */
POWERPC_EXCP_ITLBE= 92, /* Instruction TLB error */
POWERPC_EXCP_DTLBE= 93, /* Data TLB error*/
+/* VSX Unavailable (Power ISA 2.06 and later)*/
+POWERPC_EXCP_VSXU = 94, /* VSX Unavailable */
/* EOL */
POWERPC_EXCP_NB = 96,
/* QEMU exceptions: used internally during code translation */
@@ -427,6 +429,7 @@ struct ppc_slb_t {
#define MSR_VR 25 /* altivec availablex hflags */
#define MSR_SPE 25 /* SPE enable for BookE x hflags */
#define MSR_AP 23 /* Access privilege state on 602 hflags */
+#define MSR_VSX 23 /* Vector Scalar Extension (ISA 2.06 and later) x hflags */
#define MSR_SA 22 /* Supervisor access mode on 602 hflags */
#define MSR_KEY 19 /* key bit on 603e */
#define MSR_POW 18 /* Power management */
@@ -467,6 +470,7 @@ struct ppc_slb_t {
#define msr_vr ((env->msr >> MSR_VR) & 1)
#define msr_spe ((env->msr >> MSR_SPE) & 1)
#define msr_ap ((env->msr >> MSR_AP) & 1)
+#define msr_vsx ((env->msr >> MSR_VSX) & 1)
#define msr_sa ((env->msr >> MSR_SA) & 1)
#define msr_key ((env->msr >> MSR_KEY) & 1)
#define msr_pow ((env->msr >> MSR_POW) & 1)
Index: b/target-ppc/excp_helper.c
===
--- a/target-ppc/excp_helper.c
+++ b/target-ppc/excp_helper.c
@@ -390,6 +390,11 @@ static inline void powerpc_excp(PowerPCC
new_msr |= (target_ulong)MSR_HVB;
}
goto store_current;
+case POWERPC_EXCP_VSXU: /* VSX unavailable exception */
+if (lpes1 == 0) {
+new_msr |= (target_ulong)MSR_HVB;
+}
+goto store_current;
case POWERPC_EXCP_PIT: /* Programmable interval timer interrupt*/
LOG_EXCP("PIT exception\n");
goto store_next;
Index: b/target-ppc/translate.c
===
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -199,6 +199,7 @@ typedef struct DisasContext {
#endif
int fpu_enabled;
int altivec_enabled;
+int vsx_enabled;
int spe_enabled;
ppc_spr_t *spr_cb; /* Needed to check rights for mfspr/mtspr */
int singlestep_enabled;
@@ -9763,6 +9764,11 @@ static inline void gen_intermediate_code
ctx.altivec_enabled = msr_vr;
else
ctx.altivec_enabled = 0;
+if ((env->flags & POWERPC_FLAG_VSX) && msr_vsx) {
+ctx.vsx_enabled = msr_vsx;
+} else {
+ctx.vsx_enabled = 0;
+}
if ((env->flags & POWERPC_FLAG_SE) && msr_se)
ctx.singlestep_enabled = CPU_SINGLE_STEP;
else
Index: b/target-ppc/translate_init.c
===
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -3061,6 +3061,7 @@ static void init_excp_POWER7 (CPUPPCStat
env->excp_vectors[POWERPC_EXCP_TRACE]= 0x0D00;
env->excp_vectors[POWERPC_EXCP_PERFM]= 0x0F00;
env->excp_vectors[POWERPC_EXCP_VPU] = 0x0F20;
+env->excp_vectors[POWERPC_EXCP_VSXU] = 0x0F40;
env->excp_vectors[POWERPC_EXCP_IABR] = 0x1300;
env->excp_vectors[POWERPC_EXCP_MAINT]= 0x1600;
env->excp_vectors[POWERPC_EXCP_VPUA] = 0x1700;
@@ -7232,7 +7233,7 @@ POWERPC_FAMILY(POWER7)(ObjectClass *oc,
PPC_SEGMENT_64B | PPC_SLBI |
PPC_POPCNTB | PPC_POPCNTWD;
pcc->insns_flags2 = PPC2_VSX | PPC2_DFP | PPC2_DBRX | PPC2_ISA205;
-pcc->msr_mask = 0x8204FF37ULL;
+pcc->msr_mask = 0x8284FF37ULL;
pcc->mmu_model = POWERPC_MMU_2_06;
#if defined(CONFIG_SOFTMMU)
pcc->handle_mmu_fault = ppc_hash64_handle_mmu_fault;
@@ -7267,7 +7268,7 @@ POWERPC_FAMILY(POWER8)(ObjectClass *oc,
PPC_SEGMENT_64B | PPC_SLBI |
PPC_POPCNTB | PPC_POPCNTWD;
pcc->insns_flags2 = PPC2_VSX | PPC2_DFP | PPC2_DBRX;
-pcc->msr_mask = 0x8204FF36ULL;
+pcc->msr_mask = 0x8284FF36ULL;
pcc->mmu_model = POWERPC_MMU_2_06;
#if defined(CONFIG_SOFTMMU)
[Qemu-devel] [PATCH 3/7] Add VSX Instruction Decoders
From: Tom Musta
This patch adds decoders for the VSX fields XT, XS, XA, XB and
DM. The first four are split fields and a general helper for
these types of fields is also added.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/translate.c
===
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -370,6 +370,12 @@ static inline int32_t name(uint32_t opco
return (int16_t)((opcode >> (shift)) & ((1 << (nb)) - 1));\
}
+#define EXTRACT_HELPER_SPLIT(name, shift1, nb1, shift2, nb2) \
+static inline uint32_t name(uint32_t opcode) \
+{ \
+return (((opcode >> (shift1)) & ((1 << (nb1)) - 1)) << nb2) | \
+((opcode >> (shift2)) & ((1 << (nb2)) - 1)); \
+}
/* Opcode part 1 */
EXTRACT_HELPER(opc1, 26, 6);
/* Opcode part 2 */
@@ -484,6 +490,11 @@ static inline target_ulong MASK(uint32_t
return ret;
}
+EXTRACT_HELPER_SPLIT(xT, 0, 1, 21, 5);
+EXTRACT_HELPER_SPLIT(xS, 0, 1, 21, 5);
+EXTRACT_HELPER_SPLIT(xA, 2, 1, 16, 5);
+EXTRACT_HELPER_SPLIT(xB, 1, 1, 11, 5);
+EXTRACT_HELPER(DM, 8, 2);
/*/
/* PowerPC instructions table*/
[Qemu-devel] [PATCH 4/7] Add VSR to Global Registers
From: Tom Musta
This patch adds VSX VSRs to the the list of global register indices.
More specifically, it adds the lower halves of the first 32 VSRs to
the list of global register indices. The upper halves of the first
32 VSRs are already defined via cpu_fpr[]. And the second 32 VSRs
are already defined via the cpu_avrh[] and cpu_avrl[] arrays.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/translate.c
===
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -51,6 +51,7 @@ static char cpu_reg_names[10*3 + 22*4 /*
#endif
+ 10*4 + 22*5 /* FPR */
+ 2*(10*6 + 22*7) /* AVRh, AVRl */
++ 10*5 + 22*6 /* VSR */
+ 8*5 /* CRF */];
static TCGv cpu_gpr[32];
#if !defined(TARGET_PPC64)
@@ -58,6 +59,7 @@ static TCGv cpu_gprh[32];
#endif
static TCGv_i64 cpu_fpr[32];
static TCGv_i64 cpu_avrh[32], cpu_avrl[32];
+static TCGv_i64 cpu_vsr[32];
static TCGv_i32 cpu_crf[8];
static TCGv cpu_nip;
static TCGv cpu_msr;
@@ -137,6 +139,11 @@ void ppc_translate_init(void)
#endif
p += (i < 10) ? 6 : 7;
cpu_reg_names_size -= (i < 10) ? 6 : 7;
+snprintf(p, cpu_reg_names_size, "vsr%d", i);
+cpu_vsr[i] = tcg_global_mem_new_i64(TCG_AREG0,
+ offsetof(CPUPPCState, vsr[i]), p);
+p += (i < 10) ? 5 : 6;
+cpu_reg_names_size -= (i < 10) ? 5 : 6;
}
cpu_nip = tcg_global_mem_new(TCG_AREG0,
@@ -6980,6 +6987,26 @@ GEN_VAFORM_PAIRED(vmsumshm, vmsumshs, 20
GEN_VAFORM_PAIRED(vsel, vperm, 21)
GEN_VAFORM_PAIRED(vmaddfp, vnmsubfp, 23)
+/*** VSX extension ***/
+
+static inline TCGv_i64 cpu_vsrh(int n)
+{
+if (n < 32) {
+return cpu_fpr[n];
+} else {
+return cpu_avrh[n-32];
+}
+}
+
+static inline TCGv_i64 cpu_vsrl(int n)
+{
+if (n < 32) {
+return cpu_vsr[n];
+} else {
+return cpu_avrl[n-32];
+}
+}
+
/*** SPE extension ***/
/* Register moves */
[Qemu-devel] [PATCH 5/7] Add lxvd2x
From: Tom Musta
This patch adds the lxvd2x instruction.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/translate.c
===
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -7007,6 +7007,22 @@ static inline TCGv_i64 cpu_vsrl(int n)
}
}
+static void gen_lxvd2x(DisasContext *ctx)
+{
+TCGv EA;
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+gen_set_access_type(ctx, ACCESS_INT);
+EA = tcg_temp_new();
+gen_addr_reg_index(ctx, EA);
+gen_qemu_ld64(ctx, cpu_vsrh(xT(ctx->opcode)), EA);
+tcg_gen_addi_tl(EA, EA, 8);
+gen_qemu_ld64(ctx, cpu_vsrl(xT(ctx->opcode)), EA);
+tcg_temp_free(EA);
+}
+
/*** SPE extension ***/
/* Register moves */
@@ -9456,6 +9472,8 @@ GEN_VAFORM_PAIRED(vmsumshm, vmsumshs, 20
GEN_VAFORM_PAIRED(vsel, vperm, 21),
GEN_VAFORM_PAIRED(vmaddfp, vnmsubfp, 23),
+GEN_HANDLER_E(lxvd2x, 0x1F, 0x0C, 0x1A, 0, PPC_NONE, PPC2_VSX),
+
#undef GEN_SPE
#define GEN_SPE(name0, name1, opc2, opc3, inval0, inval1, type) \
GEN_OPCODE_DUAL(name0##_##name1, 0x04, opc2, opc3, inval0, inval1, type,
PPC_NONE)
[Qemu-devel] [PATCH 7/7] Add xxpermdi
From: Tom Musta
This patch adds the xxpermdi instruction. The instruction
uses bits 22, 23, 29 and 30 for non-opcode fields (DM, AX
and BX). This results in overloading of the opcode table
with aliases, which can be seen in the GEN_XX3FORM_DM
macro.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/translate.c
===
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -7039,10 +7039,28 @@ static void gen_stxvd2x(DisasContext *ct
tcg_temp_free(EA);
}
+static void gen_xxpermdi(DisasContext *ctx)
+{
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+
+if ((DM(ctx->opcode) & 2) == 0) {
+tcg_gen_mov_i64(cpu_vsrh(xT(ctx->opcode)), cpu_vsrh(xA(ctx->opcode)));
+} else {
+tcg_gen_mov_i64(cpu_vsrh(xT(ctx->opcode)), cpu_vsrl(xA(ctx->opcode)));
+}
+if ((DM(ctx->opcode) & 1) == 0) {
+tcg_gen_mov_i64(cpu_vsrl(xT(ctx->opcode)), cpu_vsrh(xB(ctx->opcode)));
+} else {
+tcg_gen_mov_i64(cpu_vsrl(xT(ctx->opcode)), cpu_vsrl(xB(ctx->opcode)));
+}
+}
+
/*** SPE extension ***/
/* Register moves */
-
static inline void gen_evmra(DisasContext *ctx)
{
@@ -9492,6 +9510,27 @@ GEN_HANDLER_E(lxvd2x, 0x1F, 0x0C, 0x1A,
GEN_HANDLER_E(stxvd2x, 0x1F, 0xC, 0x1E, 0, PPC_NONE, PPC2_VSX),
+#undef GEN_XX3FORM_DM
+#define GEN_XX3FORM_DM(name, opc2, opc3) \
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x00, opc3|0x00, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x01, opc3|0x00, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x02, opc3|0x00, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x03, opc3|0x00, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x00, opc3|0x04, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x01, opc3|0x04, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x02, opc3|0x04, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x03, opc3|0x04, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x00, opc3|0x08, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x01, opc3|0x08, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x02, opc3|0x08, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x03, opc3|0x08, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x00, opc3|0x0C, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x01, opc3|0x0C, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x02, opc3|0x0C, 0, PPC_NONE,
PPC2_VSX),\
+GEN_HANDLER2_E(name, #name, 0x3C, opc2|0x03, opc3|0x0C, 0, PPC_NONE, PPC2_VSX)
+
+GEN_XX3FORM_DM(xxpermdi, 0x08, 0x01),
+
#undef GEN_SPE
#define GEN_SPE(name0, name1, opc2, opc3, inval0, inval1, type) \
GEN_OPCODE_DUAL(name0##_##name1, 0x04, opc2, opc3, inval0, inval1, type,
PPC_NONE)
[Qemu-devel] [PATCH 6/7] Add stxvd2x
From: Tom Musta
This patch adds the stxvd2x instruction.
Signed-off-by: Tom Musta
Signed-off-by: Anton Blanchard
---
Index: b/target-ppc/translate.c
===
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -7023,6 +7023,22 @@ static void gen_lxvd2x(DisasContext *ctx
tcg_temp_free(EA);
}
+static void gen_stxvd2x(DisasContext *ctx)
+{
+TCGv EA;
+if (unlikely(!ctx->vsx_enabled)) {
+gen_exception(ctx, POWERPC_EXCP_VSXU);
+return;
+}
+gen_set_access_type(ctx, ACCESS_INT);
+EA = tcg_temp_new();
+gen_addr_reg_index(ctx, EA);
+gen_qemu_st64(ctx, cpu_vsrh(xS(ctx->opcode)), EA);
+tcg_gen_addi_tl(EA, EA, 8);
+gen_qemu_st64(ctx, cpu_vsrl(xS(ctx->opcode)), EA);
+tcg_temp_free(EA);
+}
+
/*** SPE extension ***/
/* Register moves */
@@ -9474,6 +9490,8 @@ GEN_VAFORM_PAIRED(vmaddfp, vnmsubfp, 23)
GEN_HANDLER_E(lxvd2x, 0x1F, 0x0C, 0x1A, 0, PPC_NONE, PPC2_VSX),
+GEN_HANDLER_E(stxvd2x, 0x1F, 0xC, 0x1E, 0, PPC_NONE, PPC2_VSX),
+
#undef GEN_SPE
#define GEN_SPE(name0, name1, opc2, opc3, inval0, inval1, type) \
GEN_OPCODE_DUAL(name0##_##name1, 0x04, opc2, opc3, inval0, inval1, type,
PPC_NONE)
[Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default
Inverting the way sandbox handles arguments, making possible to have no
argument and still have '-sandbox on' enabled.
Signed-off-by: Eduardo Otubo
---
The option '-sandbox on' is now used by default by virt-test[0] -- it has been
merged into the 'next' branch and will be available in the next release,
meaning we have a back support for regression tests if anything breaks because
of some missing system call not listed in the whitelist.
This being said, I think it makes sense to have this option set to 'on' by
default in the next Qemu version. It's been a while since no missing syscall is
reported and at this point the whitelist seems to be pretty mature.
[0] -
https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8ec0f18365dcba714
qemu-options.hx | 4 ++--
vl.c| 47 ---
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 5dc8b75..315a86d 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2982,13 +2982,13 @@ Old param mode (ARM only).
ETEXI
DEF("sandbox", HAS_ARG, QEMU_OPTION_sandbox, \
-"-sandbox Enable seccomp mode 2 system call filter (default
'off').\n",
+"-sandbox Enable seccomp mode 2 system call filter (default
'on').\n",
QEMU_ARCH_ALL)
STEXI
@item -sandbox @var{arg}
@findex -sandbox
Enable Seccomp mode 2 system call filter. 'on' will enable syscall filtering
and 'off' will
-disable it. The default is 'off'.
+disable it. The default is 'on'.
ETEXI
DEF("readconfig", HAS_ARG, QEMU_OPTION_readconfig,
diff --git a/vl.c b/vl.c
index b42ac67..ae3bdc9 100644
--- a/vl.c
+++ b/vl.c
@@ -529,6 +529,20 @@ static QemuOptsList qemu_msg_opts = {
},
};
+static QemuOpts *qemu_get_sandbox_opts(void)
+{
+QemuOptsList *list;
+QemuOpts *opts;
+
+list = qemu_find_opts("sandbox");
+assert(list);
+opts = qemu_opts_find(list, NULL);
+if (!opts) {
+opts = qemu_opts_create_nofail(list);
+}
+return opts;
+}
+
/**
* Get machine options
*
@@ -960,24 +974,9 @@ static int bt_parse(const char *opt)
return 1;
}
-static int parse_sandbox(QemuOpts *opts, void *opaque)
+static bool sandbox_enabled(bool default_usb)
{
-/* FIXME: change this to true for 1.3 */
-if (qemu_opt_get_bool(opts, "enable", false)) {
-#ifdef CONFIG_SECCOMP
-if (seccomp_start() < 0) {
-qerror_report(ERROR_CLASS_GENERIC_ERROR,
- "failed to install seccomp syscall filter in the
kernel");
-return -1;
-}
-#else
-qerror_report(ERROR_CLASS_GENERIC_ERROR,
- "sandboxing request but seccomp is not compiled into
this build");
-return -1;
-#endif
-}
-
-return 0;
+return qemu_opt_get_bool(qemu_get_sandbox_opts(), "sandbox", default_usb);
}
bool usb_enabled(bool default_usb)
@@ -3806,8 +3805,18 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
-if (qemu_opts_foreach(qemu_find_opts("sandbox"), parse_sandbox, NULL, 0)) {
-exit(1);
+if (sandbox_enabled(true)) {
+#ifdef CONFIG_SECCOMP
+if (seccomp_start() < 0) {
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ "failed to install seccomp syscall filter in the
kernel");
+return -1;
+}
+#else
+qerror_report(ERROR_CLASS_GENERIC_ERROR,
+ "sandboxing request but seccomp is not compiled into
this build");
+return -1;
+#endif
}
#ifndef _WIN32
--
1.8.3.1
Re: [Qemu-devel] [RFC v5 2/5] hw/arm/digic: prepare DIGIC-based boards support
On Thu, 17 Oct 2013 20:17:15 +0100
Peter Maydell wrote:
> On 17 October 2013 19:51, Georg Hofstetter wrote:
> > flash (ROM1) on these cameras starts at 0xF800 and is either
> > 0x0080, 0x0100 ox 0x0200 large. just like with every
> > chip-selected memory, where the CS/EN line is selected by address masks,
> > addressing beyond the size memory repeats the content over and over.
> >
> > ROM0 (0xF000) is rarely used.
> >
> > The ARM in DIGIC has the high vectors selected by hardware and so the
> > reset vector is 0x. There you will find a bootloader.
> > Due to the memories repeating over and over starting from 0xF800,
> > the CPU will read from 0xF87F, 0xF8FF or 0xF9FF, depending
> > on flash size (see above).
> >
> > This kind of addressing beyond real flash end and wrapping over is
> > intentionally used by canon in multiple places - even in the main
> > firmware and when reflashing.
> > Some blocks are reflashed on a regular basis. They are used for
> > properties, which are the configuration area.
>
> Thanks for this explanation of the hardware.
>
> > If you want to make the emulator behave like the real hardware, then you
> > have to:
> >
> > - reset to 0x
>
> Yep. This implies having a cpu property corresponding to "enable
> hivecs from bootup" (matching the h/w config signal), and making
> sure cpu reset honours it; that's fairly easy.
>
> > - place ROM0 at 0xF000
> > - place ROM1 at 0xF800
> > - make the memory subsystem address correctly: (pseudocode)
> > if((virt_addr & 0xF800) == 0xF000)
> > {
> > real_addr = 0xF000 | (virt_addr & (rom0_size - 1));
> > }
> > if((virt_addr & 0xF800) == 0xF800)
> > {
> > real_addr = 0xF800 | (virt_addr & (rom1_size - 1));
> > }
>
> The easy way to do this is just to use memory region aliases
> to repeat the ROM through the whole area; you can do that
> in the board model without having to mess with the memory
> subsystem itself.
Hmm. The current DIGIC patchseries already has the functionality like this!
Here is my console log:
$ xxd -g 1 -l 0x40 ./canon-a1100-rom1.bin
000: 12 00 00 ea fe ff ff ea fe ff ff ea fe ff ff ea
010: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea
020: 62 61 72 65 62 6f 78 00 00 00 10 00 84 5e 01 00 barebox..^..
030: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
$ ./arm-softmmu/qemu-system-arm -M canon-a1100 -bios ./canon-a1100-rom1.bin
-serial stdio
Switch to console [cs0]
barebox 2013.08.0-00267-g85b83fb #125 Thu Aug 29 07:58:57 MSK 2013
Board: Canon PowerShot A1100 IS
digic-gpio c022.gpio: probed gpiochip-1 with base 0
cfi_flash f800.flash: found cfi flash at f800, size 4194304
malloc space: 0x0010 -> 0x002f (size 2 MiB)
Open /dev/env0 No such file or directory
no valid environment found on /dev/env0. Using default environment
running /env/bin/init...
canon> /
canon> / md -b 0xf800+0x40
f800: 12 00 00 ea fe ff ff ea fe ff ff ea fe ff ff ea
f810: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea
f820: 62 61 72 65 62 6f 78 00 00 00 10 00 84 5e 01 00barebox..^..
f830: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
canon> / md -b 0xf840+0x40
f840: 12 00 00 ea fe ff ff ea fe ff ff ea fe ff ff ea
f8400010: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea
f8400020: 62 61 72 65 62 6f 78 00 00 00 10 00 84 5e 01 00barebox..^..
f8400030: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
canon> / md -b 0xf900+0x40
f900: 12 00 00 ea fe ff ff ea fe ff ff ea fe ff ff ea
f910: fe ff ff ea fe ff ff ea fe ff ff ea fe ff ff ea
f920: 62 61 72 65 62 6f 78 00 00 00 10 00 84 5e 01 00barebox..^..
f930: 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
canon> /
--
Best regards,
Antony Pavlov
[Qemu-devel] [PATCH] save_page: replace block_offset with MemoryRegion
This patch exports MemoryRegion to save_page hook, replacing
argument ram_addr_t block_offset with a MemoryRegion suggested
by Paolo Bonzini.
Forgot to include this patch to the localhost migration series
sent earlier today. Will adjust it in migration-local.c later if
this patch could be merged first, otherwise I'll pick it to my
next update of the series.
Signed-off-by: Lei Li
---
arch_init.c | 4 ++--
include/migration/migration.h | 2 +-
include/migration/qemu-file.h | 8
migration-rdma.c | 4 ++--
savevm.c | 8
5 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 7545d96..a9b97be 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -485,8 +485,8 @@ static int ram_save_block(QEMUFile *f, bool last_stage)
/* In doubt sent page as normal */
bytes_sent = -1;
-ret = ram_control_save_page(f, block->offset,
- offset, TARGET_PAGE_SIZE, &bytes_sent);
+ret = ram_control_save_page(f, mr, offset, TARGET_PAGE_SIZE,
+&bytes_sent);
if (ret != RAM_SAVE_CONTROL_NOT_SUPP) {
if (ret != RAM_SAVE_CONTROL_DELAYED) {
diff --git a/include/migration/migration.h b/include/migration/migration.h
index 140e6b4..2b39669 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -158,7 +158,7 @@ void ram_control_load_hook(QEMUFile *f, uint64_t flags);
#define RAM_SAVE_CONTROL_NOT_SUPP -1000
#define RAM_SAVE_CONTROL_DELAYED -2000
-size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
+size_t ram_control_save_page(QEMUFile *f, MemoryRegion *mr,
ram_addr_t offset, size_t size,
int *bytes_sent);
diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
index 0f757fb..d73dc4b 100644
--- a/include/migration/qemu-file.h
+++ b/include/migration/qemu-file.h
@@ -77,10 +77,10 @@ typedef int (QEMURamHookFunc)(QEMUFile *f, void *opaque,
uint64_t flags);
* is saved (such as RDMA, for example.)
*/
typedef size_t (QEMURamSaveFunc)(QEMUFile *f, void *opaque,
- ram_addr_t block_offset,
- ram_addr_t offset,
- size_t size,
- int *bytes_sent);
+ MemoryRegion *mr,
+ ram_addr_t offset,
+ size_t size,
+ int *bytes_sent);
typedef struct QEMUFileOps {
QEMUFilePutBufferFunc *put_buffer;
diff --git a/migration-rdma.c b/migration-rdma.c
index f94f3b4..ae04de4 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -2699,7 +2699,7 @@ static int qemu_rdma_close(void *opaque)
* the protocol because most transfers are sent
asynchronously.
*/
static size_t qemu_rdma_save_page(QEMUFile *f, void *opaque,
- ram_addr_t block_offset, ram_addr_t offset,
+ MemoryRegion *mr, ram_addr_t offset,
size_t size, int *bytes_sent)
{
QEMUFileRDMA *rfile = opaque;
@@ -2716,7 +2716,7 @@ static size_t qemu_rdma_save_page(QEMUFile *f, void
*opaque,
* is full, or the page doen't belong to the current chunk,
* an actual RDMA write will occur and a new chunk will be formed.
*/
-ret = qemu_rdma_write(f, rdma, block_offset, offset, size);
+ret = qemu_rdma_write(f, rdma, mr->ram_addr, offset, size);
if (ret < 0) {
fprintf(stderr, "rdma migration: write error! %d\n", ret);
goto err;
diff --git a/savevm.c b/savevm.c
index 2f631d4..3ee256e 100644
--- a/savevm.c
+++ b/savevm.c
@@ -661,12 +661,12 @@ void ram_control_load_hook(QEMUFile *f, uint64_t flags)
}
}
-size_t ram_control_save_page(QEMUFile *f, ram_addr_t block_offset,
- ram_addr_t offset, size_t size, int *bytes_sent)
+size_t ram_control_save_page(QEMUFile *f, MemoryRegion *mr, ram_addr_t offset,
+ size_t size, int *bytes_sent)
{
if (f->ops->save_page) {
-int ret = f->ops->save_page(f, f->opaque, block_offset,
-offset, size, bytes_sent);
+int ret = f->ops->save_page(f, f->opaque, mr, offset,
+size, bytes_sent);
if (ret != RAM_SAVE_CONTROL_DELAYED) {
if (bytes_sent && *bytes_sent > 0) {
--
1.7.11.7
Re: [Qemu-devel] [PATCH 6/6] qapi: add doc for QEvent
于 2013/10/22 14:55, Wenchao Xia 写道:
于 2013/10/22 5:00, Eric Blake 写道:
On 10/21/2013 03:16 AM, Wenchao Xia wrote:
Signed-off-by: Wenchao Xia
---
qapi-schema.json | 56
++
1 files changed, 56 insertions(+), 0 deletions(-)
Incomplete. Now that you are actually using the enum (see the spot I
pointed out in 5/6), you ALSO need to change:
-{ 'type': 'EventInfo', 'data': {'name': 'str'} }
+{ 'type': 'EventInfo', 'data': {'name': 'QEvent'} }
and make use of the enum in the QAPI documentation.
I just found QEvent is a int(enum) so this change can't be done.
Is there a way to tell use QEvent's correspond string? Add a new
way to specify enum's correspond string automatically? for example:
{ 'type': 'EventInfo', 'data': {'name': '&QEvent'}
I just found visitor will do it for me automatically, so it is not
a problem, sorry for the disturbing messsage.
Re: [Qemu-devel] [v2 07/13] Add VSX Scalar Move Instructions
On 10/22/2013 1:31 AM, Paolo Bonzini wrote:
Il 11/10/2013 14:02, Tom Musta ha scritto:
+case OP_CPSGN: { \
+TCGv_i64 xa = tcg_temp_new(); \
+tcg_gen_mov_i64(xa, cpu_vsrh(xA(ctx->opcode))); \
+tcg_gen_andi_i64(xa, xa, (sgn_mask)); \
+tcg_gen_andi_i64(xb, xb, ~(sgn_mask));\
+tcg_gen_or_i64(xb, xb, xa); \
+tcg_temp_free(xa);\
+break;\
You might get slightly better generated code if you move the sgn_mask
immediate to a temporary and then use and+andc.
Paolo
Thank you for the suggestion, Paolo. I will recode, retest and resubmit this
one and patch 8.
Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default
On Tue, Oct 22, 2013 at 12:21 PM, Eduardo Otubo
wrote:
> Inverting the way sandbox handles arguments, making possible to have no
> argument and still have '-sandbox on' enabled.
>
> Signed-off-by: Eduardo Otubo
> ---
>
> The option '-sandbox on' is now used by default by virt-test[0] -- it has been
> merged into the 'next' branch and will be available in the next release,
> meaning we have a back support for regression tests if anything breaks because
> of some missing system call not listed in the whitelist.
>
> This being said, I think it makes sense to have this option set to 'on' by
> default in the next Qemu version. It's been a while since no missing syscall
> is
> reported and at this point the whitelist seems to be pretty mature.
>
> [0] -
> https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8ec0f18365dcba714
This breaks hot_add of a network device that uses a script= argument, correct?
If so, this cannot be made default.
Regards,
Anthony Liguori
>
> qemu-options.hx | 4 ++--
> vl.c| 47 ---
> 2 files changed, 30 insertions(+), 21 deletions(-)
>
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 5dc8b75..315a86d 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2982,13 +2982,13 @@ Old param mode (ARM only).
> ETEXI
>
> DEF("sandbox", HAS_ARG, QEMU_OPTION_sandbox, \
> -"-sandbox Enable seccomp mode 2 system call filter (default
> 'off').\n",
> +"-sandbox Enable seccomp mode 2 system call filter (default
> 'on').\n",
> QEMU_ARCH_ALL)
> STEXI
> @item -sandbox @var{arg}
> @findex -sandbox
> Enable Seccomp mode 2 system call filter. 'on' will enable syscall filtering
> and 'off' will
> -disable it. The default is 'off'.
> +disable it. The default is 'on'.
> ETEXI
>
> DEF("readconfig", HAS_ARG, QEMU_OPTION_readconfig,
> diff --git a/vl.c b/vl.c
> index b42ac67..ae3bdc9 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -529,6 +529,20 @@ static QemuOptsList qemu_msg_opts = {
> },
> };
>
> +static QemuOpts *qemu_get_sandbox_opts(void)
> +{
> +QemuOptsList *list;
> +QemuOpts *opts;
> +
> +list = qemu_find_opts("sandbox");
> +assert(list);
> +opts = qemu_opts_find(list, NULL);
> +if (!opts) {
> +opts = qemu_opts_create_nofail(list);
> +}
> +return opts;
> +}
> +
> /**
> * Get machine options
> *
> @@ -960,24 +974,9 @@ static int bt_parse(const char *opt)
> return 1;
> }
>
> -static int parse_sandbox(QemuOpts *opts, void *opaque)
> +static bool sandbox_enabled(bool default_usb)
> {
> -/* FIXME: change this to true for 1.3 */
> -if (qemu_opt_get_bool(opts, "enable", false)) {
> -#ifdef CONFIG_SECCOMP
> -if (seccomp_start() < 0) {
> -qerror_report(ERROR_CLASS_GENERIC_ERROR,
> - "failed to install seccomp syscall filter in the
> kernel");
> -return -1;
> -}
> -#else
> -qerror_report(ERROR_CLASS_GENERIC_ERROR,
> - "sandboxing request but seccomp is not compiled into
> this build");
> -return -1;
> -#endif
> -}
> -
> -return 0;
> +return qemu_opt_get_bool(qemu_get_sandbox_opts(), "sandbox",
> default_usb);
> }
>
> bool usb_enabled(bool default_usb)
> @@ -3806,8 +3805,18 @@ int main(int argc, char **argv, char **envp)
> exit(1);
> }
>
> -if (qemu_opts_foreach(qemu_find_opts("sandbox"), parse_sandbox, NULL,
> 0)) {
> -exit(1);
> +if (sandbox_enabled(true)) {
> +#ifdef CONFIG_SECCOMP
> +if (seccomp_start() < 0) {
> +qerror_report(ERROR_CLASS_GENERIC_ERROR,
> + "failed to install seccomp syscall filter in the
> kernel");
> +return -1;
> +}
> +#else
> +qerror_report(ERROR_CLASS_GENERIC_ERROR,
> + "sandboxing request but seccomp is not compiled into
> this build");
> +return -1;
> +#endif
> }
>
> #ifndef _WIN32
> --
> 1.8.3.1
>
Re: [Qemu-devel] [PATCHv5 04/17] block: add logical block provisioning info to BlockDriverInfo
On 10/20/2013 04:42 PM, Peter Lieven wrote: > Signed-off-by: Peter Lieven > --- > include/block/block.h | 16 > 1 file changed, 16 insertions(+) > Reviewed-by: Eric Blake -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCHv5 05/17] block: add wrappers for logical block provisioning information
On 10/20/2013 04:42 PM, Peter Lieven wrote: > This adds 2 wrappers to read the unallocated_blocks_are_zero and > can_write_zeroes_with_unmap info from the BDI. The wrappers are > required to check for the existence of a backing_hd and > if the devices are opened with the correct flags. > > Signed-off-by: Peter Lieven > --- > block.c | 30 ++ > include/block/block.h |2 ++ > 2 files changed, 32 insertions(+) > Reviewed-by: Eric Blake -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH v2 0/2] fw_cfg: add etc/e820
Hi, Mini patch series adds a new file to fw_cfg, holding a e820 map with both reservations and ram regions. The existing fw_cfg entry with e820 reservations only is left as-is. This allows to (a) support more than 1TB of memory (which is impossible using the current cmos entries) and (b) support non-contignous memory in the furure without having to introduce a new interface for that. please review, Gerd Gerd Hoffmann (2): pc: add etc/e820 fw_cfg file pc: register e820 entries for ram hw/i386/pc.c | 41 ++--- 1 file changed, 30 insertions(+), 11 deletions(-) -- 1.8.3.1
[Qemu-devel] [PATCH 2/2] pc: register e820 entries for ram
So RAM shows up in the new etc/e820 fw_cfg file.
Cc: Andrea Arcangeli
Signed-off-by: Gerd Hoffmann
---
hw/i386/pc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0500ab6..d98cb25 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1151,12 +1151,14 @@ FWCfgState *pc_memory_init(MemoryRegion *system_memory,
memory_region_init_alias(ram_below_4g, NULL, "ram-below-4g", ram,
0, below_4g_mem_size);
memory_region_add_subregion(system_memory, 0, ram_below_4g);
+e820_add_entry(0, below_4g_mem_size, E820_RAM);
if (above_4g_mem_size > 0) {
ram_above_4g = g_malloc(sizeof(*ram_above_4g));
memory_region_init_alias(ram_above_4g, NULL, "ram-above-4g", ram,
below_4g_mem_size, above_4g_mem_size);
memory_region_add_subregion(system_memory, 0x1ULL,
ram_above_4g);
+e820_add_entry(0x1ULL, above_4g_mem_size, E820_RAM);
}
--
1.8.3.1
[Qemu-devel] [PATCH 1/2] pc: add etc/e820 fw_cfg file
Unlike the existing FW_CFG_E820_TABLE entry which carries reservations
only the new etc/e820 file also has entries for RAM.
Format is simliar to the FW_CFG_E820_TABLE, it is a simple list of
e820_entry structs. Unlike FW_CFG_E820_TABLE it has no count though
as the number of entries can be figured from the file size.
Cc: Andrea Arcangeli
Signed-off-by: Gerd Hoffmann
---
hw/i386/pc.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0c313fe..0500ab6 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -89,7 +89,9 @@ struct e820_table {
struct e820_entry entry[E820_NR_ENTRIES];
} QEMU_PACKED __attribute((__aligned__(4)));
-static struct e820_table e820_table;
+static struct e820_table e820_reserve;
+static struct e820_entry *e820_table;
+static unsigned e820_entries;
struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
void gsi_handler(void *opaque, int n, int level)
@@ -576,19 +578,32 @@ static void handle_a20_line_change(void *opaque, int irq,
int level)
int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
{
-int index = le32_to_cpu(e820_table.count);
+int index = le32_to_cpu(e820_reserve.count);
struct e820_entry *entry;
-if (index >= E820_NR_ENTRIES)
-return -EBUSY;
-entry = &e820_table.entry[index++];
+if (type != E820_RAM) {
+/* old FW_CFG_E820_TABLE entry -- reservations only */
+if (index >= E820_NR_ENTRIES) {
+return -EBUSY;
+}
+entry = &e820_reserve.entry[index++];
+
+entry->address = cpu_to_le64(address);
+entry->length = cpu_to_le64(length);
+entry->type = cpu_to_le32(type);
+
+e820_reserve.count = cpu_to_le32(index);
+}
-entry->address = cpu_to_le64(address);
-entry->length = cpu_to_le64(length);
-entry->type = cpu_to_le32(type);
+/* new "etc/e820" file -- include ram too */
+e820_table = g_realloc(e820_table,
+ sizeof(struct e820_entry) * (e820_entries+1));
+e820_table[e820_entries].address = cpu_to_le64(address);
+e820_table[e820_entries].length = cpu_to_le64(length);
+e820_table[e820_entries].type = cpu_to_le32(type);
+e820_entries++;
-e820_table.count = cpu_to_le32(index);
-return index;
+return e820_entries;
}
/* Calculates the limit to CPU APIC ID values
@@ -639,7 +654,9 @@ static FWCfgState *bochs_bios_init(void)
fw_cfg_add_bytes(fw_cfg, FW_CFG_SMBIOS_ENTRIES,
smbios_table, smbios_len);
fw_cfg_add_bytes(fw_cfg, FW_CFG_E820_TABLE,
- &e820_table, sizeof(e820_table));
+ &e820_reserve, sizeof(e820_reserve));
+fw_cfg_add_file(fw_cfg, "etc/e820", e820_table,
+sizeof(struct e820_entry) * e820_entries);
fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, &hpet_cfg, sizeof(hpet_cfg));
/* allocate memory for the NUMA channel: one (64bit) word for the number
--
1.8.3.1
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
Eric Blake, le Tue 22 Oct 2013 11:52:11 +0100, a écrit : > On 10/22/2013 11:48 AM, Eric Blake wrote: > > HMP can let the user abbreviate to net=10.0.2.2/24, > > The command line, just like HMP, can use shorthand for convenience. How are these usually defined? A quick search didn't provide me an example. Samuel
[Qemu-devel] [PATCH v4] integrator: fix Linux boot failure by emulating dbg region
From: Alex Bennée
Commit 9b8c69243 (since reverted) broke the ability to boot the kernel
as the value returned by unassigned_mem_read returned non-zero and left
the kernel looping forever waiting for it to change (see
integrator_led_set in the kernel code).
Relying on a varying implementation detail is incorrect anyway so this
introduces a basic stub of a memory region for the debug/LED section
on the integrator board.
Signed-off-by: Alex Bennée
---
Changes for v4:
* Moved hw/arm/integrator_debug.c -> hw/misc/arm_integrator_debug.c
default-configs/arm-softmmu.mak| 1 +
hw/arm/integratorcp.c | 2 +
hw/misc/Makefile.objs | 1 +
hw/misc/arm_integrator_debug.c | 103 +
include/hw/misc/arm_integrator_debug.h | 18 ++
5 files changed, 125 insertions(+)
create mode 100644 hw/misc/arm_integrator_debug.c
create mode 100644 include/hw/misc/arm_integrator_debug.h
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index d13bc2b..7e69137 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -79,3 +79,4 @@ CONFIG_VERSATILE_PCI=y
CONFIG_VERSATILE_I2C=y
CONFIG_SDHCI=y
+CONFIG_INTEGRATOR_DEBUG=y
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index 2ef93ed..c44b2a4 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -11,6 +11,7 @@
#include "hw/devices.h"
#include "hw/boards.h"
#include "hw/arm/arm.h"
+#include "hw/misc/arm_integrator_debug.h"
#include "net/net.h"
#include "exec/address-spaces.h"
#include "sysemu/sysemu.h"
@@ -508,6 +509,7 @@ static void integratorcp_init(QEMUMachineInitArgs *args)
icp_control_init(0xcb00);
sysbus_create_simple("pl050_keyboard", 0x1800, pic[3]);
sysbus_create_simple("pl050_mouse", 0x1900, pic[4]);
+sysbus_create_simple(TYPE_INTEGRATOR_DEBUG, 0x1a00, 0);
sysbus_create_varargs("pl181", 0x1c00, pic[23], pic[24], NULL);
if (nd_table[0].used)
smc91c111_init(&nd_table[0], 0xc800, pic[27]);
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 2578e29..cca5c05 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -10,6 +10,7 @@ obj-$(CONFIG_VMPORT) += vmport.o
# ARM devices
common-obj-$(CONFIG_PL310) += arm_l2x0.o
+common-obj-$(CONFIG_INTEGRATOR_DEBUG) += arm_integrator_debug.o
# PKUnity SoC devices
common-obj-$(CONFIG_PUV3) += puv3_pm.o
diff --git a/hw/misc/arm_integrator_debug.c b/hw/misc/arm_integrator_debug.c
new file mode 100644
index 000..f1ebdd4
--- /dev/null
+++ b/hw/misc/arm_integrator_debug.c
@@ -0,0 +1,103 @@
+/*
+ * LED, Switch and Debug control registers for ARM Integrator Boards
+ *
+ * This is currently a stub for this functionality but at least
+ * ensures something other than unassigned_mem_read() handles access
+ * to this area.
+ *
+ * The real h/w is described at:
+ *
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0159b/Babbfijf.html
+ *
+ * Copyright (c) 2013 Alex Bennée
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "hw/hw.h"
+#include "hw/sysbus.h"
+#include "exec/address-spaces.h"
+#include "hw/misc/arm_integrator_debug.h"
+
+#define INTEGRATOR_DEBUG(obj) \
+OBJECT_CHECK(IntegratorDebugState, (obj), TYPE_INTEGRATOR_DEBUG)
+
+typedef struct {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
+uint32_t alpha;
+uint32_t leds;
+uint32_t switches;
+} IntegratorDebugState;
+
+static uint64_t intdbg_control_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+switch (offset >> 2) {
+case 0: /* ALPHA */
+case 1: /* LEDS */
+case 2: /* SWITCHES */
+qemu_log_mask(LOG_UNIMP,
+ "%s: returning zero from %" HWADDR_PRIx ":%u\n",
+ __func__, offset, size);
+return 0;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Bad offset %" HWADDR_PRIx,
+ __func__, offset);
+return 0;
+}
+}
+
+static void intdbg_control_write(void *opaque, hwaddr offset,
+ uint64_t value, unsigned size)
+{
+switch (offset >> 2) {
+case 1: /* ALPHA */
+case 2: /* LEDS */
+case 3: /* SWITCHES */
+/* Nothing interesting implemented yet. */
+qemu_log_mask(LOG_UNIMP,
+ "%s: ignoring write of %" PRIu64
+ " to %" HWADDR_PRIx ":%u\n",
+ __func__, value, offset, size);
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: write of %" PRIu64
+ " to bad offset %" HWADDR_PRIx "\n",
+ __func__, value, offset);
+}
+}
+
+static const MemoryRegionOps intdbg_control_ops = {
+.read = intdbg_control_read,
+
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
On 10/22/2013 03:11 PM, Samuel Thibault wrote: > Eric Blake, le Tue 22 Oct 2013 11:52:11 +0100, a écrit : >> On 10/22/2013 11:48 AM, Eric Blake wrote: >>> HMP can let the user abbreviate to net=10.0.2.2/24, >> >> The command line, just like HMP, can use shorthand for convenience. > > How are these usually defined? A quick search didn't provide me an > example. Hmm, I'm not actually sure myself. I know Keven recently added some code in his blockdev parsing that aliased old commands to re-inject themselves back into a QDict in the preferred spelling, before passing the QDict on down to the final client that handles the options; maybe he has some better ideas on creating a command line shorthand while still keeping QMP fully-structured. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] linux-user: create target_structs header to place ipc_perm and shmid_ds
Ping
http://patchwork.ozlabs.org/patch/281527/
From: Petar Jovanovic
Sent: Tuesday, October 15, 2013 2:44 PM
To: Petar Jovanovic; qemu-devel@nongnu.org
Cc: aurel...@aurel32.net; riku.voi...@linaro.org; peter.mayd...@linaro.org
Subject: RE: [PATCH] linux-user: create target_structs header to place ipc_perm
and shmid_ds
Ping
http://patchwork.ozlabs.org/patch/281527/
Regards,
Petar
From: Petar Jovanovic [petar.jovano...@rt-rk.com]
Sent: Tuesday, October 08, 2013 7:32 PM
To: qemu-devel@nongnu.org
Cc: Petar Jovanovic; aurel...@aurel32.net; riku.voi...@linaro.org;
peter.mayd...@linaro.org
Subject: [PATCH] linux-user: create target_structs header to place ipc_perm and
shmid_ds
From: Petar Jovanovic
Creating target_structs header in linux-user/$arch/ and making
target_ipc_perm and target_shmid_ds its first inhabitants.
The struct defintions may/should be further fine-tuned by arch maintainers.
Signed-off-by: Petar Jovanovic
---
As suggested, this header can be used to move all target-specific struct
definitions. All arch maintainers are welcome to double check definitions
of target_shmid_ds and target_ipc_perm. The definitions have been either
improved by comparing the actual layout to the one in arch-toolchains
headers or remain the same (i.e. as they are now in the code).
linux-user/aarch64/target_structs.h| 40 +
linux-user/alpha/target_structs.h | 30 +
linux-user/arm/target_structs.h| 34 ++
linux-user/cris/target_structs.h | 40 +
linux-user/i386/target_structs.h | 40 +
linux-user/m68k/target_structs.h | 40 +
linux-user/microblaze/target_structs.h | 40 +
linux-user/mips/target_structs.h | 30 +
linux-user/mips64/target_structs.h |2 +
linux-user/openrisc/target_structs.h | 40 +
linux-user/ppc/target_structs.h| 42 ++
linux-user/qemu.h |1 +
linux-user/s390x/target_structs.h | 45 +++
linux-user/sh4/target_structs.h| 40 +
linux-user/sparc/target_structs.h | 45 +++
linux-user/sparc64/target_structs.h| 40 +
linux-user/syscall.c | 76
linux-user/unicore32/target_structs.h | 40 +
linux-user/x86_64/target_structs.h | 40 +
19 files changed, 657 insertions(+), 48 deletions(-)
create mode 100644 linux-user/aarch64/target_structs.h
create mode 100644 linux-user/alpha/target_structs.h
create mode 100644 linux-user/arm/target_structs.h
create mode 100644 linux-user/cris/target_structs.h
create mode 100644 linux-user/i386/target_structs.h
create mode 100644 linux-user/m68k/target_structs.h
create mode 100644 linux-user/microblaze/target_structs.h
create mode 100644 linux-user/mips/target_structs.h
create mode 100644 linux-user/mips64/target_structs.h
create mode 100644 linux-user/openrisc/target_structs.h
create mode 100644 linux-user/ppc/target_structs.h
create mode 100644 linux-user/s390x/target_structs.h
create mode 100644 linux-user/sh4/target_structs.h
create mode 100644 linux-user/sparc/target_structs.h
create mode 100644 linux-user/sparc64/target_structs.h
create mode 100644 linux-user/unicore32/target_structs.h
create mode 100644 linux-user/x86_64/target_structs.h
diff --git a/linux-user/aarch64/target_structs.h
b/linux-user/aarch64/target_structs.h
new file mode 100644
index 000..30ed852
--- /dev/null
+++ b/linux-user/aarch64/target_structs.h
@@ -0,0 +1,40 @@
+#ifndef TARGET_STRUCTS_H
+#define TARGET_STRUCTS_H
+
+struct target_ipc_perm {
+abi_int __key; /* Key. */
+abi_uint uid; /* Owner's user ID. */
+abi_uint gid; /* Owner's group ID. */
+abi_uint cuid; /* Creator's user ID. */
+abi_uint cgid; /* Creator's group ID. */
+abi_ushort mode;/* Read/write permission. */
+abi_ushort __pad1;
+abi_ushort __seq; /* Sequence number. */
+abi_ushort __pad2;
+abi_ulong __unused1;
+abi_ulong __unused2;
+};
+
+struct target_shmid_ds {
+struct target_ipc_perm shm_perm;/* operation permission struct */
+abi_long shm_segsz; /* size of segment in bytes */
+abi_ulong shm_atime;/* time of last shmat() */
+#if TARGET_ABI_BITS == 32
+abi_ulong __unused1;
+#endif
+abi_ulong shm_dtime;/* time of last shmdt() */
+#if TARGET_ABI_BITS == 32
+abi_ulong __unused2;
+#endif
+abi_ulong shm_ctime;/* time of last change by shmctl() */
+#if TARGET_ABI_BITS == 32
+abi_ulong __unused3;
+#endif
+abi
[Qemu-devel] [V3 07/13] Add VSX Scalar Move Instructions
From 37b74a6ca422e62b349692188c457bf6127a3a83 Mon Sep 17 00:00:00 2001
From: Tom Musta
Date: Thu, 3 Oct 2013 10:09:50 -0500
Subject: [PATCH 07/13] Add VSX Scalar Move Instructions
To: qemu-...@nongnu.org
This patch adds the VSX scalar move instructions:
- xsabsdp (Scalar Absolute Value Double-Precision)
- xsnabspd (Scalar Negative Absolute Value Double-Precision)
- xsnegdp (Scalar Negate Double-Precision)
- xscpsgndp (Scalar Copy Sign Double-Precision)
A common generator macro (VSX_SCALAR_MOVE) is added since these
instructions vary only slightly from each other.
Macros to support VSX XX2 and XX3 form opcodes are also added.
These macros handle the overloading of "opcode 2" space (instruction
bits 26:30) caused by AX and BX bits (29 and 30, respectively).
V3: Per feedback from Paolo Bonzini, moved the sign mask into a
temporary and used andc.
Signed-off-by: Tom Musta
---
target-ppc/translate.c | 69
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 047e876..7409f77 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -7163,6 +7163,58 @@ static void gen_xxpermdi(DisasContext *ctx)
tcg_temp_free(xh);
tcg_temp_free(xl);
}
+#define OP_ABS 1
+#define OP_NABS 2
+#define OP_NEG 3
+#define OP_CPSGN 4
+#define SGN_MASK_DP 0x8000ul
+#define SGN_MASK_SP 0x80008000ul
+
+#define VSX_SCALAR_MOVE(name, op, sgn_mask) \
+static void glue(gen_, name)(DisasContext * ctx) \
+{ \
+TCGv_i64 xb, sgm; \
+if (unlikely(!ctx->vsx_enabled)) {\
+gen_exception(ctx, POWERPC_EXCP_VSXU);\
+return; \
+} \
+xb = tcg_temp_new(); \
+sgm = tcg_temp_new(); \
+tcg_gen_mov_i64(xb, cpu_vsrh(xB(ctx->opcode))); \
+tcg_gen_movi_i64(sgm, sgn_mask); \
+switch (op) { \
+case OP_ABS: {\
+tcg_gen_andc_i64(xb, xb, sgm);\
+break;\
+} \
+case OP_NABS: { \
+tcg_gen_or_i64(xb, xb, sgm); \
+break;\
+} \
+case OP_NEG: {\
+tcg_gen_xor_i64(xb, xb, sgm); \
+break;\
+} \
+case OP_CPSGN: { \
+TCGv_i64 xa = tcg_temp_new(); \
+tcg_gen_mov_i64(xa, cpu_vsrh(xA(ctx->opcode))); \
+tcg_gen_and_i64(xa, xa, sgm); \
+tcg_gen_andc_i64(xb, xb, sgm);\
+tcg_gen_or_i64(xb, xb, xa); \
+tcg_temp_free(xa);\
+break;\
+} \
+} \
+tcg_gen_mov_i64(cpu_vsrh(xT(ctx->opcode)), xb); \
+tcg_temp_free(xb);\
+tcg_temp_free(sgm); \
+}
+
+VSX_SCALAR_MOVE(xsabsdp, OP_ABS, SGN_MASK_DP)
+VSX_SCALAR_MOVE(xsnabsdp, OP_NABS, SGN_MASK_DP)
+VSX_SCALAR_MOVE(xsnegdp, OP_NEG, SGN_MASK_DP)
+VSX_SCALAR_MOVE(xscpsgndp, OP_CPSGN, SGN_MASK_DP)
+
/*** SPE extension ***/
/* Register moves */
@@ -9622,6 +9674,18 @@ GEN_HANDLER_E(stxsdx, 0x1F, 0xC, 0x16, 0, PPC_NONE,
PPC2_VSX),
GEN_HANDLER_E(stxvd2x, 0x1F, 0xC, 0x1E, 0, PPC_NONE, PPC2_VSX),
GEN_HANDLER_E(stxvw4x, 0x1F, 0xC, 0x1C, 0, PPC_NONE, PPC2_VSX),
+#undef GEN_XX2FORM
+#define GEN_XX2FORM(name, opc2, opc3, fl2) \
+GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 0, opc3, 0, PPC_NONE, fl2), \
+GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 1, opc3, 0, PPC_NONE, fl2)
+
+#undef GEN_XX3FORM
+#define GEN_XX3FORM(name, opc2, opc3, fl2) \
+GEN_HANDLER2_E(name, #name, 0x3C, opc2 | 0, opc3, 0, PPC_NON
[Qemu-devel] [V3 08/13] Add VSX Vector Move Instructions
This patch adds the vector move instructions:
- xvabsdp - Vector Absolute Value Double-Precision
- xvnabsdp - Vector Negative Absolute Value Double-Precision
- xvnegdp - Vector Negate Double-Precision
- xvcpsgndp - Vector Copy Sign Double-Precision
- xvabssp - Vector Absolute Value Single-Precision
- xvnabssp - Vector Negative Absolute Value Single-Precision
- xvnegsp - Vector Negate Single-Precision
- xvcpsgnsp - Vector Copy Sign Single-Precision
V3: Per Paolo Bonzini's suggestion, used a temporary for the
sign mask and andc.
Signed-off-by: Tom Musta
---
target-ppc/translate.c | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/target-ppc/translate.c b/target-ppc/translate.c
index 7409f77..e7d40a4 100644
--- a/target-ppc/translate.c
+++ b/target-ppc/translate.c
@@ -7215,6 +7215,69 @@ VSX_SCALAR_MOVE(xsnabsdp, OP_NABS, SGN_MASK_DP)
VSX_SCALAR_MOVE(xsnegdp, OP_NEG, SGN_MASK_DP)
VSX_SCALAR_MOVE(xscpsgndp, OP_CPSGN, SGN_MASK_DP)
+#define VSX_VECTOR_MOVE(name, op, sgn_mask) \
+static void glue(gen_, name)(DisasContext * ctx) \
+{\
+TCGv_i64 xbh, xbl, sgm; \
+if (unlikely(!ctx->vsx_enabled)) { \
+gen_exception(ctx, POWERPC_EXCP_VSXU); \
+return; \
+}\
+xbh = tcg_temp_new();\
+xbl = tcg_temp_new();\
+sgm = tcg_temp_new();\
+tcg_gen_mov_i64(xbh, cpu_vsrh(xB(ctx->opcode))); \
+tcg_gen_mov_i64(xbl, cpu_vsrl(xB(ctx->opcode))); \
+tcg_gen_movi_i64(sgm, sgn_mask); \
+switch (op) {\
+case OP_ABS: { \
+tcg_gen_andc_i64(xbh, xbh, sgm); \
+tcg_gen_andc_i64(xbl, xbl, sgm); \
+break; \
+}\
+case OP_NABS: { \
+tcg_gen_or_i64(xbh, xbh, sgm); \
+tcg_gen_or_i64(xbl, xbl, sgm); \
+break; \
+}\
+case OP_NEG: { \
+tcg_gen_xor_i64(xbh, xbh, sgm); \
+tcg_gen_xor_i64(xbl, xbl, sgm); \
+break; \
+}\
+case OP_CPSGN: { \
+TCGv_i64 xah = tcg_temp_new(); \
+TCGv_i64 xal = tcg_temp_new(); \
+tcg_gen_mov_i64(xah, cpu_vsrh(xA(ctx->opcode))); \
+tcg_gen_mov_i64(xal, cpu_vsrl(xA(ctx->opcode))); \
+tcg_gen_and_i64(xah, xah, sgm); \
+tcg_gen_and_i64(xal, xal, sgm); \
+tcg_gen_andc_i64(xbh, xbh, sgm); \
+tcg_gen_andc_i64(xbl, xbl, sgm); \
+tcg_gen_or_i64(xbh, xbh, xah); \
+tcg_gen_or_i64(xbl, xbl, xal); \
+tcg_temp_free(xah); \
+tcg_temp_free(xal); \
+break; \
+}\
+}\
+tcg_gen_mov_i64(cpu_vsrh(xT(ctx->opcode)), xbh); \
+tcg_gen_mov_i64(cpu_vsrl(xT(ctx->opcode)), xbl); \
+tcg_temp_free(xbh); \
+tcg_temp_free(xbl); \
+tcg_temp_free(sgm); \
+}
+
+VSX_VECTOR_MOVE(xvabsdp, OP_ABS, SGN_MASK_DP)
+VSX_VECTOR_MOVE(xvnabsdp, OP_NABS, SGN_MASK_DP)
+VSX_VECTOR_MOVE(xvnegdp, OP_NEG, SGN_MASK_DP)
+VSX_VECTOR_MOVE(xvcpsgndp, OP_CPSGN, SGN_MASK_DP)
+VSX_VECTOR_MOVE(xvabssp, OP_ABS, SGN_MASK_SP)
+VSX_VECTOR_MOVE(xvnabssp, OP_NABS, SGN_MASK_SP)
+VSX_VECTOR_MOVE(xvnegsp, OP_NEG, SGN_MASK_SP)
+VSX_VECTOR_MOVE(xvcpsgnsp, OP_CPSGN, SGN_MASK_SP)
+
+
/*** SPE extension ***/
/* Register m
Re: [Qemu-devel] [PATCH 2/7] Add MSR VSX and Associated Exception
On 10/22/2013 04:06 AM, Anton Blanchard wrote:
> From: Tom Musta
>
> This patch adds support for the VSX bit of the PowerPC Machine
> State Register (MSR) as well as the corresponding VSX Unavailable
> exception.
>
> The VSX bit is added to the defined bits masks of the Power7 and
> Power8 CPU models.
>
> Signed-off-by: Tom Musta
> Signed-off-by: Anton Blanchard
> ---
>
> Index: b/target-ppc/cpu.h
> ===
> --- a/target-ppc/cpu.h
> +++ b/target-ppc/cpu.h
> @@ -236,6 +236,8 @@ enum {
> POWERPC_EXCP_NMEXTBR = 91, /* Non maskable external breakpoint
> */
> POWERPC_EXCP_ITLBE= 92, /* Instruction TLB error
> */
> POWERPC_EXCP_DTLBE= 93, /* Data TLB error
> */
> +/* VSX Unavailable (Power ISA 2.06 and later)
> */
> +POWERPC_EXCP_VSXU = 94, /* VSX Unavailable
> */
> /* EOL
> */
> POWERPC_EXCP_NB = 96,
> /* QEMU exceptions: used internally during code translation
> */
> @@ -427,6 +429,7 @@ struct ppc_slb_t {
> #define MSR_VR 25 /* altivec availablex hflags
> */
> #define MSR_SPE 25 /* SPE enable for BookE x hflags
> */
> #define MSR_AP 23 /* Access privilege state on 602 hflags
> */
> +#define MSR_VSX 23 /* Vector Scalar Extension (ISA 2.06 and later) x hflags
> */
> #define MSR_SA 22 /* Supervisor access mode on 602 hflags
> */
> #define MSR_KEY 19 /* key bit on 603e
> */
> #define MSR_POW 18 /* Power management
> */
> @@ -467,6 +470,7 @@ struct ppc_slb_t {
> #define msr_vr ((env->msr >> MSR_VR) & 1)
> #define msr_spe ((env->msr >> MSR_SPE) & 1)
> #define msr_ap ((env->msr >> MSR_AP) & 1)
> +#define msr_vsx ((env->msr >> MSR_VSX) & 1)
> #define msr_sa ((env->msr >> MSR_SA) & 1)
> #define msr_key ((env->msr >> MSR_KEY) & 1)
> #define msr_pow ((env->msr >> MSR_POW) & 1)
> Index: b/target-ppc/excp_helper.c
> ===
> --- a/target-ppc/excp_helper.c
> +++ b/target-ppc/excp_helper.c
> @@ -390,6 +390,11 @@ static inline void powerpc_excp(PowerPCC
> new_msr |= (target_ulong)MSR_HVB;
> }
> goto store_current;
> +case POWERPC_EXCP_VSXU: /* VSX unavailable exception
> */
> +if (lpes1 == 0) {
> +new_msr |= (target_ulong)MSR_HVB;
> +}
> +goto store_current;
> case POWERPC_EXCP_PIT: /* Programmable interval timer interrupt
> */
> LOG_EXCP("PIT exception\n");
> goto store_next;
> Index: b/target-ppc/translate.c
> ===
> --- a/target-ppc/translate.c
> +++ b/target-ppc/translate.c
> @@ -199,6 +199,7 @@ typedef struct DisasContext {
> #endif
> int fpu_enabled;
> int altivec_enabled;
> +int vsx_enabled;
> int spe_enabled;
> ppc_spr_t *spr_cb; /* Needed to check rights for mfspr/mtspr */
> int singlestep_enabled;
> @@ -9763,6 +9764,11 @@ static inline void gen_intermediate_code
> ctx.altivec_enabled = msr_vr;
> else
> ctx.altivec_enabled = 0;
> +if ((env->flags & POWERPC_FLAG_VSX) && msr_vsx) {
> +ctx.vsx_enabled = msr_vsx;
> +} else {
> +ctx.vsx_enabled = 0;
> +}
In order to get correct code generation when the msr changes,
one has to adjust the TB flags. Which for target-ppc means
adjusting env->hflags.
See hreg_compute_hflags.
Ideally, target-ppc would initialize these ctx bits from tb->flags
instead of env->msr to make this obvious. But so long as the two
are in sync it's not technically a bug.
r~
Re: [Qemu-devel] [PATCH_v2 9/9] target-openrisc: Correct carry flagcheck of l.addc and l.addic test casess
Hi Alex, I am using a cross-compiling toolchain. It's the easiest way as I have to compile the image for QEMU anyhow. http://opencores.org/or1k/OpenRISC_GNU_tool_chain Then it's just an "make && make test" in the corresponding tests/tcg/openrisc folder. Inside the virtual machine it would be a little bit more complicated. You have to compile Linux with the initramfs containing the QEMU test sources. Another storage device is currently not supported by the OpenRISC QEMU emulator. Sebastian On 22/10/2013 1:35 AM, Alex Bennée wrote: sebast...@macke.de writes: The test cases did not correctly test for the carry flag. Out of interest how are you building your test cases, cross-compiling or from within the emulated environment? I want to clean-up and resurrect the TCG tests but one of the challenges is all the non-x86 targets need to be built somehow. Cheers,
Re: [Qemu-devel] [PATCH_v2 9/9] target-openrisc: Correct carry flagcheck of l.addc and l.addic test casess
On Tue, Oct 22, 2013 at 7:45 PM, Sebastian Macke wrote: > Hi Alex, > > I am using a cross-compiling toolchain. It's the easiest way as I have to > compile the image for QEMU anyhow. > http://opencores.org/or1k/OpenRISC_GNU_tool_chain > > Then it's just an "make && make test" in the corresponding > tests/tcg/openrisc folder. > > Inside the virtual machine it would be a little bit more complicated. You > have to compile Linux with the initramfs containing the QEMU test sources. > Another storage device is currently not supported by the OpenRISC QEMU > emulator. It should be possible to use network, I did a quick check at the time of openrisc port submission, it used to work. -- Thanks. -- Max
Re: [Qemu-devel] [PATCH_v2 9/9] target-openrisc: Correct carry flagcheck of l.addc and l.addic test casess
jcmvb...@gmail.com writes: > On Tue, Oct 22, 2013 at 7:45 PM, Sebastian Macke wrote: >> Hi Alex, >> >> I am using a cross-compiling toolchain. It's the easiest way as I have to >> compile the image for QEMU anyhow. >> http://opencores.org/or1k/OpenRISC_GNU_tool_chain I shall have a look. > > It should be possible to use network, I did a quick check at the time of > openrisc port submission, it used to work. Nah cross-compiling makes more sense. I was thinking of making configure detect the various cross compilers at configure time and then optionally enable each set of tcg tests depending on Cross Compile support. -- Alex Bennée
Re: [Qemu-devel] [PATCH_v2 9/9] target-openrisc: Correct carry flagcheck of l.addc and l.addic test casess
On 22/10/2013 9:01 AM, Max Filippov wrote: On Tue, Oct 22, 2013 at 7:45 PM, Sebastian Macke wrote: Hi Alex, I am using a cross-compiling toolchain. It's the easiest way as I have to compile the image for QEMU anyhow. http://opencores.org/or1k/OpenRISC_GNU_tool_chain Then it's just an "make && make test" in the corresponding tests/tcg/openrisc folder. Inside the virtual machine it would be a little bit more complicated. You have to compile Linux with the initramfs containing the QEMU test sources. Another storage device is currently not supported by the OpenRISC QEMU emulator. It should be possible to use network, I did a quick check at the time of openrisc port submission, it used to work. This is true. Via a network file system it should be no problem. But this is a very complicated way to test the QEMU tcg part. The image containing gcc I am currently using you can download under www.simulationcorner.net/vmlinux Run it with "qemu-system-or32 -m 128 -kernel vmlinux -nographic"
[Qemu-devel] [PATCH 2/4 v5] block: Add device-width property to pflash_cfi01
The width of the devices that make up the flash interface
is required to mask certain commands, in particular the
write length for buffered writes. This length will be presented
to each device on the interface by the program writing the flash,
and the flash emulation code needs to be able to determine
the length of the write as recieved by each flash device.
The device-width defaults to the bank width which should
maintain existing behavior for platforms that don't need
this change.
This change is required to support buffered writes on the
vexpress platform that has a 32 bit flash interface with 2
16 bit devices on it.
Signed-off-by: Roy Franz
---
hw/block/pflash_cfi01.c |5 +
1 file changed, 5 insertions(+)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index d5e366d..cda8289 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -72,6 +72,7 @@ struct pflash_t {
uint32_t nb_blocs;
uint64_t sector_len;
uint8_t bank_width;
+uint8_t device_width;
uint8_t be;
uint8_t wcycle; /* if 0, the flash is read normally */
int ro;
@@ -378,6 +379,8 @@ static void pflash_write(pflash_t *pfl, hwaddr offset,
break;
case 0xe8:
+/* Mask writeblock size based on device width */
+value &= (1ULL << (pfl->device_width * 8)) - 1;
DPRINTF("%s: block write of %x bytes\n", __func__, value);
pfl->counter = value;
pfl->wcycle++;
@@ -707,6 +710,7 @@ static Property pflash_cfi01_properties[] = {
DEFINE_PROP_UINT32("num-blocks", struct pflash_t, nb_blocs, 0),
DEFINE_PROP_UINT64("sector-length", struct pflash_t, sector_len, 0),
DEFINE_PROP_UINT8("width", struct pflash_t, bank_width, 0),
+DEFINE_PROP_UINT8("device-width", struct pflash_t, device_width, 0),
DEFINE_PROP_UINT8("big-endian", struct pflash_t, be, 0),
DEFINE_PROP_UINT16("id0", struct pflash_t, ident0, 0),
DEFINE_PROP_UINT16("id1", struct pflash_t, ident1, 0),
@@ -757,6 +761,7 @@ pflash_t *pflash_cfi01_register(hwaddr base,
qdev_prop_set_uint32(dev, "num-blocks", nb_blocs);
qdev_prop_set_uint64(dev, "sector-length", sector_len);
qdev_prop_set_uint8(dev, "width", bank_width);
+qdev_prop_set_uint8(dev, "device-width", bank_width);
qdev_prop_set_uint8(dev, "big-endian", !!be);
qdev_prop_set_uint16(dev, "id0", id0);
qdev_prop_set_uint16(dev, "id1", id1);
--
1.7.10.4
[Qemu-devel] [PATCH 1/4 v4] block: rename pflash_t member width to bank_width
Rename the 'width' member of the pflash_t structuer
in preparation for adding a bank_width member.
Signed-off-by: Roy Franz
---
hw/block/pflash_cfi01.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 018a967..d5e366d 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -71,7 +71,7 @@ struct pflash_t {
BlockDriverState *bs;
uint32_t nb_blocs;
uint64_t sector_len;
-uint8_t width;
+uint8_t bank_width;
uint8_t be;
uint8_t wcycle; /* if 0, the flash is read normally */
int ro;
@@ -126,9 +126,9 @@ static uint32_t pflash_read (pflash_t *pfl, hwaddr offset,
ret = -1;
boff = offset & 0xFF; /* why this here ?? */
-if (pfl->width == 2)
+if (pfl->bank_width == 2)
boff = boff >> 1;
-else if (pfl->width == 4)
+else if (pfl->bank_width == 4)
boff = boff >> 2;
#if 0
@@ -665,7 +665,7 @@ static void pflash_cfi01_realize(DeviceState *dev, Error
**errp)
pfl->cfi_table[0x28] = 0x02;
pfl->cfi_table[0x29] = 0x00;
/* Max number of bytes in multi-bytes write */
-if (pfl->width == 1) {
+if (pfl->bank_width == 1) {
pfl->cfi_table[0x2A] = 0x08;
} else {
pfl->cfi_table[0x2A] = 0x0B;
@@ -706,7 +706,7 @@ static Property pflash_cfi01_properties[] = {
DEFINE_PROP_DRIVE("drive", struct pflash_t, bs),
DEFINE_PROP_UINT32("num-blocks", struct pflash_t, nb_blocs, 0),
DEFINE_PROP_UINT64("sector-length", struct pflash_t, sector_len, 0),
-DEFINE_PROP_UINT8("width", struct pflash_t, width, 0),
+DEFINE_PROP_UINT8("width", struct pflash_t, bank_width, 0),
DEFINE_PROP_UINT8("big-endian", struct pflash_t, be, 0),
DEFINE_PROP_UINT16("id0", struct pflash_t, ident0, 0),
DEFINE_PROP_UINT16("id1", struct pflash_t, ident1, 0),
@@ -745,8 +745,8 @@ pflash_t *pflash_cfi01_register(hwaddr base,
DeviceState *qdev, const char *name,
hwaddr size,
BlockDriverState *bs,
-uint32_t sector_len, int nb_blocs, int width,
-uint16_t id0, uint16_t id1,
+uint32_t sector_len, int nb_blocs,
+int bank_width, uint16_t id0, uint16_t id1,
uint16_t id2, uint16_t id3, int be)
{
DeviceState *dev = qdev_create(NULL, TYPE_CFI_PFLASH01);
@@ -756,7 +756,7 @@ pflash_t *pflash_cfi01_register(hwaddr base,
}
qdev_prop_set_uint32(dev, "num-blocks", nb_blocs);
qdev_prop_set_uint64(dev, "sector-length", sector_len);
-qdev_prop_set_uint8(dev, "width", width);
+qdev_prop_set_uint8(dev, "width", bank_width);
qdev_prop_set_uint8(dev, "big-endian", !!be);
qdev_prop_set_uint16(dev, "id0", id0);
qdev_prop_set_uint16(dev, "id1", id1);
--
1.7.10.4
[Qemu-devel] [PATCH 0/4 v4] block, arm: Fix buffered flash writes on VExpress
This patchset fixes buffered flash writes on the VExpress platform. Buffered writes should now work properly on platforms whose flash interface width is different from the device width. The default is for the device-width to be set to the interface width, so platforms that can benefit from this change will need to be updated. This patchset updates the configuration for the VExpress platform which requires it. UEFI firmware uses buffered writes for persistent variable storage, and this patchset enables this usage on QEMU. Changes from v3: * Broke out width->bank_width name change into separate patch. * Added patch that returns status for each device in bank. * Reviewed code for other uses of device_width. The one remaining place this should be used is in the handling of returning the device ID. The existing code looks a bit suspect, as it is combining 16 bit values by shifting 8 bits and oring them. I have no good way to test various flash configurations, so I am reluctant to make major changes to that code. Changes from v2: (All changes in patch 2/2, 1/1 unchanged.) * Set flash invariant properties directly in VExpress specific flash init routine rather than passing long argument list. * Fix typo in comment. Changes from v1: * Add device-width property and use this to mask write length instead of devices mas write length * Update vexpress init code to set device-width to proper value. Roy Franz (4): rename pflash_t member width to bank_width Add device-width property to pflash_cfi01 return status for each device Set proper device-width for vexpress flash hw/arm/vexpress.c | 43 +-- hw/block/pflash_cfi01.c | 37 +++-- 2 files changed, 60 insertions(+), 20 deletions(-) -- 1.7.10.4
[Qemu-devel] [PATCH 3/4 v4] block: return status for each device
Now that we know how wide each flash device that makes up the bank is,
return status for each device in the bank. Leave existing code
that treats 32 bit wide banks as composed of two 16 bit devices as otherwise
we may break configurations that do not set the device_width propery.
Signed-off-by: Roy Franz
---
hw/block/pflash_cfi01.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index cda8289..aa2cbbc 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -191,9 +191,21 @@ static uint32_t pflash_read (pflash_t *pfl, hwaddr offset,
case 0x60: /* Block /un)lock */
case 0x70: /* Status Register */
case 0xe8: /* Write block */
-/* Status register read */
+/* Status register read. Return status from each device in
+ * bank.
+ */
ret = pfl->status;
-if (width > 2) {
+if (width > pfl->device_width) {
+int shift = pfl->device_width * 8;
+while (shift + pfl->device_width * 8 <= width * 8) {
+ret |= pfl->status << (shift);
+shift += pfl->device_width * 8;
+}
+} else if (width > 2) {
+/* Handle 32 bit flash cases where device width may be
+ * improperly set. (Existing behavior before device width
+ * added.)
+ */
ret |= pfl->status << 16;
}
DPRINTF("%s: status %x\n", __func__, ret);
--
1.7.10.4
[Qemu-devel] [PATCH 4/4 v4] block: Set proper device-width for vexpress flash
Create vexpress specific pflash registration
function which properly configures the device-width
of 16 bits (2 bytes) for the NOR flash on the
vexpress platform. This change is required for
buffered flash writes to work properly.
Signed-off-by: Roy Franz
---
hw/arm/vexpress.c | 43 +--
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/hw/arm/vexpress.c b/hw/arm/vexpress.c
index f48de00..8eae73c 100644
--- a/hw/arm/vexpress.c
+++ b/hw/arm/vexpress.c
@@ -480,6 +480,35 @@ static void vexpress_modify_dtb(const struct arm_boot_info
*info, void *fdt)
}
}
+
+/* Open code a private version of pflash registration since we
+ * need to set non-default device width for VExpress platform.
+ */
+static pflash_t *ve_pflash_cfi01_register(hwaddr base, const char *name,
+ BlockDriverState *bs)
+{
+DeviceState *dev = qdev_create(NULL, "cfi.pflash01");
+
+if (bs && qdev_prop_set_drive(dev, "drive", bs)) {
+abort();
+}
+
+qdev_prop_set_uint32(dev, "num-blocks", VEXPRESS_FLASH_SIZE /
VEXPRESS_FLASH_SECT_SIZE);
+qdev_prop_set_uint64(dev, "sector-length", VEXPRESS_FLASH_SECT_SIZE);
+qdev_prop_set_uint8(dev, "width", 4);
+qdev_prop_set_uint8(dev, "device-width", 2);
+qdev_prop_set_uint8(dev, "big-endian", 0);
+qdev_prop_set_uint16(dev, "id0", 0x00);
+qdev_prop_set_uint16(dev, "id1", 0x89);
+qdev_prop_set_uint16(dev, "id2", 0x00);
+qdev_prop_set_uint16(dev, "id3", 0x18);
+qdev_prop_set_string(dev, "name", name);
+qdev_init_nofail(dev);
+
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+return OBJECT_CHECK(pflash_t, (dev), "cfi.pflash01");
+}
+
static void vexpress_common_init(VEDBoardInfo *daughterboard,
QEMUMachineInitArgs *args)
{
@@ -561,11 +590,8 @@ static void vexpress_common_init(VEDBoardInfo
*daughterboard,
sysbus_create_simple("pl111", map[VE_CLCD], pic[14]);
dinfo = drive_get_next(IF_PFLASH);
-pflash0 = pflash_cfi01_register(map[VE_NORFLASH0], NULL, "vexpress.flash0",
-VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
-VEXPRESS_FLASH_SECT_SIZE,
-VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE, 4,
-0x00, 0x89, 0x00, 0x18, 0);
+pflash0 = ve_pflash_cfi01_register(map[VE_NORFLASH0], "vexpress.flash0",
+ dinfo ? dinfo->bdrv : NULL);
if (!pflash0) {
fprintf(stderr, "vexpress: error registering flash 0.\n");
exit(1);
@@ -580,11 +606,8 @@ static void vexpress_common_init(VEDBoardInfo
*daughterboard,
}
dinfo = drive_get_next(IF_PFLASH);
-if (!pflash_cfi01_register(map[VE_NORFLASH1], NULL, "vexpress.flash1",
-VEXPRESS_FLASH_SIZE, dinfo ? dinfo->bdrv : NULL,
-VEXPRESS_FLASH_SECT_SIZE,
-VEXPRESS_FLASH_SIZE / VEXPRESS_FLASH_SECT_SIZE, 4,
-0x00, 0x89, 0x00, 0x18, 0)) {
+if (!ve_pflash_cfi01_register(map[VE_NORFLASH1], "vexpress.flash1",
+ dinfo ? dinfo->bdrv : NULL)) {
fprintf(stderr, "vexpress: error registering flash 1.\n");
exit(1);
}
--
1.7.10.4
[Qemu-devel] [PATCH] rdma: rename 'x-rdma' => 'rdma'
From: "Michael R. Hines"
As far as we can tell, all known bugs have been fixed,
there as been very good participation in testing and running.
1. Parallel RDMA migrations are working
2. IPv6 migration is working
3. Libvirt patches are ready
4. virt-test is working
Any objections to removing the experimental tag?
There is one remaining bug: qemu-system-i386 does not compile
with RDMA: I have very zero access to 32-bit hardware
using RDMA, so this hasn't been much of a priority. It seems
safer to *not* submit non-testable patch rather than submit
submit a fix just for the sake of compiling =)
Signed-off-by: Michael R. Hines
---
docs/rdma.txt| 12 ++--
migration-rdma.c |2 +-
migration.c |6 +++---
qapi-schema.json |4 ++--
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/docs/rdma.txt b/docs/rdma.txt
index 8d1e003..2c2beba 100644
--- a/docs/rdma.txt
+++ b/docs/rdma.txt
@@ -66,7 +66,7 @@ bulk-phase round of the migration and can be enabled for
extremely
high-performance RDMA hardware using the following command:
QEMU Monitor Command:
-$ migrate_set_capability x-rdma-pin-all on # disabled by default
+$ migrate_set_capability rdma-pin-all on # disabled by default
Performing this action will cause all 8GB to be pinned, so if that's
not what you want, then please ignore this step altogether.
@@ -93,12 +93,12 @@ $ migrate_set_speed 40g # or whatever is the MAX of your
RDMA device
Next, on the destination machine, add the following to the QEMU command line:
-qemu . -incoming x-rdma:host:port
+qemu . -incoming rdma:host:port
Finally, perform the actual migration on the source machine:
QEMU Monitor Command:
-$ migrate -d x-rdma:host:port
+$ migrate -d rdma:host:port
PERFORMANCE
===
@@ -120,8 +120,8 @@ For example, in the same 8GB RAM example with all 8GB of
memory in
active use and the VM itself is completely idle using the same 40 gbps
infiniband link:
-1. x-rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
-2. x-rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
+1. rdma-pin-all disabled total time: approximately 7.5 seconds @ 9.5 Gbps
+2. rdma-pin-all enabled total time: approximately 4 seconds @ 26 Gbps
These numbers would of course scale up to whatever size virtual machine
you have to migrate using RDMA.
@@ -407,7 +407,7 @@ socket is broken during a non-RDMA based migration.
TODO:
=
-1. 'migrate x-rdma:host:port' and '-incoming x-rdma' options will be
+1. 'migrate rdma:host:port' and '-incoming rdma' options will be
renamed to 'rdma' after the experimental phase of this work has
completed upstream.
2. Currently, 'ulimit -l' mlock() limits as well as cgroups swap limits
diff --git a/migration-rdma.c b/migration-rdma.c
index f94f3b4..eeb4302 100644
--- a/migration-rdma.c
+++ b/migration-rdma.c
@@ -3412,7 +3412,7 @@ void rdma_start_outgoing_migration(void *opaque,
}
ret = qemu_rdma_source_init(rdma, &local_err,
-s->enabled_capabilities[MIGRATION_CAPABILITY_X_RDMA_PIN_ALL]);
+s->enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL]);
if (ret) {
goto err;
diff --git a/migration.c b/migration.c
index b4f8462..d9c7a62 100644
--- a/migration.c
+++ b/migration.c
@@ -81,7 +81,7 @@ void qemu_start_incoming_migration(const char *uri, Error
**errp)
if (strstart(uri, "tcp:", &p))
tcp_start_incoming_migration(p, errp);
#ifdef CONFIG_RDMA
-else if (strstart(uri, "x-rdma:", &p))
+else if (strstart(uri, "rdma:", &p))
rdma_start_incoming_migration(p, errp);
#endif
#if !defined(WIN32)
@@ -423,7 +423,7 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
if (strstart(uri, "tcp:", &p)) {
tcp_start_outgoing_migration(s, p, &local_err);
#ifdef CONFIG_RDMA
-} else if (strstart(uri, "x-rdma:", &p)) {
+} else if (strstart(uri, "rdma:", &p)) {
rdma_start_outgoing_migration(s, p, &local_err);
#endif
#if !defined(WIN32)
@@ -501,7 +501,7 @@ bool migrate_rdma_pin_all(void)
s = migrate_get_current();
-return s->enabled_capabilities[MIGRATION_CAPABILITY_X_RDMA_PIN_ALL];
+return s->enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL];
}
bool migrate_auto_converge(void)
diff --git a/qapi-schema.json b/qapi-schema.json
index 145eca8..4bae4b1 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -615,7 +615,7 @@
# This feature allows us to minimize migration traffic for certain
work
# loads, by sending compressed difference of the pages
#
-# @x-rdma-pin-all: Controls whether or not the entire VM memory footprint is
+# @rdma-pin-all: Controls whether or not the entire VM memory footprint is
# mlock()'d on demand or all at once. Refer to docs/rdma.txt for
usage.
# Disabled by default. Experimental: may (or may not) be renamed after
# further testing is complete. (since 1.6)
@@ -632,7 +632,7 @@
#
[Qemu-devel] [Bug 1242963] Re: QEMU loadvm causes guest OS freeze
** Changed in: qemu Status: Incomplete => New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1242963 Title: QEMU loadvm causes guest OS freeze Status in QEMU: New Bug description: HOST: ubuntu 13.10 x64 GUEST: winxp sp 3 x86 AFFECT QEMU(tested): v1.5.2, v1.5.3, v1.6.0, v1.6.1 I compile QEMU by myself with "./configure --target-list=i386-softmmu && make && make install". After installing a winxp sp3 into the qemu-system-i386 with command line: > qemu-system-i386 -m 512 -hda xp.img -net user -net nic,model=rtl8139 -rtc base=localtime,clock=vm I use monitor to create a live snapshot: > stop > savevm xxx > cont And then I load this snapshot (I also try it in commad line: -loadvm xxx): > loadvm xxx > cont After that, the windows system is freeze (don't accept any keyboard or mouse input, although I knew vcpu is still working). If I compile with -enable-kvm and launch qemu-system-i386 with -enable-kvm, it looks like everything works well. I think it is a bug for qemu system. BTW: freeze is not appearing 100%, but in my test, 95% cases would cause system freeze. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1242963/+subscriptions
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
On Tue, Oct 22, 2013 at 09:24:46AM +0100, Peter Maydell wrote: > On 21 October 2013 21:03, Peter Maydell wrote: > > Ken: I think this should work (and it doesn't break building with > > old makes), but I don't have a make 4.0 to hand; if you could > > test it I'd appreciate it. > > Forwarding a message from Ken (whose mail client is apparently > not very good :-): > No, it was operator error - I somehow fell into editing the original mail (didn't even know that was an option for received mails) and trashed the header. Anyway. > Ken wrote: > # I applied it to 1.6.1 - some fuzz and large offsets, but it > # completed the default build (i.e. just ./configure so all targets) > # and also a DESTDIR install. > > Ken -- any chance you could test git master? I think it would > be more interesting to make sure that 1.7 works with Make 4.0: > I don't know if anybody will care enough to backport this patch > to 1.6.x. > > thanks > -- PMM Not sure how to. I cloned git://git.qemu.org/qemu.git which was at commit fc8ead74674b7129e8f31c2595c76658e5622197 Merge: 3551643 7174e54 Author: Anthony Liguori Date: Fri Oct 18 10:03:24 2013 -0700 Merge remote-tracking branch 'qemu-kvm/uq/master' into staging Copied the non-dotfiles (cp -av *), applied the patch, got a message from configure: ERROR: DTC not present. Your options: (1) Preferred: Install the DTC devel package (2) Fetch the DTC submodule, using: git submodule update --init dtc So I went back to git, did the submodule update and copied afresh, applied the patch, and still got the same error. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce
[Qemu-devel] QueuePFN peculiarity in virtio-mmio
Hi, "Appendix X: virtio-mmio" in the virtio spec says • 0x040 | RW | QueuePFN [...] When the Guest stops using the queue it must write zero (0x0) to this register. [...] and Virtqueue Configuration [...] 2. Check if the queue is not already in use: read QueuePFN register, returned value should be zero (0x0). [...] I think this in itself is already suboptimal, because a guest that crashes and reboots (while the emulator itself survives) will not be able to use the device after said reboot (it has never re-set QueuePFN to zero). But, more importantly: I think that resetting the device (by writing 0 to its status register) should include (ie. *guarantee*) the effects of setting QueuePFN to zero for all imaginable queues of the device. This way, a defensive guest that starts up by resetting the device (*) after identifying it via MagicValue / Version / DeviceID / VendorID would be able to use the device regardless of the device's prior QueuePFN setting(s). (*) Resetting the device is the first step in "2.2.1 Device Initialization Sequence". It "is not required on initial start up", but as a guest driver can never be sure whether the startup in question is the initial one, a defensive driver will always start with device reet. The question arises because Olivier has posted a series to edk2-devel that adds virtio-mmio support to TianoCore, and Mark tested it (using OVMF) with a Linux guest and found problems. Namely, OVMF itself can drive the virtio devices via virtio-mmio, but the Linux kernel booted from OVMF can not. The reason is the missing zeroing of QueuePFN when OVMF is exiting. (I'm just paraphrasing the analysis.) I think - that resetting the device (via its status register) should make the host forget *all* prior configuration, including QueuePFN, - and that the Linux driver should reset the device as first step. So: - What's the motivation for the "acquire/release" semantics of QueuePFN? - Am I right that device reset should force a QueuePFN release too? Thanks, Laszlo
Re: [Qemu-devel] QueuePFN peculiarity in virtio-mmio
My apologies, I used Anthony's previous (now obsolete) email. Updated it now & keeping full context below. Sorry. On 10/22/13 19:49, Laszlo Ersek wrote: > Hi, > > "Appendix X: virtio-mmio" in the virtio spec says > > • 0x040 | RW | QueuePFN > [...] When the Guest stops using the queue it must write zero > (0x0) to this register. > [...] > > and > > Virtqueue Configuration > > [...] > 2. Check if the queue is not already in use: read QueuePFN > register, returned value should be zero (0x0). > [...] > > I think this in itself is already suboptimal, because a guest that > crashes and reboots (while the emulator itself survives) will not be > able to use the device after said reboot (it has never re-set QueuePFN > to zero). > > But, more importantly: I think that resetting the device (by writing 0 > to its status register) should include (ie. *guarantee*) the effects of > setting QueuePFN to zero for all imaginable queues of the device. > > This way, a defensive guest that starts up by resetting the device (*) > after identifying it via MagicValue / Version / DeviceID / VendorID > would be able to use the device regardless of the device's prior > QueuePFN setting(s). > > (*) Resetting the device is the first step in "2.2.1 Device > Initialization Sequence". It "is not required on initial start up", but > as a guest driver can never be sure whether the startup in question is > the initial one, a defensive driver will always start with device reet. > > > The question arises because Olivier has posted a series to edk2-devel > that adds virtio-mmio support to TianoCore, and Mark tested it (using > OVMF) with a Linux guest and found problems. Namely, OVMF itself can > drive the virtio devices via virtio-mmio, but the Linux kernel booted > from OVMF can not. The reason is the missing zeroing of QueuePFN when > OVMF is exiting. (I'm just paraphrasing the analysis.) > > I think > - that resetting the device (via its status register) should make the > host forget *all* prior configuration, including QueuePFN, > - and that the Linux driver should reset the device as first step. > > So: > - What's the motivation for the "acquire/release" semantics of QueuePFN? > - Am I right that device reset should force a QueuePFN release too? > > Thanks, > Laszlo >
Re: [Qemu-devel] [edk2] QueuePFN peculiarity in virtio-mmio
On 10/22/13 19:55, Laszlo Ersek wrote: >> The question arises because Olivier has posted a series to edk2-devel >> that adds virtio-mmio support to TianoCore, and Mark tested it (using >> OVMF) with a Linux guest and found problems. Namely, OVMF itself can >> drive the virtio devices via virtio-mmio, but the Linux kernel booted >> from OVMF can not. The reason is the missing zeroing of QueuePFN when >> OVMF is exiting. (I'm just paraphrasing the analysis.) s/OVMF/AArch64 foundation model/g http://thread.gmane.org/gmane.comp.bios.tianocore.devel/4373/focus=4411 I should have followed my own advice, not to post when sick. I'll go now and hide in a cave. Laszlo /facepalm
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
On Tue, Oct 22, 2013 at 06:35:47PM +0100, Ken Moffat wrote: > > > > Ken -- any chance you could test git master? I think it would > > be more interesting to make sure that 1.7 works with Make 4.0: > > I don't know if anybody will care enough to backport this patch > > to 1.6.x. > > > > thanks > > -- PMM > > Not sure how to. Scratch that, user error. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
On 22 October 2013 18:35, Ken Moffat wrote: > On Tue, Oct 22, 2013 at 09:24:46AM +0100, Peter Maydell wrote: >> Forwarding a message from Ken (whose mail client is apparently >> not very good :-): >> > No, it was operator error - I somehow fell into editing the > original mail (didn't even know that was an option for received > mails) and trashed the header. Anyway. ...you also managed to send to the Envelope-from, not the From. > Not sure how to. I cloned git://git.qemu.org/qemu.git which was at > commit fc8ead74674b7129e8f31c2595c76658e5622197 > Merge: 3551643 7174e54 > Author: Anthony Liguori > Date: Fri Oct 18 10:03:24 2013 -0700 > > Merge remote-tracking branch 'qemu-kvm/uq/master' into staging > > Copied the non-dotfiles (cp -av *), applied the patch, got a > message from configure: > > ERROR: DTC not present. Your options: > (1) Preferred: Install the DTC devel package > (2) Fetch the DTC submodule, using: > git submodule update --init dtc > > So I went back to git, did the submodule update and copied afresh, > applied the patch, and still got the same error. I'm not sure what you're trying to achieve with the copy, but it seems likely to cause problems. Just do a build from the git tree. If you don't want to put object files in your git tree, this is what out-of-tree build is for: cd into the directory you want to put the object files in, and run the configure script from there: mkdir ../build cd ../build ../qemu.git/configure [usual configure options etc] thanks -- PMM
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
On Tue, Oct 22, 2013 at 07:10:43PM +0100, Peter Maydell wrote: > On 22 October 2013 18:35, Ken Moffat wrote: > > On Tue, Oct 22, 2013 at 09:24:46AM +0100, Peter Maydell wrote: > >> Forwarding a message from Ken (whose mail client is apparently > >> not very good :-): > >> > > No, it was operator error - I somehow fell into editing the > > original mail (didn't even know that was an option for received > > mails) and trashed the header. Anyway. > > ...you also managed to send to the Envelope-from, not the From. > > > Not sure how to. I cloned git://git.qemu.org/qemu.git which was at > > commit fc8ead74674b7129e8f31c2595c76658e5622197 > > Merge: 3551643 7174e54 > > Author: Anthony Liguori > > Date: Fri Oct 18 10:03:24 2013 -0700 > > > > Merge remote-tracking branch 'qemu-kvm/uq/master' into staging > > > > Copied the non-dotfiles (cp -av *), applied the patch, got a > > message from configure: > > > > ERROR: DTC not present. Your options: > > (1) Preferred: Install the DTC devel package > > (2) Fetch the DTC submodule, using: > > git submodule update --init dtc > > > > So I went back to git, did the submodule update and copied afresh, > > applied the patch, and still got the same error. > > I'm not sure what you're trying to achieve with the copy, but > it seems likely to cause problems. Just do a build from the > git tree. If you don't want to put object files in your git tree, > this is what out-of-tree build is for: cd into the directory you > want to put the object files in, and run the configure script > from there: > mkdir ../build > cd ../build > ../qemu.git/configure [usual configure options etc] > > thanks > -- PMM Thanks for that info. ĸen -- das eine Mal als Tragödie, dieses Mal als Farce
Re: [Qemu-devel] [PATCH for-1.7] configure: Explicitly set ARFLAGS so we can build with GNU Make 4.0
On Tue, Oct 22, 2013 at 07:09:10PM +0100, Ken Moffat wrote: > On Tue, Oct 22, 2013 at 06:35:47PM +0100, Ken Moffat wrote: > > > > > > Ken -- any chance you could test git master? I think it would > > > be more interesting to make sure that 1.7 works with Make 4.0: > > > I don't know if anybody will care enough to backport this patch > > > to 1.6.x. > > > > > > thanks > > > -- PMM > > > > Not sure how to. > Scratch that, user error. > Built and DESTDIR installed with the default targets using make-4.0 ĸen -- das eine Mal als Tragödie, dieses Mal als Farce
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
I see. So it would be something like this?
commit 1807466d691f281f430fbf8c0bbff6bf8073247d
Author: Samuel Thibault
Date: Tue Oct 22 21:11:46 2013 +0200
qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
This patchs adds parameters to manage some new options in the qemu -net
command.
Slirp IPv6 address, network prefix, and DNS IPv6 address can be given in
argument to the qemu command.
Defaults parameters are respectively fc00::2, fc00::, /64 and fc00::3.
Signed-off-by: Yann Bordenave
Signed-off-by: Samuel Thibault
diff --git a/net/net.c b/net/net.c
index c330c9a..0833aba 100644
--- a/net/net.c
+++ b/net/net.c
@@ -809,6 +809,36 @@ int net_client_init(QemuOpts *opts, int is_netdev, Error
**errp)
int ret = -1;
{
+/* Parse convenience option format ip6-net=fc00::0[/64] */
+const char *ip6_net = qemu_opt_get(opts, "ip6-net");
+
+if (ip6_net) {
+char buf[strlen(ip6_net)+1];
+
+if (get_str_sep(buf, sizeof(buf), &ip6_net, '/') < 0) {
+/* Default 64bit prefix length. */
+qemu_opt_set(opts, "ip6-prefix", ip6_net);
+qemu_opt_set_number(opts, "ip6-prefixlen", 64);
+} else {
+/* User-specified prefix length. */
+int len;
+char *end;
+
+qemu_opt_set(opts, "ip6-prefix", buf);
+len = strtol(ip6_net, &end, 10);
+
+if (*end != '\0') {
+error_set(errp, QERR_INVALID_PARAMETER_VALUE,
+ "ip6-prefix", "a number");
+} else {
+qemu_opt_set_number(opts, "ip6-prefixlen", len);
+}
+}
+qemu_opt_unset(opts, "ip6-net");
+}
+}
+
+{
OptsVisitor *ov = opts_visitor_new(opts);
net_visit(opts_get_visitor(ov), is_netdev, &object, &err);
diff --git a/net/slirp.c b/net/slirp.c
index 124e953..01f81e0 100644
--- a/net/slirp.c
+++ b/net/slirp.c
@@ -134,17 +134,23 @@ static NetClientInfo net_slirp_info = {
static int net_slirp_init(NetClientState *peer, const char *model,
const char *name, int restricted,
const char *vnetwork, const char *vhost,
+ const char *vprefix6, int vprefix6_len,
+ const char *vhost6,
const char *vhostname, const char *tftp_export,
const char *bootfile, const char *vdhcp_start,
- const char *vnameserver, const char *smb_export,
- const char *vsmbserver, const char **dnssearch)
+ const char *vnameserver, const char *vnameserver6,
+ const char *smb_export, const char *vsmbserver,
+ const char **dnssearch)
{
/* default settings according to historic slirp */
struct in_addr net = { .s_addr = htonl(0x0a000200) }; /* 10.0.2.0 */
struct in_addr mask = { .s_addr = htonl(0xff00) }; /* 255.255.255.0 */
struct in_addr host = { .s_addr = htonl(0x0a000202) }; /* 10.0.2.2 */
+struct in6_addr ip6_prefix;
+struct in6_addr ip6_host;
struct in_addr dhcp = { .s_addr = htonl(0x0a00020f) }; /* 10.0.2.15 */
struct in_addr dns = { .s_addr = htonl(0x0a000203) }; /* 10.0.2.3 */
+struct in6_addr ip6_dns;
#ifndef _WIN32
struct in_addr smbsrv = { .s_addr = 0 };
#endif
@@ -212,6 +218,24 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
return -1;
}
+if (!vprefix6)
+vprefix6 = "fc00::";
+if (!inet_pton(AF_INET6, vprefix6, &ip6_prefix)) {
+return -1;
+}
+
+if (!vprefix6_len)
+vprefix6_len = 64;
+if (vprefix6_len < 0 || vprefix6_len > 128) {
+return -1;
+}
+
+if (!vhost6)
+vhost6 = "fc00::2";
+if (!inet_pton(AF_INET6, vhost6, &ip6_host)) {
+return -1;
+}
+
if (vnameserver && !inet_aton(vnameserver, &dns)) {
return -1;
}
@@ -220,6 +244,12 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
return -1;
}
+if (!vnameserver6)
+vnameserver6 = "fc00::3";
+if (!inet_pton(AF_INET6, vnameserver6, &ip6_dns)) {
+return -1;
+}
+
if (vdhcp_start && !inet_aton(vdhcp_start, &dhcp)) {
return -1;
}
@@ -242,8 +272,10 @@ static int net_slirp_init(NetClientState *peer, const char
*model,
s = DO_UPCAST(SlirpState, nc, nc);
-s->slirp = slirp_init(restricted, net, mask, host, vhostname,
- tftp_export, bootfile, dhcp, dns, dnssearch, s);
+s->slirp = slirp_init(restricted, net, mask, host,
+ ip6_prefix, vprefix6_len, ip6_host,
+ vhostname, tftp_export, bootfile, dhcp,
+ d
Re: [Qemu-devel] [PATCH] rdma: rename 'x-rdma' => 'rdma'
On 10/22/2013 05:59 PM, mrhi...@linux.vnet.ibm.com wrote: > From: "Michael R. Hines" > > As far as we can tell, all known bugs have been fixed, > there as been very good participation in testing and running. > > 1. Parallel RDMA migrations are working > 2. IPv6 migration is working > 3. Libvirt patches are ready > 4. virt-test is working > > Any objections to removing the experimental tag? > > There is one remaining bug: qemu-system-i386 does not compile > with RDMA: I have very zero access to 32-bit hardware > using RDMA, so this hasn't been much of a priority. It seems > safer to *not* submit non-testable patch rather than submit > submit a fix just for the sake of compiling =) > > Signed-off-by: Michael R. Hines > --- > > TODO: > = > -1. 'migrate x-rdma:host:port' and '-incoming x-rdma' options will be > +1. 'migrate rdma:host:port' and '-incoming rdma' options will be > renamed to 'rdma' after the experimental phase of this work has > completed upstream. Shouldn't you remove step 1 and renumber the rest of the list altogether, rather than just altering the comment to make it out-of-date? > +++ b/qapi-schema.json > @@ -615,7 +615,7 @@ > # This feature allows us to minimize migration traffic for certain > work > # loads, by sending compressed difference of the pages > # > -# @x-rdma-pin-all: Controls whether or not the entire VM memory footprint is > +# @rdma-pin-all: Controls whether or not the entire VM memory footprint is > # mlock()'d on demand or all at once. Refer to docs/rdma.txt for > usage. > # Disabled by default. Experimental: may (or may not) be renamed > after > # further testing is complete. (since 1.6) I'd also recommend tweaking this to say 'since 1.7', since the spelling 'rdma-pin-all' is new to this release. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 16/16] qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
On 10/22/2013 08:12 PM, Samuel Thibault wrote:
> I see. So it would be something like this?
>
> commit 1807466d691f281f430fbf8c0bbff6bf8073247d
> Author: Samuel Thibault
> Date: Tue Oct 22 21:11:46 2013 +0200
>
> qapi-schema, qemu-options & slirp: Adding Qemu options for IPv6 addresses
>
> This patchs adds parameters to manage some new options in the qemu -net
> command.
> Slirp IPv6 address, network prefix, and DNS IPv6 address can be given in
> argument to the qemu command.
> Defaults parameters are respectively fc00::2, fc00::, /64 and fc00::3.
>
> Signed-off-by: Yann Bordenave
> Signed-off-by: Samuel Thibault
Yes, this looks better from the interface point of view (I didn't
closely review the code though, as I'm not a slirp expert).
> { 'type': 'NetdevUserOptions',
>'data': {
> -'*hostname': 'str',
> -'*restrict': 'bool',
> -'*ip':'str',
> -'*net': 'str',
> -'*host': 'str',
> -'*tftp': 'str',
> -'*bootfile': 'str',
> -'*dhcpstart': 'str',
> -'*dns': 'str',
> -'*dnssearch': ['String'],
> -'*smb': 'str',
> -'*smbserver': 'str',
> -'*hostfwd': ['String'],
> -'*guestfwd': ['String'] } }
> +'*hostname':'str',
> +'*restrict':'bool',
> +'*ip': 'str',
> +'*net': 'str',
> +'*host':'str',
> +'*tftp':'str',
> +'*bootfile':'str',
> +'*dhcpstart': 'str',
> +'*dns': 'str',
> +'*dnssearch': ['String'],
> +'*ip6-prefix': 'str',
> +'*ip6-prefixlen': 'int',
> +'*ip6-host':'str',
> +'*ip6-dns': 'str',
> +'*smb': 'str',
> +'*smbserver': 'str',
> +'*hostfwd': ['String'],
> +'*guestfwd':['String'] } }
>
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [PATCH] doc: fix hardcode helper path
The install directory of qemu-bridge-helper is configurabled,
but we used a fixed path in document.
DEFAULT_BRIDGE_HELPER macro isn't available in texi mode,
we always use "/path/to/" prefix for dynamic path (eg:
/path/to/image, /path/to/linux, etc).
Signed-off-by: Amos Kong
---
qemu-options.hx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 5dc8b75..8b94264 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1605,7 +1605,7 @@ to disable script execution.
If running QEMU as an unprivileged user, use the network helper
@var{helper} to configure the TAP interface. The default network
-helper executable is @file{/usr/local/libexec/qemu-bridge-helper}.
+helper executable is @file{/path/to/qemu-bridge-helper}.
@option{fd}=@var{h} can be used to specify the handle of an already
opened host TAP interface.
@@ -1629,7 +1629,7 @@ qemu-system-i386 linux.img \
#launch a QEMU instance with the default network helper to
#connect a TAP device to bridge br0
qemu-system-i386 linux.img \
- -net nic -net
tap,"helper=/usr/local/libexec/qemu-bridge-helper"
+ -net nic -net tap,"helper=/path/to/qemu-bridge-helper"
@end example
@item -netdev bridge,id=@var{id}[,br=@var{bridge}][,helper=@var{helper}]
@@ -1638,7 +1638,7 @@ Connect a host TAP network interface to a host bridge
device.
Use the network helper @var{helper} to configure the TAP interface and
attach it to the bridge. The default network helper executable is
-@file{/usr/local/libexec/qemu-bridge-helper} and the default bridge
+@file{/path/to/qemu-bridge-helper} and the default bridge
device is @file{br0}.
Examples:
--
1.8.3.1
Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance
On 10/15/2013 03:26 AM, Jules Wang wrote: v2 -> v3: * add documentation of new option in qapi-schema. * long option name: ft -> fault-tolerant 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 | 10 ++- 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 | 6 +- qmp-commands.hx | 3 +- savevm.c | 178 +++--- 11 files changed, 303 insertions(+), 30 deletions(-) create mode 100644 docs/curling.txt Jules, I think we should work together. The patches I sent this week solve all of the problems (and more) of Kemari and have been in testing for over 1 year. 1. I/O buffering is already working 2. Checkpoint parallelism is already working 3. Staging of the checkpoint memory is already working on both the sender side and receiver side. 3. Checkpoint chunking is already working (this means that checkpoints can be very large and must be split up like slab caches, which can dynamically grow and shrink as the amount of diryt memory in the virtual machine fluctuates. 4. RDMA checkpointing is already working 5. TCP checkpointing is already working 6. There does not need to be a custom migration URI - this is easily implemented through a capability. 7. Libvirt support is already available on github. 8 There is no need to modify the QEMU migration metadata state information. All of these features take advantage of the recent advances in QEMU in migration performance improvements over the last few years. Would you be interested in "joining forces"? You even picked a cool name (I didn't even choose a name). =) Also: I will soon be working in IBM China Beijing, for 3 years - starting next month - perhaps we could talk on the phone (or meet in person)? - Michael
Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance
On 10/15/2013 03:26 AM, Jules Wang wrote: v2 -> v3: * add documentation of new option in qapi-schema. * long option name: ft -> fault-tolerant 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 | 10 ++- 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 | 6 +- qmp-commands.hx | 3 +- savevm.c | 178 +++--- 11 files changed, 303 insertions(+), 30 deletions(-) create mode 100644 docs/curling.txt Ooops, forgot to send you the wiki link: http://wiki.qemu.org/Features/MicroCheckpointing
[Qemu-devel] About VM fork in QEMU
Dear QEMU developers, I am a Ph.D. student in Penn State. And we are currently working on a project that needs to fork multiple instances of a same VM instance with exactly same state (e.g., memory layout, registers, etc.) in a very efficient way. Snapshot is too heavy for us because it needs to dump the memory state to the filesystem so that reverting is possible sometime later. Our project does not need to revert a VM to a previous snapshot but lively clone (or fork) multiple instances and make them run at the same time. Do you happen to know if it's possible to do this? What we are envisioning is copy-on-write would happen both on disks (e.g., qcow2) and memory state (e.g., physical pages). Thanks, Xinyang -- Xinyang GE Department of Computer Science & Engineering The Pennsylvania State University Homepage: http://www.cse.psu.edu/~xxg113/
Re: [Qemu-devel] About VM fork in QEMU
On 10/22/2013 09:23 PM, Xinyang Ge wrote: > Dear QEMU developers, > > I am a Ph.D. student in Penn State. And we are currently working on a > project that needs to fork multiple instances of a same VM instance > with exactly same state (e.g., memory layout, registers, etc.) in a > very efficient way. Snapshot is too heavy for us because it needs to > dump the memory state to the filesystem so that reverting is possible > sometime later. Our project does not need to revert a VM to a previous > snapshot but lively clone (or fork) multiple instances and make them > run at the same time. Do you happen to know if it's possible to do > this? What we are envisioning is copy-on-write would happen both on > disks (e.g., qcow2) and memory state (e.g., physical pages). Live cloning is a disaster waiting to happen if not done in a very carefully controlled environment (I could maybe see it useful across two private networks for forensic analysis or running "what-if" scenarios, but never for provisioning enterprise-quality public-facing servers). Remember, if you ever expose both forks of a live clone to the same network at the same time, you have a security vulnerability if you did not manage to scrube the random pool of the two guests to be different, where the crypto behavior of the second guest can be guessed by observing the behavior of the first. But scrubbing memory correctly requires knowing EXACTLY where in memory the random pool is stored, which is highly guest-dependent, and may be spread across multiple guest locations. With offline disk images, the set of information to scrub is a bit easier, and in fact, 'virt-sysprep' from the libguestfs tools can do it for a number of guests, but virt-sysprep (rightfully) refuses to try to scrub a live image. Do your forked guests really have to run in parallel, or is it sufficient to serialize the running of one variation followed by the other variation? As far as I know, the only way to run two guests that diverge from the same live state is to take a snapshot and then run two qemu instances that both point to that common state as their starting point, and I would personally never attempt it in parallel. Meanwhile, although you complained that snapshots are too heavyweight, it's really the only way I know to even begin to attempt live cloning with current qemu. Of course, being open source, you're welcome to submit a patch to add features to qemu to do a faster live clone. But be prepared for an uphill battle if you cannot prove that such a patch does not introduce security implications running improperly scrubbed forks in parallel. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition
On Oct 8, 2013, at 12:05 PM, Paolo Bonzini wrote: > Il 08/10/2013 16:49, Eric Blake ha scritto: >> You are now returning a state that older libvirt versions are not >> expecting. Obviously, we can patch newer libvirt to make migration work >> again, but should we be thinking about damage control by stating that an >> older management app should still be able to drive migration on a new >> qemu? Or is it acceptable to state that newer qemu requires newer >> management tools? > > We strive for that, but sometimes we break because we do not really know > what management expects from QEMU. > > In this case, in particular, I think a capability is a bit overkill. > Libvirt needs to be somewhat liberal in what it accepts; in this case it > can treat any unknown state as "active". > > Paolo > >> If we try to support this working under older management tools, maybe >> the approach is that we have to add some new migration capability; newer >> management tools set the capability to true and are therefore allowed to >> see the new state name; older management tools do not set the capability >> and when that is the case we guarantee that we do not return a state >> string that the older tool is not expecting. Thoughts on whether we >> should pursue this? > >
Re: [Qemu-devel] [PATCH v7] powerpc: add PVR mask support
On 10/14/2013 02:04 PM, Alexey Kardashevskiy wrote: > On 09/30/2013 09:30 PM, Alexander Graf wrote: >> >> On 27.09.2013, at 10:05, Alexey Kardashevskiy wrote: >> >>> 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 adds PVR value/mask support for KVM, i.e. for -cpu host option. >>> >>> 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 >> >> Looks reasonable to me, but I'll wait for an ack from Andreas. > > > Ping, anyone? Ping, anyone, please? -- Alexey
Re: [Qemu-devel] QueuePFN peculiarity in virtio-mmio
Laszlo Ersek writes: > Hi, > > "Appendix X: virtio-mmio" in the virtio spec says Hi Laszlo, You're in luck! We're currently revising the virtio spec under the OASIS banner. I'd really like you to post your suggestion to their mailing list (yes, you will have to subscribe to it, for IP reasons: virtio-comment-subscr...@lists.oasis-open.org. Thanks, Rusty.
Re: [Qemu-devel] Disabling IRQ error
Dear Max,
Sorry for the late reply.
Thanks for your advice about lowering the irqs after raising them,
and that fixed my problem.
Thanks again for your kindness.
Thanks,
Simen
于 2013/09/11 17:29, Max Filippov 写道:
On Wed, Sep 11, 2013 at 12:12 PM, Xie Xianshan wrote:
I want to add a new device "fpga" for e500, and trigger an interrupt IRQ3
while the register BB_INTR_REG which belongs to device "fpga" is wrote by
the device driver of "fpga".
For e500, IRQ3 is an external interrupt irq.
According the debug log, the disabling error is encoutered during writing
BB_INTR_REG register.
- write BB_INTR_REG register
- qemu_irq_raise() is called.
- after serval minutes,
the error message about disabling irq is displayed.
- continue the next execution without error(with poll?)
So your device raises IRQ, but it doesn't lower it. Real devices
usually don't do that, they either generate a short pulse on the
IRQ line (in case of edge-triggered IRQ) or raise IRQ line on
some event and then lower it on a command from its driver
(level-triggered IRQ).
You can do the following to make your device behave that way:
- make your fpga device capable of lowering its IRQ, e.g. by adding
another register:
static void fpga_write(FPGAState *s, unsigned int offset, uint32_t value,
unsigned size) {
switch(offset) {
case BB_INTR_REG:
qemu_irq_raise(s->irq);
break;
case BB_INTC_REG:
qemu_irq_lower(s->irq);
break;
}
}
- provide an interrupt service routine in the linux driver for your fpga
device that would check whether the interrupt was caused by its
device, and if so lower the device's IRQ.
Thanks.
-- Max
Re: [Qemu-devel] [PATCH_v2 0/9] target-openrisc: Corrections and speed improvements
Hi Sebastian, On Tue, Oct 22, 2013 at 8:12 AM, Sebastian Macke wrote: > > This series is the first part to make the OpenRISC target more > reliable and faster. > It corrects several severe problems which prevented the OpenRISC emulation > for being useful in the past. > > The patchset was tested with > - the tests/tcg/openrisc tests > - booting Linux 3.11 > - run configure + make + gcc of a simple terminal graphic demo called > cmatrix > - run benchmark tool nbench in qemu-user mode and in the softmmu mode > > The speed improvement is less than 10% because the overhead is still to high > as the openrisc target does not support translation block chaining. > This will be included in one of the future patches. > > Only the patch which removes the npc and ppc variables removes a little > feature > from the OpenRISC target but which does not break the specification and will > lead to > a significant speed improvement. For v2 0/9 - 9/9 Acked-by: Jia Liu I'll add some comment into the code to explain why we separate flags from sr and send a pull request if nobody raise a rejection. > > > Sebastian Macke (9): > target-openrisc: Speed up move instruction > target-openrisc: Remove unnecessary code generated by jump > instructions > target-openrisc: Remove executable flag for every page > target-openrisc: Correct wrong epcr register in interrupt handler > openrisc-timer: Reduce overhead, Separate clock update functions > target-openrisc: Correct memory bounds checking for the tlb buffers > target-openrisc: Separate branch flag from Supervision register > target-openrisc: Complete remove of npc and ppc variables > target-openrisc: Correct carry flag check of l.addc and l.addic test > cases > > hw/openrisc/cputimer.c | 29 -- > target-openrisc/cpu.c | 1 + > target-openrisc/cpu.h | 16 ++- > target-openrisc/gdbstub.c | 20 +--- > target-openrisc/interrupt.c| 27 ++--- > target-openrisc/interrupt_helper.c | 3 +- > target-openrisc/machine.c | 3 +- > target-openrisc/mmu.c | 4 +- > target-openrisc/sys_helper.c | 74 ++ > target-openrisc/translate.c| 201 > - > tests/tcg/openrisc/test_addc.c | 8 +- > tests/tcg/openrisc/test_addic.c| 10 +- > 12 files changed, 175 insertions(+), 221 deletions(-) > > -- > 1.8.4.1 > Regards, Jia
Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance
On 2013-10-22 17:00 -0400，Michael R. Hines wrote： > On 10/15/2013 03:26 AM, Jules Wang wrote: > > v2 -> v3: > > * add documentation of new option in qapi-schema. > > > > * long option name: ft -> fault-tolerant > > > > 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 | 10 ++- > > 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 | 6 +- > > qmp-commands.hx | 3 +- > > savevm.c | 178 > > +++--- > > 11 files changed, 303 insertions(+), 30 deletions(-) > > create mode 100644 docs/curling.txt > > > > Jules, I think we should work together. The patches I sent this week > solve all of the problems (and more) of Kemari and have been in > testing for over 1 year. > > 1. I/O buffering is already working > 2. Checkpoint parallelism is already working > 3. Staging of the checkpoint memory is already working > on both the sender side and receiver side. > 3. Checkpoint chunking is already working (this means that checkpoints > can be very large and must be split up like slab caches, > which can dynamically grow and shrink as the amount of > diryt memory in the virtual machine fluctuates. > 4. RDMA checkpointing is already working > 5. TCP checkpointing is already working > 6. There does not need to be a custom migration URI > - this is easily implemented through a capability. > 7. Libvirt support is already available on github. > 8 There is no need to modify the QEMU migration metadata state information. > > All of these features take advantage of the recent advances > in QEMU in migration performance improvements over the last > few years. I will read your patches carefully as a good learning material. > > Would you be interested in "joining forces"? You even picked > a cool name (I didn't even choose a name). =) Yes, your solution is better than mine obviously, and we could work together to improve your patches. > > Also: I will soon be working in IBM China Beijing, for 3 years - starting > next month - perhaps we could talk on the phone (or meet in person)? Welcome to Beijing and take some dust masks with you, you will need them. :) I prefer email or meet in person if necessary. I will read and try your patches first. > - Michael > > >
Re: [Qemu-devel] [Qemu-trivial] [PATCH v3] misc: Spelling and grammar fixes in comments
Am 21.10.2013 10:46, schrieb Michael Tokarev: > So guys, do we agree to apply this or not, after all? :) > > Thanks, > > /mjt The discussion was a bit confusing. Finally, the patch got two reviews (Reviewed-by: Peter Maydell , Reviewed-By: Don Koch , see http://patchwork.ozlabs.org/patch/282925/).I assume that Reviewed-By is unusual but obviously the same as Reviewed-by. Eric Blake wrote that he liked the approach of patch v2, but did not object to v3. Therefore I think that you can take the patch v3 into your queue. Regards, Stefan
Re: [Qemu-devel] [PATCH v8 0/2] bugs fix for hpet
ping? Any further comment? Thanks On Fri, Oct 18, 2013 at 12:00 PM, Liu Ping Fan wrote: > v8: > make piix/q35 compat diverge > simplify the code, use hpet_irqs to pass "intcap" value > > v7: > use macro to define "intcap" in pc.h > (as to 3/4 and 4/4, I am not sure about whether to merge them or not, so > keep them separate") > > v6: > move the setting of intcap to board, and keep the init value as zero. > (thanks for the discussion from Paolo and Michael) > introduce an extra hpet property "compat" to tell PC version > > v5: > use stand compat property to fix hpet intcap on pc-q35, while on pc-piix, > hard code intcap as IRQ2 > > v4: > use stand compat property to fix hpet intcap > > v3: > change hpet interrupt capablity on board's demand > > > Liu Ping Fan (2): > hpet: inverse polarity when pin above ISA_NUM_IRQS > hpet: enable to entitle more irq pins for hpet > > hw/i386/pc.c | 19 --- > hw/i386/pc_piix.c| 3 ++- > hw/i386/pc_q35.c | 21 + > hw/timer/hpet.c | 23 +++ > include/hw/i386/pc.h | 24 +++- > 5 files changed, 77 insertions(+), 13 deletions(-) > > -- > 1.8.1.4 >
Re: [Qemu-devel] [PATCH] MAINTAINERS: add block driver sub-maintainers
At Mon, 21 Oct 2013 14:26:15 +0100, Stefan Hajnoczi wrote: > > There are a number of contributors who maintain block drivers (image > formats and protocols). They should be listed in the MAINTAINERS file > so that get_maintainer.pl lists them. > > Note that commits are still merged through Kevin or Stefan's block tree > but the block driver sub-maintainers are usually the ones to review > patches. > > Acked-by: Kevin Wolf > Signed-off-by: Stefan Hajnoczi > --- > MAINTAINERS | 38 ++ > 1 file changed, 38 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 77edacf..da18a23 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -857,3 +857,41 @@ Stable 0.10 > L: qemu-sta...@nongnu.org > T: git git://git.qemu-project.org/qemu-stable-0.10.git > S: Orphan > + > +Block drivers > +- > +VMDK > +M: Fam Zheng > +S: Supported > +F: block/vmdk.c > + > +RBD > +M: Josh Durgin > +S: Supported > +F: block/rbd.c > + > +Sheepdog > +M: MORITA Kazutaka > +S: Supported > +F: block/sheepdog.c Acked-by: MORITA Kazutaka
