[Qemu-devel] [PATCH 3/3] pseries: Use Book3S-HV TCE acceleration capabilities
The pseries machine of qemu implements the TCE mechanism used as a
virtual IOMMU for the PAPR defined virtual IO devices. Because the
PAPR spec only defines a small DMA address space, the guest VIO
drivers need to update TCE mappings very frequently - the virtual
network device is particularly bad. This means many slow exits to
qemu to emulate the H_PUT_TCE hypercall.
Sufficiently recent kernels allow this to be mitigated by implementing
H_PUT_TCE in the host kernel. To make use of this, however, qemu
needs to initialize the necessary TCE tables, and map them into itself
so that the VIO device implementations can retrieve the mappings when
they access guest memory (which is treated as a virtual DMA
operation).
This patch adds the necessary calls to use the KVM TCE acceleration.
If the kernel does not support acceleration, or there is some other
error creating the accelerated TCE table, then it will still fall back
to full userspace TCE implementation.
Signed-off-by: David Gibson
---
hw/spapr_vio.c |8 ++-
hw/spapr_vio.h |1 +
target-ppc/kvm.c | 54 ++
target-ppc/kvm_ppc.h | 14 +
4 files changed, 76 insertions(+), 1 deletions(-)
diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
index 35818e1..1da3032 100644
--- a/hw/spapr_vio.c
+++ b/hw/spapr_vio.c
@@ -165,7 +165,13 @@ static void rtce_init(VIOsPAPRDevice *dev)
* sizeof(VIOsPAPR_RTCE);
if (size) {
-dev->rtce_table = g_malloc0(size);
+dev->rtce_table = kvmppc_create_spapr_tce(dev->reg,
+ dev->rtce_window_size,
+ &dev->kvmtce_fd);
+
+if (!dev->rtce_table) {
+dev->rtce_table = g_malloc0(size);
+}
}
}
diff --git a/hw/spapr_vio.h b/hw/spapr_vio.h
index 4fe5f74..a325a5f 100644
--- a/hw/spapr_vio.h
+++ b/hw/spapr_vio.h
@@ -57,6 +57,7 @@ typedef struct VIOsPAPRDevice {
target_ulong signal_state;
uint32_t rtce_window_size;
VIOsPAPR_RTCE *rtce_table;
+int kvmtce_fd;
VIOsPAPR_CRQ crq;
} VIOsPAPRDevice;
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 37ee902..866cf7f 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -28,6 +28,7 @@
#include "kvm_ppc.h"
#include "cpu.h"
#include "device_tree.h"
+#include "hw/sysbus.h"
#include "hw/spapr.h"
#include "hw/sysbus.h"
@@ -58,6 +59,7 @@ static int cap_ppc_smt = 0;
#ifdef KVM_CAP_PPC_RMA
static int cap_ppc_rma = 0;
#endif
+static int cap_spapr_tce = false;
/* XXX We have a race condition where we actually have a level triggered
* interrupt, but the infrastructure can't expose that yet, so the guest
@@ -87,6 +89,9 @@ int kvm_arch_init(KVMState *s)
#ifdef KVM_CAP_PPC_RMA
cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
#endif
+#ifdef KVM_CAP_SPAPR_TCE
+cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
+#endif
if (!cap_interrupt_level) {
fprintf(stderr, "KVM: Couldn't find level irq capability. Expect the "
@@ -792,6 +797,55 @@ off_t kvmppc_alloc_rma(const char *name)
#endif
}
+void *kvmppc_create_spapr_tce(target_ulong liobn, uint32_t window_size, int
*pfd)
+{struct kvm_create_spapr_tce args = {
+.liobn = liobn,
+.window_size = window_size,
+};
+long len;
+int fd;
+void *table;
+
+if (!cap_spapr_tce) {
+return NULL;
+}
+
+fd = kvm_vm_ioctl(kvm_state, KVM_CREATE_SPAPR_TCE, &args);
+if (fd < 0) {
+return NULL;
+}
+
+len = (window_size / SPAPR_VIO_TCE_PAGE_SIZE) * sizeof(VIOsPAPR_RTCE);
+/* FIXME: round this up to page size */
+
+table = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
+if (table == MAP_FAILED) {
+close(fd);
+return NULL;
+}
+
+*pfd = fd;
+return table;
+}
+
+int kvmppc_remove_spapr_tce(void *table, int fd, uint32_t window_size)
+{
+long len;
+
+if (fd < 0)
+return -1;
+
+len = (window_size / SPAPR_VIO_TCE_PAGE_SIZE)*sizeof(VIOsPAPR_RTCE);
+if ((munmap(table, len) < 0) ||
+(close(fd) < 0)) {
+fprintf(stderr, "KVM: Unexpected error removing KVM SPAPR TCE "
+"table: %s", strerror(errno));
+/* Leak the table */
+}
+
+return 0;
+}
+
bool kvm_arch_stop_on_emulation_error(CPUState *env)
{
return true;
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index ad9903c..b78579a 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -20,6 +20,8 @@ int kvmppc_set_interrupt(CPUState *env, int irq, int level);
void kvmppc_set_papr(CPUState *env);
int kvmppc_smt_threads(void);
off_t kvmppc_alloc_rma(const char *name);
+void *kvmppc_create_spapr_tce(target_ulong liobn, uint32_t window_size, int
*fd);
+int kvmppc_remove_spapr_tce(void *table, int pfd, uint32_t window_size);
#else
@@ -57,6 +59,18 @@ static inline off_t kvmppc_alloc_rma(const char *name)
r
[Qemu-devel] [0/3] pseries: Support and improvements for KVM Book3S-HV support
Alex Graf has added support for KVM acceleration of the pseries machine, using his Book3S-PR KVM variant, which runs the guest in userspace, emulating supervisor operations. Recent kernels now have the Book3S-HV KVM variant which uses the hardware hypervisor features of recent POWER CPUs. Alex's changes to qemu are enough to get qemu working roughly with Book3S-HV, but taking full advantage of this mode needs more work. This patch series makes a start on better exploiting Book3S-HV. Even with these patches, qemu won't quite be able to run on a current Book3S-HV KVM kernel. That's because current Book3S-HV requires guest memory to be backed by hugepages, but qemu refuses to use hugepages for guest memory unless KVM advertises CAP_SYNC_MMU, which Book3S-HV does not currently do. We're working on improvements to the KVM code which will implement CAP_SYNC_MMU and allow smallpage backing of guests, but they're not there yet. So, in order to test Book3S-HV for now you need to either: * Hack the host kernel to lie and advertise CAP_SYNC_MMU even though it doesn't really implement it. or * Hack qemu so it does not check for CAP_SYNC_MMU when the -mem-path option is used. Bot approaches are ugly and unsafe, but it seems we can generally get away with it in practice. Obviously this is only an interim hack until the proper CAP_SYNC_MMU support is ready.
[Qemu-devel] [PATCH 2/3] pseries: Allow KVM Book3S-HV on PPC970 CPUS
At present, using the hypervisor aware Book3S-HV KVM will only work
with qemu on POWER7 CPUs. PPC970 CPUs also have hypervisor
capability, but they lack the VRMA feature which makes assigning guest
memory easier.
In order to allow KVM Book3S-HV on PPC970, we need to specially
allocate the first chunk of guest memory (the "Real Mode Area" or
RMA), so that it is physically contiguous.
Sufficiently recent host kernels allow such contiguous RMAs to be
allocated, with a kvm capability advertising whether the feature is
available and/or necessary on this hardware. This patch enables qemu
to use this support, thus allowing kvm acceleration of pseries qemu
machines on PPC970 hardware.
Signed-off-by: Paul Mackerras
Signed-off-by: David Gibson
---
hw/spapr.c | 50
target-ppc/kvm.c | 51 ++
target-ppc/kvm_ppc.h |6 +
3 files changed, 98 insertions(+), 9 deletions(-)
diff --git a/hw/spapr.c b/hw/spapr.c
index ba9ae1c..d51425a 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -89,6 +89,7 @@ qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t *irq_num)
}
static void *spapr_create_fdt_skel(const char *cpu_model,
+ target_phys_addr_t rma_size,
target_phys_addr_t initrd_base,
target_phys_addr_t initrd_size,
const char *boot_device,
@@ -97,7 +98,9 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
{
void *fdt;
CPUState *env;
-uint64_t mem_reg_property[] = { 0, cpu_to_be64(ram_size) };
+uint64_t mem_reg_property_rma[] = { 0, cpu_to_be64(rma_size) };
+uint64_t mem_reg_property_nonrma[] = { cpu_to_be64(rma_size),
+ cpu_to_be64(ram_size - rma_size) };
uint32_t start_prop = cpu_to_be32(initrd_base);
uint32_t end_prop = cpu_to_be32(initrd_base + initrd_size);
uint32_t pft_size_prop[] = {0, cpu_to_be32(hash_shift)};
@@ -143,15 +146,25 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
_FDT((fdt_end_node(fdt)));
-/* memory node */
+/* memory node(s) */
_FDT((fdt_begin_node(fdt, "memory@0")));
_FDT((fdt_property_string(fdt, "device_type", "memory")));
-_FDT((fdt_property(fdt, "reg",
- mem_reg_property, sizeof(mem_reg_property;
-
+_FDT((fdt_property(fdt, "reg", mem_reg_property_rma,
+ sizeof(mem_reg_property_rma;
_FDT((fdt_end_node(fdt)));
+if (ram_size > rma_size) {
+char mem_name[32];
+
+ sprintf(mem_name, "memory@%" PRIx64, (uint64_t)rma_size);
+ _FDT((fdt_begin_node(fdt, mem_name)));
+ _FDT((fdt_property_string(fdt, "device_type", "memory")));
+_FDT((fdt_property(fdt, "reg", mem_reg_property_nonrma,
+ sizeof(mem_reg_property_nonrma;
+_FDT((fdt_end_node(fdt)));
+}
+
/* cpus */
_FDT((fdt_begin_node(fdt, "cpus")));
@@ -341,6 +354,7 @@ static void ppc_spapr_init(ram_addr_t ram_size,
{
CPUState *env;
int i;
+target_phys_addr_t rma_alloc_size, rma_size;
ram_addr_t ram_offset;
uint32_t initrd_base;
long kernel_size, initrd_size, fw_size;
@@ -350,10 +364,23 @@ static void ppc_spapr_init(ram_addr_t ram_size,
spapr = g_malloc(sizeof(*spapr));
cpu_ppc_hypercall = emulate_spapr_hypercall;
+/* Allocate RMA if necessary */
+rma_alloc_size = kvmppc_alloc_rma("ppc_spapr.rma");
+
+if (rma_alloc_size == -1) {
+hw_error("qemu: Unable to create RMA\n");
+exit(1);
+}
+if (rma_alloc_size && (rma_alloc_size < ram_size)) {
+rma_size = rma_alloc_size;
+} else {
+rma_size = ram_size;
+}
+
/* We place the device tree just below either the top of RAM, or
* 2GB, so that it can be processed with 32-bit code if
* necessary */
-spapr->fdt_addr = MIN(ram_size, 0x8000) - FDT_MAX_SIZE;
+spapr->fdt_addr = MIN(rma_size, 0x8000) - FDT_MAX_SIZE;
spapr->rtas_addr = spapr->fdt_addr - RTAS_MAX_SIZE;
/* init CPUs */
@@ -378,8 +405,13 @@ static void ppc_spapr_init(ram_addr_t ram_size,
/* allocate RAM */
spapr->ram_limit = ram_size;
-ram_offset = qemu_ram_alloc(NULL, "ppc_spapr.ram", spapr->ram_limit);
-cpu_register_physical_memory(0, ram_size, ram_offset);
+if (spapr->ram_limit > rma_alloc_size) {
+ram_addr_t nonrma_base = rma_alloc_size;
+ram_addr_t nonrma_size = spapr->ram_limit - rma_alloc_size;
+
+ram_offset = qemu_ram_alloc(NULL, "ppc_spapr.ram", nonrma_size);
+cpu_register_physical_memory(nonrma_base, nonrma_size, ram_offset);
+}
/* allocate hash page table. For now we always make this 16mb,
* later we should probably make it scale to the size of guest
@@ -503,7 +535,7 @@ static void ppc_spapr
[Qemu-devel] [PATCH 1/3] pseries: Support SMT systems for KVM Book3S-HV
Alex Graf has already made qemu support KVM for the pseries machine
when using the Book3S-PR KVM variant (which runs the guest in
usermode, emulating supervisor operations). This code allows gets us
very close to also working with KVM Book3S-HV (using the hypervisor
capabilities of recent POWER CPUs).
This patch moves us another step towards Book3S-HV support by
correctly handling SMT (multithreaded) POWER CPUs. There are two
parts to this:
* Querying KVM to check SMT capability, and if present, adjusting the
cpu numbers that qemu assigns to cause KVM to assign guest threads
to cores in the right way (this isn't automatic, because the POWER
HV support has a limitation that different threads on a single core
cannot be in different guests at the same time).
* Correctly informing the guest OS of the SMT thread to core mappings
via the device tree.
Signed-off-by: David Gibson
---
hw/spapr.c | 23 ---
target-ppc/helper.c | 11 +++
target-ppc/kvm.c | 10 ++
target-ppc/kvm_ppc.h |6 ++
4 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/hw/spapr.c b/hw/spapr.c
index b118975..ba9ae1c 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -29,6 +29,9 @@
#include "elf.h"
#include "net.h"
#include "blockdev.h"
+#include "cpus.h"
+#include "kvm.h"
+#include "kvm_ppc.h"
#include "hw/boards.h"
#include "hw/ppc.h"
@@ -103,6 +106,7 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
uint32_t interrupt_server_ranges_prop[] = {0, cpu_to_be32(smp_cpus)};
int i;
char *modelname;
+int smt = kvmppc_smt_threads();
#define _FDT(exp) \
do { \
@@ -162,13 +166,17 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
for (env = first_cpu; env != NULL; env = env->next_cpu) {
int index = env->cpu_index;
-uint32_t gserver_prop[] = {cpu_to_be32(index), 0}; /* HACK! */
+uint32_t servers_prop[smp_threads];
+uint32_t gservers_prop[smp_threads * 2];
char *nodename;
uint32_t segs[] = {cpu_to_be32(28), cpu_to_be32(40),
0x, 0x};
uint32_t tbfreq = kvm_enabled() ? kvmppc_get_tbfreq() : TIMEBASE_FREQ;
uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq() : 10;
+if ((index % smt) != 0)
+continue;
+
if (asprintf(&nodename, "%s@%x", modelname, index) < 0) {
fprintf(stderr, "Allocation failure\n");
exit(1);
@@ -193,9 +201,18 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
pft_size_prop, sizeof(pft_size_prop;
_FDT((fdt_property_string(fdt, "status", "okay")));
_FDT((fdt_property(fdt, "64-bit", NULL, 0)));
-_FDT((fdt_property_cell(fdt, "ibm,ppc-interrupt-server#s", index)));
+
+/* Build interrupt servers and gservers properties */
+for (i = 0; i < smp_threads; i++) {
+servers_prop[i] = cpu_to_be32(index + i);
+/* Hack, direct the group queues back to cpu 0 */
+gservers_prop[i*2] = cpu_to_be32(index + i);
+gservers_prop[i*2 + 1] = 0;
+}
+_FDT((fdt_property(fdt, "ibm,ppc-interrupt-server#s",
+ servers_prop, sizeof(servers_prop;
_FDT((fdt_property(fdt, "ibm,ppc-interrupt-gserver#s",
- gserver_prop, sizeof(gserver_prop;
+ gservers_prop, sizeof(gservers_prop;
if (env->mmu_model & POWERPC_MMU_1TSEG) {
_FDT((fdt_property(fdt, "ibm,processor-segment-sizes",
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 6339be3..137a494 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -26,6 +26,8 @@
#include "helper_regs.h"
#include "qemu-common.h"
#include "kvm.h"
+#include "kvm_ppc.h"
+#include "cpus.h"
//#define DEBUG_MMU
//#define DEBUG_BATS
@@ -3189,6 +3191,15 @@ CPUPPCState *cpu_ppc_init (const char *cpu_model)
if (tcg_enabled()) {
ppc_translate_init();
}
+/* Adjust cpu index for SMT */
+#if !defined(CONFIG_USER_ONLY)
+if (kvm_enabled()) {
+int smt = kvmppc_smt_threads();
+
+env->cpu_index = (env->cpu_index / smp_threads)*smt
++ (env->cpu_index % smp_threads);
+}
+#endif /* !CONFIG_USER_ONLY */
env->cpu_model_str = cpu_model;
cpu_ppc_register_internal(env, def);
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index 35a6f10..2c1bc7a 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -28,6 +28,7 @@
#include "kvm_ppc.h"
#include "cpu.h"
#include "device_tree.h"
+#include "hw/spapr.h"
#include "hw/sysbus.h"
#include "hw/spapr.h"
@@ -53,6 +54,7 @@ static int cap_interrupt_unset = false;
static int cap_interrupt_level = false;
static int cap_segstate;
static int cap_booke_sregs;
+static int cap_ppc_smt = 0;
/* XXX We have a race condition where we actually have a
Re: [Qemu-devel] [PATCH v3 0/6]: block: Add I/O status support
On 09/27/2011 04:43 AM, Luiz Capitulino wrote: This series adds support to the block layer to keep track of devices' I/O status. That information is also made available in QMP and HMP. The goal here is to allow management applications that miss the BLOCK_IO_ERROR event to able to query the VM to determine if any device has caused the VM to stop and which device caused it. Here's an HMP example: (qemu) info status VM status: paused (io-error) (qemu) info block ide0-hd0: removable=0 io-status=ok file=disks/test2.img ro=0 drv=qcow2 encrypted=0 ide0-hd1: removable=0 io-status=nospace file=/dev/vg_doriath/kvmtest ro=0 drv=qcow2 encrypted=0 ide1-cd0: removable=1 locked=0 io-status=ok [not inserted] floppy0: removable=1 locked=0 [not inserted] sd0: removable=1 locked=0 [not inserted] The session above shows that the VM is stopped due to an I/O error. By using the info block command it's possible to determine that the 'ide0-hd1' device caused the error, which turns out to be due to no space. I test it with the options enospc and stop on virtio and scsi models. It works fine. Tested-by: Mark Wu
Re: [Qemu-devel] [PATCH 1/3] pseries: Support SMT systems for KVM Book3S-HV
On 2011-09-29 08:45, David Gibson wrote: > diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c > index 35a6f10..2c1bc7a 100644 > --- a/target-ppc/kvm.c > +++ b/target-ppc/kvm.c ... > @@ -76,6 +78,9 @@ int kvm_arch_init(KVMState *s) > cap_interrupt_level = kvm_check_extension(s, KVM_CAP_PPC_IRQ_LEVEL); > cap_segstate = kvm_check_extension(s, KVM_CAP_PPC_SEGSTATE); > cap_booke_sregs = kvm_check_extension(s, KVM_CAP_PPC_BOOKE_SREGS); > +#ifdef KVM_CAP_PPC_SMT > +cap_ppc_smt = kvm_check_extension(s, KVM_CAP_PPC_SMT); > +#endif Just use update-linux-headers.sh if the CAP is missing and drop the #ifdef. Same for patch 2 & 3. Jan signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 3/3] pseries: Use Book3S-HV TCE acceleration capabilities
On 2011-09-29 08:45, David Gibson wrote:
> The pseries machine of qemu implements the TCE mechanism used as a
> virtual IOMMU for the PAPR defined virtual IO devices. Because the
> PAPR spec only defines a small DMA address space, the guest VIO
> drivers need to update TCE mappings very frequently - the virtual
> network device is particularly bad. This means many slow exits to
> qemu to emulate the H_PUT_TCE hypercall.
>
> Sufficiently recent kernels allow this to be mitigated by implementing
> H_PUT_TCE in the host kernel. To make use of this, however, qemu
> needs to initialize the necessary TCE tables, and map them into itself
> so that the VIO device implementations can retrieve the mappings when
> they access guest memory (which is treated as a virtual DMA
> operation).
>
> This patch adds the necessary calls to use the KVM TCE acceleration.
> If the kernel does not support acceleration, or there is some other
> error creating the accelerated TCE table, then it will still fall back
> to full userspace TCE implementation.
>
> Signed-off-by: David Gibson
> ---
> hw/spapr_vio.c |8 ++-
> hw/spapr_vio.h |1 +
> target-ppc/kvm.c | 54
> ++
> target-ppc/kvm_ppc.h | 14 +
> 4 files changed, 76 insertions(+), 1 deletions(-)
>
> diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
> index 35818e1..1da3032 100644
> --- a/hw/spapr_vio.c
> +++ b/hw/spapr_vio.c
> @@ -165,7 +165,13 @@ static void rtce_init(VIOsPAPRDevice *dev)
> * sizeof(VIOsPAPR_RTCE);
>
> if (size) {
> -dev->rtce_table = g_malloc0(size);
> +dev->rtce_table = kvmppc_create_spapr_tce(dev->reg,
> + dev->rtce_window_size,
> + &dev->kvmtce_fd);
> +
> +if (!dev->rtce_table) {
> +dev->rtce_table = g_malloc0(size);
> +}
> }
> }
>
> diff --git a/hw/spapr_vio.h b/hw/spapr_vio.h
> index 4fe5f74..a325a5f 100644
> --- a/hw/spapr_vio.h
> +++ b/hw/spapr_vio.h
> @@ -57,6 +57,7 @@ typedef struct VIOsPAPRDevice {
> target_ulong signal_state;
> uint32_t rtce_window_size;
> VIOsPAPR_RTCE *rtce_table;
> +int kvmtce_fd;
> VIOsPAPR_CRQ crq;
> } VIOsPAPRDevice;
>
> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
> index 37ee902..866cf7f 100644
> --- a/target-ppc/kvm.c
> +++ b/target-ppc/kvm.c
> @@ -28,6 +28,7 @@
> #include "kvm_ppc.h"
> #include "cpu.h"
> #include "device_tree.h"
> +#include "hw/sysbus.h"
> #include "hw/spapr.h"
>
> #include "hw/sysbus.h"
> @@ -58,6 +59,7 @@ static int cap_ppc_smt = 0;
> #ifdef KVM_CAP_PPC_RMA
> static int cap_ppc_rma = 0;
> #endif
> +static int cap_spapr_tce = false;
>
> /* XXX We have a race condition where we actually have a level triggered
> * interrupt, but the infrastructure can't expose that yet, so the guest
> @@ -87,6 +89,9 @@ int kvm_arch_init(KVMState *s)
> #ifdef KVM_CAP_PPC_RMA
> cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
> #endif
> +#ifdef KVM_CAP_SPAPR_TCE
> +cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
> +#endif
>
> if (!cap_interrupt_level) {
> fprintf(stderr, "KVM: Couldn't find level irq capability. Expect the
> "
> @@ -792,6 +797,55 @@ off_t kvmppc_alloc_rma(const char *name)
> #endif
> }
>
> +void *kvmppc_create_spapr_tce(target_ulong liobn, uint32_t window_size, int
> *pfd)
> +{struct kvm_create_spapr_tce args = {
Missing newline?
And please make sure your patches pass checkpatch.pl.
Jan
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] Add minimal support for Cortex A15 for ARM KVM
This patch adds minimal support for Cortex A15 to run under ARM KVM, which pavesthe way to ARM interrupt/time virtualization. Patches are based on: git://git.ncl.cs.columbia.edu/pub/git/qemu For how to setup ARM KVM environment, please refer: http://wiki.ncl.cs.columbia.edu/wiki/KVMARM:Guides:Development_Environment Makefile.target |2 +- hw/a15mpcore.c | 146 ++ hw/vexpress.c | 192 +++ target-arm/cpu.h|1 + target-arm/helper.c | 31 5 files changed, 371 insertions(+), 1 deletions(-) create mode 100644 hw/a15mpcore.c
[Qemu-devel] [PATCH] Add Qemu A15 minimal support for ARM KVM
From: Bill Carson
This patch add some A15 codes which enables ARM KVM could run
Guest OS build with Versatile Express Cortex-A15x4 tile.
Signed-off-by: Bill Carson
---
Makefile.target |2 +-
hw/a15mpcore.c | 146 ++
hw/vexpress.c | 192 +++
target-arm/cpu.h|1 +
target-arm/helper.c | 31
5 files changed, 371 insertions(+), 1 deletions(-)
create mode 100644 hw/a15mpcore.c
diff --git a/Makefile.target b/Makefile.target
index 2501c63..3899869 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -331,7 +331,7 @@ endif
obj-arm-y = integratorcp.o versatilepb.o arm_pic.o arm_timer.o
obj-arm-y += arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
obj-arm-y += versatile_pci.o
-obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
+obj-arm-y += realview_gic.o realview.o arm_sysctl.o arm11mpcore.o a9mpcore.o
a15mpcore.o
obj-arm-y += armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
obj-arm-y += pl061.o
obj-arm-y += arm-semi.o
diff --git a/hw/a15mpcore.c b/hw/a15mpcore.c
new file mode 100644
index 000..cf7ec38
--- /dev/null
+++ b/hw/a15mpcore.c
@@ -0,0 +1,146 @@
+/*
+ * ARM MPCore internal peripheral emulation (common code).
+ *
+ * Copyright (c) 2006-2007 CodeSourcery.
+ * Written by Paul Brook
+ *
+ * This code is licenced under the GPL.
+ */
+
+#include "sysbus.h"
+#include "qemu-timer.h"
+
+/* 64 external IRQ lines. */
+#define GIC_NIRQ 96
+
+
+#define NCPU 4
+
+static inline int
+gic_get_current_cpu(void)
+{
+ return cpu_single_env->cpu_index;
+}
+
+#include "arm_gic.c"
+
+/* MPCore private memory region. */
+
+typedef struct {
+uint32_t count;
+uint32_t load;
+uint32_t control;
+uint32_t status;
+uint32_t old_status;
+int64_t tick;
+QEMUTimer *timer;
+struct a15mpcore_priv_state *mpcore;
+int id; /* Encodes both timer/watchdog and CPU. */
+} mpcore_timer_state;
+
+typedef struct a15mpcore_priv_state {
+gic_state gic;
+uint32_t scu_control;
+int iomemtype;
+mpcore_timer_state timer[8];
+uint32_t num_cpu;
+} a15mpcore_priv_state;
+
+/* TODO:Per-CPU Timers. */
+
+
+/* Per-CPU private memory mapped IO. */
+
+static uint32_t a15mpcore_priv_read(void *opaque, target_phys_addr_t offset)
+{
+a15mpcore_priv_state *s = (a15mpcore_priv_state *)opaque;
+int id;
+offset &= 0xfff;
+ uint32_t value;
+
+/* Interrupt controller. */
+if (offset < 0x200) {
+ id = gic_get_current_cpu();
+} else {
+ id = (offset - 0x200) >> 8;
+if (id >= s->num_cpu) {
+ return 0;
+}
+ }
+
+ value = gic_cpu_read(&s->gic, id, offset & 0xff);
+ return value;
+}
+
+static void a15mpcore_priv_write(void *opaque, target_phys_addr_t offset,
+ uint32_t value)
+{
+a15mpcore_priv_state *s = (a15mpcore_priv_state *)opaque;
+ int id;
+
+offset &= 0xfff;
+/* Interrupt controller. */
+if (offset < 0x200) {
+ id = gic_get_current_cpu();
+} else {
+id = (offset - 0x200) >> 8;
+}
+if (id < s->num_cpu) {
+gic_cpu_write(&s->gic, id, offset & 0xff, value);
+ }
+
+return;
+}
+
+static CPUReadMemoryFunc * const a15mpcore_priv_readfn[] = {
+ a15mpcore_priv_read,
+ a15mpcore_priv_read,
+ a15mpcore_priv_read
+};
+
+static CPUWriteMemoryFunc * const a15mpcore_priv_writefn[] = {
+ a15mpcore_priv_write,
+ a15mpcore_priv_write,
+ a15mpcore_priv_write
+};
+
+static void a15mpcore_priv_map(SysBusDevice *dev, target_phys_addr_t base)
+{
+a15mpcore_priv_state *s = FROM_SYSBUSGIC(a15mpcore_priv_state, dev);
+cpu_register_physical_memory(base + 0x2000, 0x1000, s->iomemtype);/* cpu
interface */
+cpu_register_physical_memory(base + 0x1000, 0x1000, s->gic.iomemtype);/*
distributor */
+}
+
+static int a15mpcore_priv_init(SysBusDevice *dev)
+{
+a15mpcore_priv_state *s = FROM_SYSBUSGIC(a15mpcore_priv_state, dev);
+
+gic_init(&s->gic, s->num_cpu);
+s->iomemtype = cpu_register_io_memory(a15mpcore_priv_readfn,
+ a15mpcore_priv_writefn, s,
+ DEVICE_NATIVE_ENDIAN);
+sysbus_init_mmio_cb(dev, 0x2000, a15mpcore_priv_map);
+return 0;
+}
+
+
+static SysBusDeviceInfo a15mpcore_priv_info = {
+.init = a15mpcore_priv_init,
+.qdev.name = "a15mpcore_priv",
+.qdev.size = sizeof(a15mpcore_priv_state),
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT32("num-cpu", a15mpcore_priv_state, num_cpu, 1),
+DEFINE_PROP_END_OF_LIST(),
+}
+};
+
+static void a15mpcore_register_devices(void)
+{
+sysbus_register_withprop(&a15mpcore_priv_info);
+}
+
+device_init(a15mpcore_register_devices)
+
+
+
+
diff --git a/hw/vexpress.c b/hw/vexpress.c
index 9ffd332..168819f 100644
--- a/hw/vexpress.c
+++ b/hw/vexpress.c
@@
Re: [Qemu-devel] [PATCH 06/11] hw/ac97: new support for volume control
Hi Marc-André, >>> --- hw/ac97.c | 79 + 1 files changed, 79 insertions(+), 0 deletions(-) diff --git a/hw/ac97.c b/hw/ac97.c index ba94835..4a7c4ed 100644 --- a/hw/ac97.c +++ b/hw/ac97.c @@ -431,6 +431,63 @@ static void reset_voices (AC97LinkState *s, uint8_t ; ... -- 1.7.6.2 >>> According to my test, my guest OS also can support for volume control even I don't apply the patch to my code. I run my Ubuntu guest OS via the following command: qemu-system-x86_64 -M pc --enable-kvm -m 512 -smp 1 -name Ubuntu -localtime -boot c -drive file=ubuntu.img,if=virtio,index=0 -vga cirrus -chardev stdio,id=mon0 -mon chardev=mon0,mode=readline -chardev socket,id=mon1,host=localhost,port=5554,server,nowait,telnet -mon chardev=mon1,mode=control -soundhw ac97 By the way, my host OS is also Ubuntu 11.04 and I haven't apply your patch [PATCH 04/11] and [PATCH 05/11] for hw/ac97.c to my code. Are there any problems for my test? Best Regards Wayne Gao
[Qemu-devel] When do we need to do TB unchaining?
Hi, all I am looking for when TB unchaining is needed. Currently, I can only see there are three spots (take i386-softmmu as an example): 1. cpu_interrupt: When virtual devices raise interrupts, eventually apic_local_deliver (apic.c) will call cpu_interrupt. cpu_interrupt will set up env->interrupt_request, then call cpu_unlink_tb to unlink env's TBs. Here I have a question. I though cpu_interrupt is only used in system mode to deliever virtual devices' interrupt. But it seems process mode also has cpu_interrupt. I have ran some small programs in process mode under GDB, but I never see cpu_interrupt is called. Do I have to run something bigger to see when cpu_interrupt is called in process mode? Or cpu_interrupt in process mode is only used in some rare cases? 2. cpu_exit: QEMU will register a host SIGALRM handler, host_alarm_handler (qemu-timer.c), when initialize the enviroment in system mode. Then when host OS delivers SIGALRM to QEMU, host_alarm_handler calls qemu_notify_event -> cpu_exit. cpu_exit raise env->exit_request , then call cpu_unlink_tb to unlink env's TBs. There are other places where cpu_exit is called, like - cpu_signal: I think this is used when IOTHREAD is enabled. - DMA_init: I guess cpu_exit is called when DMA is done so that control is gave back to QEMU from the code cache. - gdb_do_syscall: Don't know when it get called. - vm_stop -> cpu_stop_current: Don't know when it get called. 3. tb_phys_invalidate: QEMU will invalidate TBs related to a guest page which is done by tb_invalidate_phys_page_range (exec.c), then tb_invalidate_phys_page_range calls tb_phys_invalidate to invalidate a TB and unlink links to the TB. Please correct me if I am wrong or something miss. Thanks! Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
Re: [Qemu-devel] [PATCH] Remove line buffering from log file
On 29 September 2011 06:03, Peter Chubb wrote: > Stefan> That's the reason why line buffering is needed today. I > Stefan> enable log file output to see what happened last before the > Stefan> crash. > > Thanks for this, I didn't think of this use-case. I don't think I've > ever seen a qemu crash that wasn't caused by something really obvious. You don't need the logging for the obvious ones :-) > abort() already flushes all open streams. So only signals that cause > immediate death are a problem: SIGSEGV is the obvious one. If its > handler called abort() then that would flush too. abort() is > guaranteed by the POSIX spec to be callable from a signal handler. Catching SIGSEGV is likely to interact badly with the signal handling in linux-user mode, I expect. > Stefan> Speed is not the primary target when somebody runs qemu -d ... > > It is if it takes hours to reach the problem that causes > the abort(). Speeding up by an order of magnitude is worth it. One tactic I've found useful in these cases is to run without logging up to nearly the point where things fail, and then do a savevm. Then you can loadvm on a qemu with logging enabled and only look at the section of execution that causes the problem. -- PMM
[Qemu-devel] Bug in helper_pcmpestrm and helper_pcmpistrm
Hi,
the two functions helper_pcmpestrm() and helper_pcmpistrm() in
target-i386/ops_sse.h contain obviously typos. I think that at
all 4 marked places should increment the index 'i', not decrement
it during the loop:
void glue(helper_pcmpestrm, SUFFIX) (Reg *d, Reg *s, uint32_t ctrl)
{
int i;
unsigned int res = pcmpxstrx(d, s, ctrl,
pcmp_elen(R_EDX, ctrl),
pcmp_elen(R_EAX, ctrl));
if ((ctrl >> 6) & 1) {
if (ctrl & 1)
for (i = 0; i <= 8; i--, res >>= 1)
^^^
d->W(i) = (res & 1) ? ~0 : 0;
else
for (i = 0; i <= 16; i--, res >>= 1)
d->B(i) = (res & 1) ? ~0 : 0;
} else {
d->Q(1) = 0;
d->Q(0) = res;
}
}
void glue(helper_pcmpistrm, SUFFIX) (Reg *d, Reg *s, uint32_t ctrl)
{
int i;
unsigned int res = pcmpxstrx(d, s, ctrl,
pcmp_ilen(s, ctrl),
pcmp_ilen(d, ctrl));
if ((ctrl >> 6) & 1) {
if (ctrl & 1)
for (i = 0; i <= 8; i--, res >>= 1)
^^^
d->W(i) = (res & 1) ? ~0 : 0;
else
for (i = 0; i <= 16; i--, res >>= 1)
d->B(i) = (res & 1) ? ~0 : 0;
} else {
d->Q(1) = 0;
d->Q(0) = res;
}
}
Kind regards,
Frank
--
Dr.-Ing. Frank Mehnert
Senior Manager Software Development Desktop Virtualization, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
signature.asc
Description: This is a digitally signed message part.
Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI
On Wed, Sep 21, 2011 at 07:37:55PM +1000, Ronnie Sahlberg wrote: > This provides built-in support for iSCSI to QEMU. > This has the advantage that the iSCSI devices need not be made visible to the > host, which is useful if you have very many virtual machines and very many > iscsi devices. > It also has the benefit that non-root users of QEMU can access iSCSI devices > across the network without requiring root privilege on the host. > > This driver interfaces with the multiplatform posix library for iscsi > initiator/client access to iscsi devices hosted at > git://github.com/sahlberg/libiscsi.git > > The patch adds the driver to interface with the iscsi library. > It also updated the configure script to > * by default, probe is libiscsi is available and if so, build > qemu against libiscsi. > * --enable-libiscsi > Force a build against libiscsi. If libiscsi is not available > the build will fail. > * --disable-libiscsi > Do not link against libiscsi, even if it is available. > > When linked with libiscsi, qemu gains support to access iscsi resources such > as disks and cdrom directly, without having to make the devices visible to > the host. > > You can specify devices using a iscsi url of the form : > iscsi://[[:@]][:/ > When using authentication, the password can optionally be set with > LIBISCSI_CHAP_PASSWORD="password" to avoid it showing up in the process list > > Signed-off-by: Ronnie Sahlberg > --- > Makefile.objs |1 + > block/iscsi.c | 596 > + > configure | 31 +++ > trace-events |7 + > 4 files changed, 635 insertions(+), 0 deletions(-) > create mode 100644 block/iscsi.c Reviewed-by: Stefan Hajnoczi
Re: [Qemu-devel] boot fail!
Your description might be too simple. . On Thu, Sep 29, 2011 at 5:00 AM, shbi shb wrote: > Hi, > > > I got a snapshot from my guest Windows but I cannot load it again and my > qcow2 image cannot be loaded again (Boot fail error!). > Could you please help me bout this problem? > > > Thank you > -- Regards, Donald Wang
Re: [Qemu-devel] [PATCH] [ARM] Fix sp804 dual-timer
On 29 September 2011 03:34, Peter Chubb wrote:
> -/* ??? Don't know the PrimeCell ID for this device. */
> if (offset < 0x20) {
> return arm_timer_read(s->timer[0], offset);
> -} else {
> +}
> +if (offset < 0x40) {
> return arm_timer_read(s->timer[1], offset - 0x20);
> }
if (offset < 0x20) {..} else if (offset < 0x40) {..}
would be consistent with what you did in the write function.
> + /* Timer Peripheral ID Registers, one byte per word:
> + * [11:0] - Part number = 0x804
> + * [19:12] - Designer Id = 0x41 ('A')
> + * [23:20] - Revision = 1
> + * [31:24] - Configurations = 0
> + */
> + case 0xfe0: /* TimerPeriphID0 */
> + return 0x04;
> + case 0xfe4: /* TimerPeriphID1 */
> + return 0x18;
> + case 0xfe8: /* TimerPeriphID2 */
> + return 0x14;
> + case 0xfec: /* TimerPeriphID3 */
> + return 0x00;
[etc]
It's neater to do the 8 ID registers with an array, as the other
pl* devices do -- look at hw/pl061.c:pl061_read() for an example.
> + cpu_abort (cpu_single_env, "sp804_read: Bad offset %x\n",
> + (int)offset);
Don't cpu_abort() for something a malicious guest can trigger.
(Yes, we do this in some other devices at the moment, but we
shouldn't be introducing new instances of the problem.)
Maybe we should update the comment that says "docs for
this device don't seem to be available"...
-- PMM
[Qemu-devel] balloon drivers missing in virtio-win-1.1.16.vfd
virtio_balloon drivers are missing in the virtio-win floppy disk image found at http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ whereas they are present in the ISO image , any specific reason for this ? Shouldn't they be ideally present ? Regards, Onkar
Re: [Qemu-devel] [PATCH] pseries: Update SLOF firmware image
On 09/29/2011 06:19 AM, David Gibson wrote: This patch updates the SLOF submodule and recompiled image. The new SLOF versions contains two changes of note: * The previous SLOF has a bug in SCSI condition handling that was exposed by recent updates to qemu's SCSI emulation. This update fixes the bug. * The previous SLOF has a bug in its addressing of SCSI devices, which can be exposed under certain conditions. The new SLOF also fixes this. Did you really fix this? The SLOF.bin file here seems to be the same as in patch 50/58 from Alex's pull request, and the submodule likewise does not contain this fix. Neither does your SLOF upstream repo, in fact. :) Also, you're not updating pc-bios/README. Paolo
[Qemu-devel] [PATCH] Ensure an error is reported to user if 9pfs mount tag is too long
From: "Daniel P. Berrange"
If the 9pfs mount tag is longer than MAX_TAG_LEN bytes, rather than
silently truncating the tag which will likely break the guest OS,
report an immediate error and exit QEMU
* hw/9pfs/virtio-9p-device.c: Report error & exit if mount tag is
too long
Signed-off-by: Daniel P. Berrange
---
hw/9pfs/virtio-9p-device.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 97f2da5..8ca38d3 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -117,7 +117,9 @@ VirtIODevice *virtio_9p_init(DeviceState *dev, V9fsConf
*conf)
s->ctx.fs_root = g_strdup(fse->path);
len = strlen(conf->tag);
if (len > MAX_TAG_LEN) {
-len = MAX_TAG_LEN;
+ fprintf(stderr, "mount tag '%s' (%d bytes) is longer than maximum (%d
bytes)",
+ conf->tag, len, MAX_TAG_LEN);
+ exit(1);
}
/* s->tag is non-NULL terminated string */
s->tag = g_malloc(len);
--
1.7.6.2
[Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes
From: "Daniel P. Berrange" The Linux guest kernel does not appear to have a problem handling a mount_tag larger than 32 bytes. Increase the limit to 255 bytes, though perhaps it can be made larger still, or not limited at all ? Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length. * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255 Signed-off-by: Daniel P. Berrange --- hw/9pfs/virtio-9p.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h index 17d44b4..b133b33 100644 --- a/hw/9pfs/virtio-9p.h +++ b/hw/9pfs/virtio-9p.h @@ -144,7 +144,7 @@ struct V9fsPDU /* The ID for virtio console */ #define VIRTIO_ID_9P9 #define MAX_REQ 128 -#define MAX_TAG_LEN 32 +#define MAX_TAG_LEN 255 #define BUG_ON(cond) assert(!(cond)) -- 1.7.6.2
[Qemu-devel] [PATCH v2] tcg-i386: Introduce limited deposit support
x86 cannot provide an optimized generic deposit implementation. But at
least for a few special cases, namely for writing bits 0..7, 8..15, and
0..15, versions using only a single instruction are feasible.
Introducing such limited support improves emulating 16-bit x86 code on
x86, but also rarer cases where 32-bit or 64-bit code accesses bytes or
words.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- introduce restricting predicates TCG_TARGET_deposit_i32/64_valid
to decide if deposit support can be used
- express register constraints via new 'Q' symbol
tcg/i386/tcg-target.c | 24
tcg/i386/tcg-target.h |9 +++--
tcg/tcg-op.h |4 ++--
3 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index 281f87d..3069e53 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -168,6 +168,10 @@ static int target_parse_constraint(TCGArgConstraint *ct,
const char **pct_str)
tcg_regset_set32(ct->u.regs, 0, 0xf);
}
break;
+case 'Q':
+ct->ct |= TCG_CT_REG;
+tcg_regset_set32(ct->u.regs, 0, 0xf);
+break;
case 'r':
ct->ct |= TCG_CT_REG;
if (TCG_TARGET_REG_BITS == 64) {
@@ -1747,6 +1751,22 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
break;
#endif
+OP_32_64(deposit):
+if (args[3] == 0 && args[4] == 8) {
+/* load bits 0..7 */
+tcg_out_modrm(s, OPC_MOVB_EvGv | P_REXB_R | P_REXB_RM,
+ args[2], args[0]);
+} else if (args[3] == 8 && args[4] == 8) {
+/* load bits 8..15 */
+tcg_out_modrm(s, OPC_MOVB_EvGv, args[2], args[0] + 4);
+} else if (args[3] == 0 && args[4] == 16) {
+/* load bits 0..15 */
+tcg_out_modrm(s, OPC_MOVL_EvGv | P_DATA16, args[2], args[0]);
+} else {
+tcg_abort();
+}
+break;
+
default:
tcg_abort();
}
@@ -1802,6 +1822,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_setcond_i32, { "q", "r", "ri" } },
+{ INDEX_op_deposit_i32, { "Q", "0", "Q" } },
+
#if TCG_TARGET_REG_BITS == 32
{ INDEX_op_mulu2_i32, { "a", "d", "a", "r" } },
{ INDEX_op_add2_i32, { "r", "r", "0", "1", "ri", "ri" } },
@@ -1853,6 +1875,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_ext8u_i64, { "r", "r" } },
{ INDEX_op_ext16u_i64, { "r", "r" } },
{ INDEX_op_ext32u_i64, { "r", "r" } },
+
+{ INDEX_op_deposit_i64, { "Q", "0", "Q" } },
#endif
#if TCG_TARGET_REG_BITS == 64
diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
index 5088e47..b9c9d4e 100644
--- a/tcg/i386/tcg-target.h
+++ b/tcg/i386/tcg-target.h
@@ -90,7 +90,7 @@ enum {
#define TCG_TARGET_HAS_eqv_i32 0
#define TCG_TARGET_HAS_nand_i32 0
#define TCG_TARGET_HAS_nor_i32 0
-#define TCG_TARGET_HAS_deposit_i32 0
+#define TCG_TARGET_HAS_deposit_i32 1
#if TCG_TARGET_REG_BITS == 64
#define TCG_TARGET_HAS_div2_i64 1
@@ -111,9 +111,14 @@ enum {
#define TCG_TARGET_HAS_eqv_i64 0
#define TCG_TARGET_HAS_nand_i64 0
#define TCG_TARGET_HAS_nor_i64 0
-#define TCG_TARGET_HAS_deposit_i64 0
+#define TCG_TARGET_HAS_deposit_i64 1
#endif
+#define TCG_TARGET_deposit_i32_valid(ofs, len) \
+(((ofs) == 0 && (len) == 8) || ((ofs) == 8 && (len) == 8) || \
+ ((ofs) == 0 && (len) == 16))
+#define TCG_TARGET_deposit_i64_validTCG_TARGET_deposit_i32_valid
+
#define TCG_TARGET_HAS_GUEST_BASE
/* Note: must be synced with dyngen-exec.h */
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index 404b637..fea5983 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -2045,7 +2045,7 @@ static inline void tcg_gen_deposit_i32(TCGv_i32 ret,
TCGv_i32 arg1,
TCGv_i32 arg2, unsigned int ofs,
unsigned int len)
{
-if (TCG_TARGET_HAS_deposit_i32) {
+if (TCG_TARGET_HAS_deposit_i32 && TCG_TARGET_deposit_i32_valid(ofs, len)) {
tcg_gen_op5ii_i32(INDEX_op_deposit_i32, ret, arg1, arg2, ofs, len);
} else {
uint32_t mask = (1u << len) - 1;
@@ -2064,7 +2064,7 @@ static inline void tcg_gen_deposit_i64(TCGv_i64 ret,
TCGv_i64 arg1,
TCGv_i64 arg2, unsigned int ofs,
unsigned int len)
{
-if (TCG_TARGET_HAS_deposit_i64) {
+if (TCG_TARGET_HAS_deposit_i64 && TCG_TARGET_deposit_i64_valid(ofs, len)) {
tcg_gen_op5ii_i64(INDEX_op_deposit_i64, ret, arg1, arg2, ofs, len);
} else {
uint64_t mask = (1ull << len) - 1;
--
1.7.3.4
[Qemu-devel] [RFC PATCH] Introduce tracing for 9p pdu handlers
Plan is to replace the existing debug infrastructure with Qemu tracing
infrastructure so that user can dynamically enable/disable trace events and
therefore a meaningful trace log can be generated which can be further
filtered using analysis script.
Note: Because of current simpletrace limitations, the trace events are
logging at max 6 args, however, once the more args are supported, we can
change trace events to log more info as well. Also, This initial patch only
provides a replacement for existing debug infra. More trace events to be
added later for newly added handlers and sub-routines.
Signed-off-by: Harsh Prateek Bora
---
hw/9pfs/virtio-9p.c | 62 +++
trace-events| 47 ++
2 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 1d1933f..6ee498f 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -20,6 +20,7 @@
#include "virtio-9p-debug.h"
#include "virtio-9p-xattr.h"
#include "virtio-9p-coth.h"
+#include "trace.h"
int debug_9p_pdu;
int open_fd_hw;
@@ -977,6 +978,7 @@ static void complete_pdu(V9fsState *s, V9fsPDU *pdu,
ssize_t len)
if (s->proto_version == V9FS_PROTO_2000L) {
id = P9_RLERROR;
}
+trace_complete_pdu(pdu->tag, pdu->id, id); /* Trace ERROR */
}
/* fill out the header */
@@ -1286,6 +1288,7 @@ static void v9fs_version(void *opaque)
size_t offset = 7;
pdu_unmarshal(pdu, offset, "ds", &s->msize, &version);
+trace_v9fs_version1(pdu->tag, pdu->id, s->msize, version.data);
if (!strcmp(version.data, "9P2000.u")) {
s->proto_version = V9FS_PROTO_2000U;
@@ -1296,6 +1299,8 @@ static void v9fs_version(void *opaque)
}
offset += pdu_marshal(pdu, offset, "ds", s->msize, &version);
+trace_v9fs_version2(pdu->tag, pdu->id, s->msize, version.data);
+
complete_pdu(s, pdu, offset);
v9fs_string_free(&version);
@@ -1314,6 +1319,7 @@ static void v9fs_attach(void *opaque)
ssize_t err;
pdu_unmarshal(pdu, offset, "ddssd", &fid, &afid, &uname, &aname, &n_uname);
+trace_v9fs_attach1(pdu->tag, pdu->id, fid, afid, uname.data, aname.data);
fidp = alloc_fid(s, fid);
if (fidp == NULL) {
@@ -1338,6 +1344,7 @@ static void v9fs_attach(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_attach2(pdu->tag, pdu->id, qid.type, qid.version, qid.path);
complete_pdu(s, pdu, err);
v9fs_string_free(&uname);
v9fs_string_free(&aname);
@@ -1355,6 +1362,7 @@ static void v9fs_stat(void *opaque)
V9fsState *s = pdu->s;
pdu_unmarshal(pdu, offset, "d", &fid);
+trace_v9fs_stat1(pdu->tag, pdu->id, fid);
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
@@ -1375,6 +1383,8 @@ static void v9fs_stat(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_stat2(pdu->tag, pdu->id, v9stat.mode, v9stat.atime,
v9stat.mtime, v9stat.length);
+
complete_pdu(s, pdu, err);
}
@@ -1391,6 +1401,7 @@ static void v9fs_getattr(void *opaque)
V9fsState *s = pdu->s;
pdu_unmarshal(pdu, offset, "dq", &fid, &request_mask);
+trace_v9fs_getattr1(pdu->tag, pdu->id, fid, request_mask);
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
@@ -1420,6 +1431,10 @@ static void v9fs_getattr(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_getattr2(pdu->tag, pdu->id, v9stat_dotl.st_result_mask,
+ v9stat_dotl.st_mode, v9stat_dotl.st_uid,
+ v9stat_dotl.st_gid);
+
complete_pdu(s, pdu, retval);
}
@@ -1547,6 +1562,8 @@ static void v9fs_walk(void *opaque)
offset += pdu_unmarshal(pdu, offset, "ddw", &fid,
&newfid, &nwnames);
+trace_v9fs_walk1(pdu->tag, pdu->id, fid, newfid, nwnames);
+
if (nwnames && nwnames <= P9_MAXWELEM) {
wnames = g_malloc0(sizeof(wnames[0]) * nwnames);
qids = g_malloc0(sizeof(qids[0]) * nwnames);
@@ -1603,6 +1620,7 @@ out:
v9fs_path_free(&dpath);
v9fs_path_free(&path);
out_nofid:
+trace_v9fs_walk2(pdu->tag, pdu->id, nwnames, qids);
complete_pdu(s, pdu, err);
if (nwnames && nwnames <= P9_MAXWELEM) {
for (name_idx = 0; name_idx < nwnames; name_idx++) {
@@ -1653,6 +1671,8 @@ static void v9fs_open(void *opaque)
} else {
pdu_unmarshal(pdu, offset, "db", &fid, &mode);
}
+trace_v9fs_open1(pdu->tag, pdu->id, fid, mode);
+
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
err = -ENOENT;
@@ -1699,6 +1719,7 @@ static void v9fs_open(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_open2(pdu->tag, pdu->id, qid.type, qid.version, qid.path,
iounit);
complete_pdu(s, pdu, err);
}
@@ -1717,6 +1738,7 @@ static void v9fs_lcreate(void *opaque)
pdu_unmarshal(pdu, offset, "dsddd", &dfid, &name, &flags,
&mode, &
[Qemu-devel] [PATCH 2/2] Remove virtio-9p-debug.* infra since we are using Qemu Tracing now.
Removing the existing debug infrastrucure as proposed to be replaced by
Qemu Tracing infrastructure.
Signed-off-by: Harsh Prateek Bora
---
Makefile.objs |2 +-
hw/9pfs/virtio-9p-debug.c | 646 -
hw/9pfs/virtio-9p-debug.h |6 -
hw/9pfs/virtio-9p.c |8 -
4 files changed, 1 insertions(+), 661 deletions(-)
delete mode 100644 hw/9pfs/virtio-9p-debug.c
delete mode 100644 hw/9pfs/virtio-9p-debug.h
diff --git a/Makefile.objs b/Makefile.objs
index 4a76acc..b14a417 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -304,7 +304,7 @@ sound-obj-$(CONFIG_HDA) += intel-hda.o hda-audio.o
adlib.o fmopl.o: QEMU_CFLAGS += -DBUILD_Y8950=0
hw-obj-$(CONFIG_SOUND) += $(sound-obj-y)
-9pfs-nested-$(CONFIG_VIRTFS) = virtio-9p.o virtio-9p-debug.o
+9pfs-nested-$(CONFIG_VIRTFS) = virtio-9p.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-local.o virtio-9p-xattr.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-xattr-user.o virtio-9p-posix-acl.o
9pfs-nested-$(CONFIG_VIRTFS) += virtio-9p-coth.o cofs.o codir.o cofile.o
diff --git a/hw/9pfs/virtio-9p-debug.c b/hw/9pfs/virtio-9p-debug.c
deleted file mode 100644
index 96925f0..000
--- a/hw/9pfs/virtio-9p-debug.c
+++ /dev/null
@@ -1,646 +0,0 @@
-/*
- * Virtio 9p PDU debug
- *
- * Copyright IBM, Corp. 2010
- *
- * Authors:
- * Anthony Liguori
- *
- * This work is licensed under the terms of the GNU GPL, version 2. See
- * the COPYING file in the top-level directory.
- *
- */
-
-#include "hw/virtio.h"
-#include "hw/pc.h"
-#include "virtio-9p.h"
-#include "virtio-9p-debug.h"
-
-#define BUG_ON(cond) assert(!(cond))
-
-static FILE *llogfile;
-
-static struct iovec *get_sg(V9fsPDU *pdu, int rx)
-{
-if (rx) {
-return pdu->elem.in_sg;
-}
-return pdu->elem.out_sg;
-}
-
-static int get_sg_count(V9fsPDU *pdu, int rx)
-{
-if (rx) {
-return pdu->elem.in_num;
-}
-return pdu->elem.out_num;
-
-}
-
-static void pprint_int8(V9fsPDU *pdu, int rx, size_t *offsetp,
-const char *name)
-{
-size_t copied;
-int count = get_sg_count(pdu, rx);
-size_t offset = *offsetp;
-struct iovec *sg = get_sg(pdu, rx);
-int8_t value;
-
-copied = do_pdu_unpack(&value, sg, count, offset, sizeof(value));
-
-BUG_ON(copied != sizeof(value));
-offset += sizeof(value);
-fprintf(llogfile, "%s=0x%x", name, value);
-*offsetp = offset;
-}
-
-static void pprint_int16(V9fsPDU *pdu, int rx, size_t *offsetp,
-const char *name)
-{
-size_t copied;
-int count = get_sg_count(pdu, rx);
-struct iovec *sg = get_sg(pdu, rx);
-size_t offset = *offsetp;
-int16_t value;
-
-
-copied = do_pdu_unpack(&value, sg, count, offset, sizeof(value));
-
-BUG_ON(copied != sizeof(value));
-offset += sizeof(value);
-fprintf(llogfile, "%s=0x%x", name, value);
-*offsetp = offset;
-}
-
-static void pprint_int32(V9fsPDU *pdu, int rx, size_t *offsetp,
-const char *name)
-{
-size_t copied;
-int count = get_sg_count(pdu, rx);
-struct iovec *sg = get_sg(pdu, rx);
-size_t offset = *offsetp;
-int32_t value;
-
-
-copied = do_pdu_unpack(&value, sg, count, offset, sizeof(value));
-
-BUG_ON(copied != sizeof(value));
-offset += sizeof(value);
-fprintf(llogfile, "%s=0x%x", name, value);
-*offsetp = offset;
-}
-
-static void pprint_int64(V9fsPDU *pdu, int rx, size_t *offsetp,
-const char *name)
-{
-size_t copied;
-int count = get_sg_count(pdu, rx);
-struct iovec *sg = get_sg(pdu, rx);
-size_t offset = *offsetp;
-int64_t value;
-
-
-copied = do_pdu_unpack(&value, sg, count, offset, sizeof(value));
-
-BUG_ON(copied != sizeof(value));
-offset += sizeof(value);
-fprintf(llogfile, "%s=0x%" PRIx64, name, value);
-*offsetp = offset;
-}
-
-static void pprint_str(V9fsPDU *pdu, int rx, size_t *offsetp, const char *name)
-{
-int sg_count = get_sg_count(pdu, rx);
-struct iovec *sg = get_sg(pdu, rx);
-size_t offset = *offsetp;
-uint16_t tmp_size, size;
-size_t result;
-size_t copied = 0;
-int i = 0;
-
-/* get the size */
-copied = do_pdu_unpack(&tmp_size, sg, sg_count, offset, sizeof(tmp_size));
-BUG_ON(copied != sizeof(tmp_size));
-size = le16_to_cpupu(&tmp_size);
-offset += copied;
-
-fprintf(llogfile, "%s=", name);
-for (i = 0; size && i < sg_count; i++) {
-size_t len;
-if (offset >= sg[i].iov_len) {
-/* skip this sg */
-offset -= sg[i].iov_len;
-continue;
-} else {
-len = MIN(sg[i].iov_len - offset, size);
-result = fwrite(sg[i].iov_base + offset, 1, len, llogfile);
-BUG_ON(result != len);
-size -= len;
-copied += len;
-if (size) {
-offset = 0;
-continue;
-}
-}
-}
-*offsetp +=
[Qemu-devel] [PATCH 1/2] Introduce tracing for 9p pdu handlers
Plan is to replace the existing debug infrastructure with Qemu tracing
infrastructure so that user can dynamically enable/disable trace events and
therefore a meaningful trace log can be generated which can be further
filtered using analysis script.
Note: Because of current simpletrace limitations, the trace events are
logging at max 6 args, however, once the more args are supported, we can
change trace events to log more info as well. Also, This initial patch only
provides a replacement for existing debug infra. More trace events to be
added later for newly added handlers and sub-routines.
Signed-off-by: Harsh Prateek Bora
---
hw/9pfs/virtio-9p.c | 62 +++
trace-events| 47 ++
2 files changed, 109 insertions(+), 0 deletions(-)
diff --git a/hw/9pfs/virtio-9p.c b/hw/9pfs/virtio-9p.c
index 1d1933f..6ee498f 100644
--- a/hw/9pfs/virtio-9p.c
+++ b/hw/9pfs/virtio-9p.c
@@ -20,6 +20,7 @@
#include "virtio-9p-debug.h"
#include "virtio-9p-xattr.h"
#include "virtio-9p-coth.h"
+#include "trace.h"
int debug_9p_pdu;
int open_fd_hw;
@@ -977,6 +978,7 @@ static void complete_pdu(V9fsState *s, V9fsPDU *pdu,
ssize_t len)
if (s->proto_version == V9FS_PROTO_2000L) {
id = P9_RLERROR;
}
+trace_complete_pdu(pdu->tag, pdu->id, id); /* Trace ERROR */
}
/* fill out the header */
@@ -1286,6 +1288,7 @@ static void v9fs_version(void *opaque)
size_t offset = 7;
pdu_unmarshal(pdu, offset, "ds", &s->msize, &version);
+trace_v9fs_version1(pdu->tag, pdu->id, s->msize, version.data);
if (!strcmp(version.data, "9P2000.u")) {
s->proto_version = V9FS_PROTO_2000U;
@@ -1296,6 +1299,8 @@ static void v9fs_version(void *opaque)
}
offset += pdu_marshal(pdu, offset, "ds", s->msize, &version);
+trace_v9fs_version2(pdu->tag, pdu->id, s->msize, version.data);
+
complete_pdu(s, pdu, offset);
v9fs_string_free(&version);
@@ -1314,6 +1319,7 @@ static void v9fs_attach(void *opaque)
ssize_t err;
pdu_unmarshal(pdu, offset, "ddssd", &fid, &afid, &uname, &aname, &n_uname);
+trace_v9fs_attach1(pdu->tag, pdu->id, fid, afid, uname.data, aname.data);
fidp = alloc_fid(s, fid);
if (fidp == NULL) {
@@ -1338,6 +1344,7 @@ static void v9fs_attach(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_attach2(pdu->tag, pdu->id, qid.type, qid.version, qid.path);
complete_pdu(s, pdu, err);
v9fs_string_free(&uname);
v9fs_string_free(&aname);
@@ -1355,6 +1362,7 @@ static void v9fs_stat(void *opaque)
V9fsState *s = pdu->s;
pdu_unmarshal(pdu, offset, "d", &fid);
+trace_v9fs_stat1(pdu->tag, pdu->id, fid);
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
@@ -1375,6 +1383,8 @@ static void v9fs_stat(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_stat2(pdu->tag, pdu->id, v9stat.mode, v9stat.atime,
v9stat.mtime, v9stat.length);
+
complete_pdu(s, pdu, err);
}
@@ -1391,6 +1401,7 @@ static void v9fs_getattr(void *opaque)
V9fsState *s = pdu->s;
pdu_unmarshal(pdu, offset, "dq", &fid, &request_mask);
+trace_v9fs_getattr1(pdu->tag, pdu->id, fid, request_mask);
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
@@ -1420,6 +1431,10 @@ static void v9fs_getattr(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_getattr2(pdu->tag, pdu->id, v9stat_dotl.st_result_mask,
+ v9stat_dotl.st_mode, v9stat_dotl.st_uid,
+ v9stat_dotl.st_gid);
+
complete_pdu(s, pdu, retval);
}
@@ -1547,6 +1562,8 @@ static void v9fs_walk(void *opaque)
offset += pdu_unmarshal(pdu, offset, "ddw", &fid,
&newfid, &nwnames);
+trace_v9fs_walk1(pdu->tag, pdu->id, fid, newfid, nwnames);
+
if (nwnames && nwnames <= P9_MAXWELEM) {
wnames = g_malloc0(sizeof(wnames[0]) * nwnames);
qids = g_malloc0(sizeof(qids[0]) * nwnames);
@@ -1603,6 +1620,7 @@ out:
v9fs_path_free(&dpath);
v9fs_path_free(&path);
out_nofid:
+trace_v9fs_walk2(pdu->tag, pdu->id, nwnames, qids);
complete_pdu(s, pdu, err);
if (nwnames && nwnames <= P9_MAXWELEM) {
for (name_idx = 0; name_idx < nwnames; name_idx++) {
@@ -1653,6 +1671,8 @@ static void v9fs_open(void *opaque)
} else {
pdu_unmarshal(pdu, offset, "db", &fid, &mode);
}
+trace_v9fs_open1(pdu->tag, pdu->id, fid, mode);
+
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
err = -ENOENT;
@@ -1699,6 +1719,7 @@ static void v9fs_open(void *opaque)
out:
put_fid(pdu, fidp);
out_nofid:
+trace_v9fs_open2(pdu->tag, pdu->id, qid.type, qid.version, qid.path,
iounit);
complete_pdu(s, pdu, err);
}
@@ -1717,6 +1738,7 @@ static void v9fs_lcreate(void *opaque)
pdu_unmarshal(pdu, offset, "dsddd", &dfid, &name, &flags,
&mode, &
[Qemu-devel] [RFC PATCH 0/2] Replace 9p debug infrastructure with Qemu Tracing
This patchset introduces Qemu Tracing to 9p pdu handlers and removes the existing debug infrastructure which becomes less meaningful after the introduction of coroutines. Parallel operations creates a messy output and filtering becomes difficult. With Qemu tracing in place, we can selectively enable/disable trace-events and the trace log can be further filtered using analysis scripts. Harsh Prateek Bora (2): Introduce tracing for 9p pdu handlers Remove virtio-9p-debug.* infra since we are using Qemu Tracing now. Makefile.objs |2 +- hw/9pfs/virtio-9p-debug.c | 646 - hw/9pfs/virtio-9p-debug.h |6 - hw/9pfs/virtio-9p.c | 70 +- trace-events | 47 5 files changed, 110 insertions(+), 661 deletions(-) delete mode 100644 hw/9pfs/virtio-9p-debug.c delete mode 100644 hw/9pfs/virtio-9p-debug.h
Re: [Qemu-devel] [PATCH 06/21] qapi: dealloc visitor, fix premature free and iteration logic
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
From: Michael Roth
Currently we do 3 things wrong:
1) The list iterator, in practice, is used in a manner where the pointer
we pass in is the same as the pointer we assign the output to from
visit_next_list(). This causes an infinite loop where we keep freeing
the same structures.
2) We attempt to free list->value rather than list. visit_type_
handles this. We should only be concerned with the containing list.
3) We free prematurely: iterator function will continue accessing values
we've already freed.
This patch should fix all of these issues. QmpOutputVisitor also suffers
from 1).
Signed-off-by: Michael Roth
Signed-off-by: Luiz Capitulino
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
---
qapi/qapi-dealloc-visitor.c | 20 +++-
1 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visitor.c
index f629061..6b586ad 100644
--- a/qapi/qapi-dealloc-visitor.c
+++ b/qapi/qapi-dealloc-visitor.c
@@ -26,6 +26,7 @@ struct QapiDeallocVisitor
{
Visitor visitor;
QTAILQ_HEAD(, StackEntry) stack;
+bool is_list_head;
};
static QapiDeallocVisitor *to_qov(Visitor *v)
@@ -70,15 +71,24 @@ static void qapi_dealloc_end_struct(Visitor *v, Error
**errp)
static void qapi_dealloc_start_list(Visitor *v, const char *name, Error
**errp)
{
+QapiDeallocVisitor *qov = to_qov(v);
+qov->is_list_head = true;
}
-static GenericList *qapi_dealloc_next_list(Visitor *v, GenericList **list,
+static GenericList *qapi_dealloc_next_list(Visitor *v, GenericList **listp,
Error **errp)
{
-GenericList *retval = *list;
-g_free(retval->value);
-*list = retval->next;
-return retval;
+GenericList *list = *listp;
+QapiDeallocVisitor *qov = to_qov(v);
+
+if (!qov->is_list_head) {
+*listp = list->next;
+g_free(list);
+return *listp;
+}
+
+qov->is_list_head = false;
+return list;
}
static void qapi_dealloc_end_list(Visitor *v, Error **errp)
Re: [Qemu-devel] [PATCH 08/21] qapi: add test cases for generated free functions
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
From: Michael Roth
Signed-off-by: Michael Roth
Signed-off-by: Luiz Capitulino
---
test-qmp-commands.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/test-qmp-commands.c b/test-qmp-commands.c
index f142cc6..7db38b6 100644
--- a/test-qmp-commands.c
+++ b/test-qmp-commands.c
@@ -98,6 +98,34 @@ static void test_dispatch_cmd_io(void)
QDECREF(req);
}
+/* test generated dealloc functions for generated types */
+static void test_dealloc_types(void)
+{
+UserDefOne *ud1test, *ud1a, *ud1b;
+UserDefOneList *ud1list;
+
+ud1test = g_malloc0(sizeof(UserDefOne));
+ud1test->integer = 42;
+ud1test->string = strdup("hi there 42");
+
+qapi_free_UserDefOne(ud1test);
+
+ud1a = g_malloc0(sizeof(UserDefOne));
+ud1a->integer = 43;
+ud1a->string = strdup("hi there 43");
+
+ud1b = g_malloc0(sizeof(UserDefOne));
+ud1b->integer = 44;
+ud1b->string = strdup("hi there 44");
Minor nit: this should be g_strdup.
Regards,
Anthony Liguori
+
+ud1list = g_malloc0(sizeof(UserDefOneList));
+ud1list->value = ud1a;
+ud1list->next = g_malloc0(sizeof(UserDefOneList));
+ud1list->next->value = ud1b;
+
+qapi_free_UserDefOneList(ud1list);
+}
+
int main(int argc, char **argv)
{
g_test_init(&argc,&argv, NULL);
@@ -105,6 +133,7 @@ int main(int argc, char **argv)
g_test_add_func("/0.15/dispatch_cmd", test_dispatch_cmd);
g_test_add_func("/0.15/dispatch_cmd_error", test_dispatch_cmd_error);
g_test_add_func("/0.15/dispatch_cmd_io", test_dispatch_cmd_io);
+g_test_add_func("/0.15/dealloc_types", test_dealloc_types);
module_call_init(MODULE_INIT_QAPI);
g_test_run();
Re: [Qemu-devel] [PATCH 07/21] qapi: generate qapi_free_* functions for *List types
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
From: Michael Roth
Signed-off-by: Michael Roth
Signed-off-by: Luiz Capitulino
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
---
scripts/qapi-types.py |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index fc0f7af..4797a70 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -254,6 +254,8 @@ for expr in exprs:
ret = "\n"
if expr.has_key('type'):
ret += generate_struct(expr['type'], "", expr['data']) + "\n"
+ret += generate_type_cleanup_decl(expr['type'] + "List")
+fdef.write(generate_type_cleanup(expr['type'] + "List") + "\n")
ret += generate_type_cleanup_decl(expr['type'])
fdef.write(generate_type_cleanup(expr['type']) + "\n")
elif expr.has_key('union'):
Re: [Qemu-devel] [PATCH 09/21] qapi: dealloc visitor, support freeing of nested lists
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
From: Michael Roth
Previously our logic for keeping track of when we're visiting the head
of a list was done via a global bool. This can be overwritten if dealing
with nested lists, so use stack entries to track this instead.
Signed-off-by: Michael Roth
Signed-off-by: Luiz Capitulino
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
---
qapi/qapi-dealloc-visitor.c | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/qapi/qapi-dealloc-visitor.c b/qapi/qapi-dealloc-visitor.c
index 6b586ad..a154523 100644
--- a/qapi/qapi-dealloc-visitor.c
+++ b/qapi/qapi-dealloc-visitor.c
@@ -19,6 +19,7 @@
typedef struct StackEntry
{
void *value;
+bool is_list_head;
QTAILQ_ENTRY(StackEntry) node;
} StackEntry;
@@ -39,6 +40,11 @@ static void qapi_dealloc_push(QapiDeallocVisitor *qov, void
*value)
StackEntry *e = g_malloc0(sizeof(*e));
e->value = value;
+
+/* see if we're just pushing a list head tracker */
+if (value == NULL) {
+e->is_list_head = true;
+}
QTAILQ_INSERT_HEAD(&qov->stack, e, node);
}
@@ -72,7 +78,7 @@ static void qapi_dealloc_end_struct(Visitor *v, Error **errp)
static void qapi_dealloc_start_list(Visitor *v, const char *name, Error
**errp)
{
QapiDeallocVisitor *qov = to_qov(v);
-qov->is_list_head = true;
+qapi_dealloc_push(qov, NULL);
}
static GenericList *qapi_dealloc_next_list(Visitor *v, GenericList **listp,
@@ -80,19 +86,27 @@ static GenericList *qapi_dealloc_next_list(Visitor *v,
GenericList **listp,
{
GenericList *list = *listp;
QapiDeallocVisitor *qov = to_qov(v);
+StackEntry *e = QTAILQ_FIRST(&qov->stack);
-if (!qov->is_list_head) {
-*listp = list->next;
-g_free(list);
-return *listp;
+if (e&& e->is_list_head) {
+e->is_list_head = false;
+return list;
}
-qov->is_list_head = false;
-return list;
+if (list) {
+list = list->next;
+g_free(*listp);
+return list;
+}
+
+return NULL;
}
static void qapi_dealloc_end_list(Visitor *v, Error **errp)
{
+QapiDeallocVisitor *qov = to_qov(v);
+void *obj = qapi_dealloc_pop(qov);
+assert(obj == NULL); /* should've been list head tracker with no payload */
}
static void qapi_dealloc_type_str(Visitor *v, char **obj, const char *name,
Re: [Qemu-devel] [PATCH 10/21] qapi: modify visitor code generation for list iteration
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
From: Michael Roth
Modify logic such that we never assign values to the list head argument
to progress through the list on subsequent iterations, instead rely only
on having our return value passed back in as an argument on the next
call. Also update QMP I/O visitors and test cases accordingly, and add a
missing test case for QmpOutputVisitor.
Signed-off-by: Michael Roth
Signed-off-by: Luiz Capitulino
Reviewed-by: Anthony Liguori
Regards,
Anthony Liguori
---
qapi/qmp-input-visitor.c |4 +-
qapi/qmp-output-visitor.c | 20 +++---
scripts/qapi-visit.py |4 +-
test-visitor.c| 48 +---
4 files changed, 60 insertions(+), 16 deletions(-)
diff --git a/qapi/qmp-input-visitor.c b/qapi/qmp-input-visitor.c
index fcf8bf9..8cbc0ab 100644
--- a/qapi/qmp-input-visitor.c
+++ b/qapi/qmp-input-visitor.c
@@ -144,8 +144,6 @@ static GenericList *qmp_input_next_list(Visitor *v,
GenericList **list,
}
(*list)->next = entry;
}
-*list = entry;
-
return entry;
}
@@ -240,9 +238,11 @@ static void qmp_input_type_enum(Visitor *v, int *obj,
const char *strings[],
if (strings[value] == NULL) {
error_set(errp, QERR_INVALID_PARAMETER, name ? name : "null");
+g_free(enum_str);
return;
}
+g_free(enum_str);
*obj = value;
}
diff --git a/qapi/qmp-output-visitor.c b/qapi/qmp-output-visitor.c
index 4419a31..d67724e 100644
--- a/qapi/qmp-output-visitor.c
+++ b/qapi/qmp-output-visitor.c
@@ -20,6 +20,7 @@
typedef struct QStackEntry
{
QObject *value;
+bool is_list_head;
QTAILQ_ENTRY(QStackEntry) node;
} QStackEntry;
@@ -45,6 +46,9 @@ static void qmp_output_push_obj(QmpOutputVisitor *qov,
QObject *value)
QStackEntry *e = g_malloc0(sizeof(*e));
e->value = value;
+if (qobject_type(e->value) == QTYPE_QLIST) {
+e->is_list_head = true;
+}
QTAILQ_INSERT_HEAD(&qov->stack, e, node);
}
@@ -122,12 +126,20 @@ static void qmp_output_start_list(Visitor *v, const char
*name, Error **errp)
qmp_output_push(qov, list);
}
-static GenericList *qmp_output_next_list(Visitor *v, GenericList **list,
+static GenericList *qmp_output_next_list(Visitor *v, GenericList **listp,
Error **errp)
{
-GenericList *retval = *list;
-*list = retval->next;
-return retval;
+GenericList *list = *listp;
+QmpOutputVisitor *qov = to_qov(v);
+QStackEntry *e = QTAILQ_FIRST(&qov->stack);
+
+assert(e);
+if (e->is_list_head) {
+e->is_list_head = false;
+return list;
+}
+
+return list ? list->next : NULL;
}
static void qmp_output_end_list(Visitor *v, Error **errp)
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 252230e..62de83d 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -79,11 +79,11 @@ def generate_visit_list(name, members):
void visit_type_%(name)sList(Visitor *m, %(name)sList ** obj, const char
*name, Error **errp)
{
-GenericList *i;
+GenericList *i, **head = (GenericList **)obj;
visit_start_list(m, name, errp);
-for (i = visit_next_list(m, (GenericList **)obj, errp); i; i =
visit_next_list(m,&i, errp)) {
+for (*head = i = visit_next_list(m, head, errp); i; i =
visit_next_list(m,&i, errp)) {
%(name)sList *native_i = (%(name)sList *)i;
visit_type_%(name)s(m,&native_i->value, NULL, errp);
}
diff --git a/test-visitor.c b/test-visitor.c
index b7717de..847ce14 100644
--- a/test-visitor.c
+++ b/test-visitor.c
@@ -27,11 +27,11 @@ static void visit_type_TestStruct(Visitor *v, TestStruct
**obj, const char *name
static void visit_type_TestStructList(Visitor *m, TestStructList ** obj,
const char *name, Error **errp)
{
-GenericList *i;
+GenericList *i, **head = (GenericList **)obj;
visit_start_list(m, name, errp);
-for (i = visit_next_list(m, (GenericList **)obj, errp); i; i =
visit_next_list(m,&i, errp)) {
+for (*head = i = visit_next_list(m, head, errp); i; i =
visit_next_list(m,&i, errp)) {
TestStructList *native_i = (TestStructList *)i;
visit_type_TestStruct(m,&native_i->value, NULL, errp);
}
@@ -50,6 +50,8 @@ static void test_visitor_core(void)
TestStructList *lts = NULL;
Error *err = NULL;
QObject *obj;
+QList *qlist;
+QDict *qdict;
QString *str;
int64_t value = 0;
@@ -96,7 +98,9 @@ static void test_visitor_core(void)
g_assert(pts->y == 84);
qobject_decref(obj);
+g_free(pts);
+/* test list input visitor */
obj = qobject_from_json("[{'x': 42, 'y': 84}, {'x': 12, 'y': 24}]");
mi = qmp_input_visitor_new(obj);
v = qmp_input_get_visitor(mi);
@@ -110,14 +114,41 @@ static void test_visitor_core(void)
g_assert(lts->value->x == 42);
g_assert(lts->value->y ==
Re: [Qemu-devel] [PATCH 12/21] qapi: Convert query-version
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
The original conversion was done by Anthony Liguori. This commit
is just a rebase.
For all of the rest of the patches, you can add my Signed-off-by: before your
SoB. Then you don't need to have the disclaimer in the commit message.
Regards,
Anthony Liguori
Signed-off-by: Luiz Capitulino
---
hmp.c| 13 +
hmp.h|1 +
monitor.c| 46 +++---
qapi-schema.json | 37 +
qmp-commands.hx |6 ++
qmp.c| 16
6 files changed, 76 insertions(+), 43 deletions(-)
diff --git a/hmp.c b/hmp.c
index 47e1ff7..bb6c86f 100644
--- a/hmp.c
+++ b/hmp.c
@@ -24,3 +24,16 @@ void hmp_info_name(Monitor *mon)
}
qapi_free_NameInfo(info);
}
+
+void hmp_info_version(Monitor *mon)
+{
+VersionInfo *info;
+
+info = qmp_query_version(NULL);
+
+monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+ info->qemu.major, info->qemu.minor, info->qemu.micro,
+ info->package);
+
+qapi_free_VersionInfo(info);
+}
diff --git a/hmp.h b/hmp.h
index 5fe73f1..2aa75a2 100644
--- a/hmp.h
+++ b/hmp.h
@@ -18,5 +18,6 @@
#include "qapi-types.h"
void hmp_info_name(Monitor *mon);
+void hmp_info_version(Monitor *mon);
#endif
diff --git a/monitor.c b/monitor.c
index 8af0e27..9edc38c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -730,37 +730,6 @@ help:
help_cmd(mon, "info");
}
-static void do_info_version_print(Monitor *mon, const QObject *data)
-{
-QDict *qdict;
-QDict *qemu;
-
-qdict = qobject_to_qdict(data);
-qemu = qdict_get_qdict(qdict, "qemu");
-
-monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
- qdict_get_int(qemu, "major"),
- qdict_get_int(qemu, "minor"),
- qdict_get_int(qemu, "micro"),
- qdict_get_str(qdict, "package"));
-}
-
-static void do_info_version(Monitor *mon, QObject **ret_data)
-{
-const char *version = QEMU_VERSION;
-int major = 0, minor = 0, micro = 0;
-char *tmp;
-
-major = strtol(version,&tmp, 10);
-tmp++;
-minor = strtol(tmp,&tmp, 10);
-tmp++;
-micro = strtol(tmp,&tmp, 10);
-
-*ret_data = qobject_from_jsonf("{ 'qemu': { 'major': %d, 'minor': %d, \
-'micro': %d }, 'package': %s }", major, minor, micro, QEMU_PKGVERSION);
-}
-
static QObject *get_cmd_dict(const char *name)
{
const char *p;
@@ -2866,8 +2835,7 @@ static const mon_cmd_t info_cmds[] = {
.args_type = "",
.params = "",
.help = "show the version of QEMU",
-.user_print = do_info_version_print,
-.mhandler.info_new = do_info_version,
+.mhandler.info = hmp_info_version,
},
{
.name = "network",
@@ -3159,14 +3127,6 @@ static const mon_cmd_t qmp_cmds[] = {
static const mon_cmd_t qmp_query_cmds[] = {
{
-.name = "version",
-.args_type = "",
-.params = "",
-.help = "show the version of QEMU",
-.user_print = do_info_version_print,
-.mhandler.info_new = do_info_version,
-},
-{
.name = "commands",
.args_type = "",
.params = "",
@@ -5172,9 +5132,9 @@ void monitor_resume(Monitor *mon)
static QObject *get_qmp_greeting(void)
{
-QObject *ver;
+QObject *ver = NULL;
-do_info_version(NULL,&ver);
+qmp_marshal_input_query_version(NULL, NULL,&ver);
return qobject_from_jsonf("{'QMP':{'version': %p,'capabilities':
[]}}",ver);
}
diff --git a/qapi-schema.json b/qapi-schema.json
index 3585324..3c0ac4e 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -23,3 +23,40 @@
# Since 0.14.0
##
{ 'command': 'query-name', 'returns': 'NameInfo' }
+
+##
+# @VersionInfo:
+#
+# A description of QEMU's version.
+#
+# @qemu.major: The major version of QEMU
+#
+# @qemu.minor: The minor version of QEMU
+#
+# @qemu.micro: The micro version of QEMU. By current convention, a micro
+# version of 50 signifies a development branch. A micro version
+# greater than or equal to 90 signifies a release candidate for
+# the next minor version. A micro version of less than 50
+# signifies a stable release.
+#
+# @package: QEMU will always set this field to an empty string. Downstream
+# versions of QEMU should set this to a non-empty string. The
+# exact format depends on the downstream however it highly
+# recommended that a unique name is used.
+#
+# Since: 0.14.0
+##
+{ 'type': 'VersionInfo',
+ 'data': {'qemu': {'major': 'int', 'minor': 'int', 'micro': 'int'},
+ 'package': 'str'} }
+
+##
+# @query-version:
+#
+# Returns the current version of QEMU.
+#
+# Returns: A @VersionInfo object describing the cur
Re: [Qemu-devel] [PATCH v1 00/21]: First round of QAPI conversions
On 09/28/2011 09:44 AM, Luiz Capitulino wrote: This series is a bundle of three things: 1. Patches 01 to 04 add the middle mode feature to the current QMP server. That mode allows for the current server to support QAPI commands. The Original author is Anthony, you can find his original post here: http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00374.html 2. Patches 05 to 10 are fixes from Anthony and Michael to the QAPI handling of the list type. 3. Patches 11 to 21 are simple monitor commands conversions to the QAPI. This is just a rebase of a previous conversion work by Anthony. Great series! Other than the one minor comment re: strdup and commit messages, I think it's ready to go. Regards, Anthony Liguori Makefile| 12 ++ Makefile.objs |3 + Makefile.target |6 +- error.c |4 + hmp-commands.hx | 11 +- hmp.c | 116 ++ hmp.h | 31 + monitor.c | 273 +-- qapi-schema.json| 273 +++ qapi/qapi-dealloc-visitor.c | 34 +- qapi/qapi-types-core.h |3 + qapi/qmp-input-visitor.c|4 +- qapi/qmp-output-visitor.c | 20 +++- qemu-char.c | 35 ++ qerror.c| 33 + qerror.h|2 + qmp-commands.hx | 57 +++-- qmp.c | 92 +++ scripts/qapi-commands.py| 98 --- scripts/qapi-types.py |5 + scripts/qapi-visit.py |4 +- scripts/qapi.py |4 +- test-qmp-commands.c | 29 + test-visitor.c | 48 +++-- vl.c| 12 ++ 25 files changed, 877 insertions(+), 332 deletions(-)
Re: [Qemu-devel] [PATCH] pseries: Implement set-time-of-day RTAS function
On 29.09.2011, at 04:53, David Gibson wrote: > From: Breno Leitao > > Currently there is no implementation for set-time-of-day rtas function, > which causes the following warning "setting the clock failed (-1)" on > the guest. > > This patch just creates this function, get the timedate diff and store in > the papr environment, so that the correct value will be returned by > get-time-of-day. > > In order to try it, just adjust the hardware time, run hwclock --systohc, > so that, on when the system runs hwclock --hctosys, the value is correctly > adjusted, i.e. the host time plus the timediff. > > Signed-off-by: Breno Leitao > Signed-off-by: David Gibson Thanks, applied to ppc-next. Alex
Re: [Qemu-devel] [PATCH 1/3] pseries: Support SMT systems for KVM Book3S-HV
On 29.09.2011, at 08:45, David Gibson wrote:
> Alex Graf has already made qemu support KVM for the pseries machine
> when using the Book3S-PR KVM variant (which runs the guest in
> usermode, emulating supervisor operations). This code allows gets us
> very close to also working with KVM Book3S-HV (using the hypervisor
> capabilities of recent POWER CPUs).
>
> This patch moves us another step towards Book3S-HV support by
> correctly handling SMT (multithreaded) POWER CPUs. There are two
> parts to this:
>
> * Querying KVM to check SMT capability, and if present, adjusting the
> cpu numbers that qemu assigns to cause KVM to assign guest threads
> to cores in the right way (this isn't automatic, because the POWER
> HV support has a limitation that different threads on a single core
> cannot be in different guests at the same time).
>
> * Correctly informing the guest OS of the SMT thread to core mappings
> via the device tree.
>
> Signed-off-by: David Gibson
> ---
> hw/spapr.c | 23 ---
> target-ppc/helper.c | 11 +++
> target-ppc/kvm.c | 10 ++
> target-ppc/kvm_ppc.h |6 ++
> 4 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/hw/spapr.c b/hw/spapr.c
> index b118975..ba9ae1c 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -29,6 +29,9 @@
> #include "elf.h"
> #include "net.h"
> #include "blockdev.h"
> +#include "cpus.h"
> +#include "kvm.h"
> +#include "kvm_ppc.h"
>
> #include "hw/boards.h"
> #include "hw/ppc.h"
> @@ -103,6 +106,7 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
> uint32_t interrupt_server_ranges_prop[] = {0, cpu_to_be32(smp_cpus)};
> int i;
> char *modelname;
> +int smt = kvmppc_smt_threads();
>
> #define _FDT(exp) \
> do { \
> @@ -162,13 +166,17 @@ static void *spapr_create_fdt_skel(const char
> *cpu_model,
>
> for (env = first_cpu; env != NULL; env = env->next_cpu) {
> int index = env->cpu_index;
> -uint32_t gserver_prop[] = {cpu_to_be32(index), 0}; /* HACK! */
> +uint32_t servers_prop[smp_threads];
> +uint32_t gservers_prop[smp_threads * 2];
> char *nodename;
> uint32_t segs[] = {cpu_to_be32(28), cpu_to_be32(40),
>0x, 0x};
> uint32_t tbfreq = kvm_enabled() ? kvmppc_get_tbfreq() : TIMEBASE_FREQ;
> uint32_t cpufreq = kvm_enabled() ? kvmppc_get_clockfreq() :
> 10;
>
> +if ((index % smt) != 0)
> +continue;
Please run through checkpatch.pl
Alex
Re: [Qemu-devel] [PATCH 2/3] pseries: Allow KVM Book3S-HV on PPC970 CPUS
On 29.09.2011, at 08:45, David Gibson wrote:
> At present, using the hypervisor aware Book3S-HV KVM will only work
> with qemu on POWER7 CPUs. PPC970 CPUs also have hypervisor
> capability, but they lack the VRMA feature which makes assigning guest
> memory easier.
>
> In order to allow KVM Book3S-HV on PPC970, we need to specially
> allocate the first chunk of guest memory (the "Real Mode Area" or
> RMA), so that it is physically contiguous.
>
> Sufficiently recent host kernels allow such contiguous RMAs to be
> allocated, with a kvm capability advertising whether the feature is
> available and/or necessary on this hardware. This patch enables qemu
> to use this support, thus allowing kvm acceleration of pseries qemu
> machines on PPC970 hardware.
>
> Signed-off-by: Paul Mackerras
> Signed-off-by: David Gibson
> ---
> hw/spapr.c | 50
> target-ppc/kvm.c | 51 ++
> target-ppc/kvm_ppc.h |6 +
> 3 files changed, 98 insertions(+), 9 deletions(-)
>
> diff --git a/hw/spapr.c b/hw/spapr.c
> index ba9ae1c..d51425a 100644
> --- a/hw/spapr.c
> +++ b/hw/spapr.c
> @@ -89,6 +89,7 @@ qemu_irq spapr_allocate_irq(uint32_t hint, uint32_t
> *irq_num)
> }
>
> static void *spapr_create_fdt_skel(const char *cpu_model,
> + target_phys_addr_t rma_size,
>target_phys_addr_t initrd_base,
>target_phys_addr_t initrd_size,
>const char *boot_device,
> @@ -97,7 +98,9 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
> {
> void *fdt;
> CPUState *env;
> -uint64_t mem_reg_property[] = { 0, cpu_to_be64(ram_size) };
> +uint64_t mem_reg_property_rma[] = { 0, cpu_to_be64(rma_size) };
> +uint64_t mem_reg_property_nonrma[] = { cpu_to_be64(rma_size),
> + cpu_to_be64(ram_size - rma_size)
> };
> uint32_t start_prop = cpu_to_be32(initrd_base);
> uint32_t end_prop = cpu_to_be32(initrd_base + initrd_size);
> uint32_t pft_size_prop[] = {0, cpu_to_be32(hash_shift)};
> @@ -143,15 +146,25 @@ static void *spapr_create_fdt_skel(const char
> *cpu_model,
>
> _FDT((fdt_end_node(fdt)));
>
> -/* memory node */
> +/* memory node(s) */
> _FDT((fdt_begin_node(fdt, "memory@0")));
>
> _FDT((fdt_property_string(fdt, "device_type", "memory")));
> -_FDT((fdt_property(fdt, "reg",
> - mem_reg_property, sizeof(mem_reg_property;
> -
> +_FDT((fdt_property(fdt, "reg", mem_reg_property_rma,
> + sizeof(mem_reg_property_rma;
> _FDT((fdt_end_node(fdt)));
>
> +if (ram_size > rma_size) {
> +char mem_name[32];
> +
> + sprintf(mem_name, "memory@%" PRIx64, (uint64_t)rma_size);
> + _FDT((fdt_begin_node(fdt, mem_name)));
> + _FDT((fdt_property_string(fdt, "device_type", "memory")));
> +_FDT((fdt_property(fdt, "reg", mem_reg_property_nonrma,
> + sizeof(mem_reg_property_nonrma;
> +_FDT((fdt_end_node(fdt)));
> +}
> +
> /* cpus */
> _FDT((fdt_begin_node(fdt, "cpus")));
>
> @@ -341,6 +354,7 @@ static void ppc_spapr_init(ram_addr_t ram_size,
> {
> CPUState *env;
> int i;
> +target_phys_addr_t rma_alloc_size, rma_size;
> ram_addr_t ram_offset;
> uint32_t initrd_base;
> long kernel_size, initrd_size, fw_size;
> @@ -350,10 +364,23 @@ static void ppc_spapr_init(ram_addr_t ram_size,
> spapr = g_malloc(sizeof(*spapr));
> cpu_ppc_hypercall = emulate_spapr_hypercall;
>
> +/* Allocate RMA if necessary */
> +rma_alloc_size = kvmppc_alloc_rma("ppc_spapr.rma");
> +
> +if (rma_alloc_size == -1) {
> +hw_error("qemu: Unable to create RMA\n");
> +exit(1);
> +}
> +if (rma_alloc_size && (rma_alloc_size < ram_size)) {
> +rma_size = rma_alloc_size;
> +} else {
> +rma_size = ram_size;
> +}
> +
> /* We place the device tree just below either the top of RAM, or
> * 2GB, so that it can be processed with 32-bit code if
> * necessary */
> -spapr->fdt_addr = MIN(ram_size, 0x8000) - FDT_MAX_SIZE;
> +spapr->fdt_addr = MIN(rma_size, 0x8000) - FDT_MAX_SIZE;
The change looks sane, so I'd assume the description above is now wrong :)
> spapr->rtas_addr = spapr->fdt_addr - RTAS_MAX_SIZE;
>
> /* init CPUs */
> @@ -378,8 +405,13 @@ static void ppc_spapr_init(ram_addr_t ram_size,
>
> /* allocate RAM */
> spapr->ram_limit = ram_size;
> -ram_offset = qemu_ram_alloc(NULL, "ppc_spapr.ram", spapr->ram_limit);
> -cpu_register_physical_memory(0, ram_size, ram_offset);
> +if (spapr->ram_limit > rma_alloc_size) {
> +ram_addr_t nonrma_base = rma_alloc_size;
> +ram_addr_t nonrma_size = spapr->ram_limit - rma_alloc_size;
> +
> +ram_off
Re: [Qemu-devel] [PATCH 3/3] pseries: Use Book3S-HV TCE acceleration capabilities
On 29.09.2011, at 08:45, David Gibson wrote:
> The pseries machine of qemu implements the TCE mechanism used as a
> virtual IOMMU for the PAPR defined virtual IO devices. Because the
> PAPR spec only defines a small DMA address space, the guest VIO
> drivers need to update TCE mappings very frequently - the virtual
> network device is particularly bad. This means many slow exits to
> qemu to emulate the H_PUT_TCE hypercall.
>
> Sufficiently recent kernels allow this to be mitigated by implementing
> H_PUT_TCE in the host kernel. To make use of this, however, qemu
> needs to initialize the necessary TCE tables, and map them into itself
> so that the VIO device implementations can retrieve the mappings when
> they access guest memory (which is treated as a virtual DMA
> operation).
>
> This patch adds the necessary calls to use the KVM TCE acceleration.
> If the kernel does not support acceleration, or there is some other
> error creating the accelerated TCE table, then it will still fall back
> to full userspace TCE implementation.
>
> Signed-off-by: David Gibson
> ---
> hw/spapr_vio.c |8 ++-
> hw/spapr_vio.h |1 +
> target-ppc/kvm.c | 54 ++
> target-ppc/kvm_ppc.h | 14 +
> 4 files changed, 76 insertions(+), 1 deletions(-)
>
> diff --git a/hw/spapr_vio.c b/hw/spapr_vio.c
> index 35818e1..1da3032 100644
> --- a/hw/spapr_vio.c
> +++ b/hw/spapr_vio.c
> @@ -165,7 +165,13 @@ static void rtce_init(VIOsPAPRDevice *dev)
> * sizeof(VIOsPAPR_RTCE);
>
> if (size) {
> -dev->rtce_table = g_malloc0(size);
> +dev->rtce_table = kvmppc_create_spapr_tce(dev->reg,
> + dev->rtce_window_size,
> + &dev->kvmtce_fd);
> +
> +if (!dev->rtce_table) {
> +dev->rtce_table = g_malloc0(size);
> +}
> }
> }
>
> diff --git a/hw/spapr_vio.h b/hw/spapr_vio.h
> index 4fe5f74..a325a5f 100644
> --- a/hw/spapr_vio.h
> +++ b/hw/spapr_vio.h
> @@ -57,6 +57,7 @@ typedef struct VIOsPAPRDevice {
> target_ulong signal_state;
> uint32_t rtce_window_size;
> VIOsPAPR_RTCE *rtce_table;
> +int kvmtce_fd;
> VIOsPAPR_CRQ crq;
> } VIOsPAPRDevice;
>
> diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
> index 37ee902..866cf7f 100644
> --- a/target-ppc/kvm.c
> +++ b/target-ppc/kvm.c
> @@ -28,6 +28,7 @@
> #include "kvm_ppc.h"
> #include "cpu.h"
> #include "device_tree.h"
> +#include "hw/sysbus.h"
> #include "hw/spapr.h"
>
> #include "hw/sysbus.h"
> @@ -58,6 +59,7 @@ static int cap_ppc_smt = 0;
> #ifdef KVM_CAP_PPC_RMA
> static int cap_ppc_rma = 0;
> #endif
> +static int cap_spapr_tce = false;
>
> /* XXX We have a race condition where we actually have a level triggered
> * interrupt, but the infrastructure can't expose that yet, so the guest
> @@ -87,6 +89,9 @@ int kvm_arch_init(KVMState *s)
> #ifdef KVM_CAP_PPC_RMA
> cap_ppc_rma = kvm_check_extension(s, KVM_CAP_PPC_RMA);
> #endif
> +#ifdef KVM_CAP_SPAPR_TCE
> +cap_spapr_tce = kvm_check_extension(s, KVM_CAP_SPAPR_TCE);
> +#endif
>
> if (!cap_interrupt_level) {
> fprintf(stderr, "KVM: Couldn't find level irq capability. Expect the "
> @@ -792,6 +797,55 @@ off_t kvmppc_alloc_rma(const char *name)
> #endif
> }
>
> +void *kvmppc_create_spapr_tce(target_ulong liobn, uint32_t window_size, int
> *pfd)
> +{struct kvm_create_spapr_tce args = {
> +.liobn = liobn,
> +.window_size = window_size,
> +};
> +long len;
> +int fd;
> +void *table;
> +
> +if (!cap_spapr_tce) {
> +return NULL;
> +}
> +
> +fd = kvm_vm_ioctl(kvm_state, KVM_CREATE_SPAPR_TCE, &args);
> +if (fd < 0) {
> +return NULL;
> +}
> +
> +len = (window_size / SPAPR_VIO_TCE_PAGE_SIZE) * sizeof(VIOsPAPR_RTCE);
> +/* FIXME: round this up to page size */
> +
> +table = mmap(NULL, len, PROT_READ, MAP_SHARED, fd, 0);
> +if (table == MAP_FAILED) {
> +close(fd);
> +return NULL;
> +}
> +
> +*pfd = fd;
> +return table;
> +}
> +
> +int kvmppc_remove_spapr_tce(void *table, int fd, uint32_t window_size)
Hrm. Is this ever called somewhere?
Alex
[Qemu-devel] [RFC][PATCH 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Provides the ability for the guest to communicate with user-provided code inside QEMU itself, using a lightweight mechanism. See first commit for a full description. Signed-off-by: Lluís Vilanova --- Lluís Vilanova (5): backdoor: Add documentation backdoor: Add build infrastructure backdoor: [*-user] Add QEMU-side proxy to "libbackdoor.a" backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a" backdoor: Add guest-side library Makefile |3 - Makefile.objs | 21 Makefile.target|4 + backdoor/guest/Makefile| 18 backdoor/guest/common.c| 130 +++ backdoor/guest/qemu-backdoor.h | 50 ++ backdoor/qemu/qemu-backdoor.h | 29 ++ backdoor/qemu/softmmu.c| 124 ++ backdoor/qemu/user.c | 194 backdoor/qemu/user.h | 17 bsd-user/main.c| 25 + bsd-user/mmap.c|7 + configure | 35 +++ darwin-user/main.c | 25 + darwin-user/mmap.c |7 + docs/backdoor.txt | 144 ++ hw/pci.h |1 linux-user/main.c | 30 ++ linux-user/mmap.c |7 + 19 files changed, 869 insertions(+), 2 deletions(-) create mode 100644 backdoor/guest/Makefile create mode 100644 backdoor/guest/common.c create mode 100644 backdoor/guest/qemu-backdoor.h create mode 100644 backdoor/qemu/qemu-backdoor.h create mode 100644 backdoor/qemu/softmmu.c create mode 100644 backdoor/qemu/user.c create mode 100644 backdoor/qemu/user.h create mode 100644 docs/backdoor.txt
Re: [Qemu-devel] [PATCH v1 00/21]: First round of QAPI conversions
On Thu, 29 Sep 2011 07:55:37 -0500 Anthony Liguori wrote: > On 09/28/2011 09:44 AM, Luiz Capitulino wrote: > > This series is a bundle of three things: > > > > 1. Patches 01 to 04 add the middle mode feature to the current QMP server. > > That mode allows for the current server to support QAPI commands. The > > Original author is Anthony, you can find his original post here: > > > > http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00374.html > > > > 2. Patches 05 to 10 are fixes from Anthony and Michael to the QAPI > > handling of the list type. > > > > 3. Patches 11 to 21 are simple monitor commands conversions to the QAPI. > > This is just a rebase of a previous conversion work by Anthony. > > Great series! > > Other than the one minor comment re: strdup and commit messages, I think it's > ready to go. Actually, I've found a few small problems with the enumeration in patch 14: 1. I'm not using VmRunStatus internally in QEMU, I'm using RunState (which has to be dropped, right? - Is VmRunStatus a good name btw?) 2. RunState has a RSTATE_NO_STATE enum, which is used for initialization. To have that in VmRunStatus I had to add a 'no-status' value in the schema, is that ok? 3. The code generator is replacing "-" by "_" (eg. 'no-status becomes 'no_status') but I have already fixed this and will include the patch in v2 Also, it would be nice if Michael could review how I'm doing lists in patches 16 and 17. Thanks! > > Regards, > > Anthony Liguori > > > > > Makefile| 12 ++ > > Makefile.objs |3 + > > Makefile.target |6 +- > > error.c |4 + > > hmp-commands.hx | 11 +- > > hmp.c | 116 ++ > > hmp.h | 31 + > > monitor.c | 273 > > +-- > > qapi-schema.json| 273 > > +++ > > qapi/qapi-dealloc-visitor.c | 34 +- > > qapi/qapi-types-core.h |3 + > > qapi/qmp-input-visitor.c|4 +- > > qapi/qmp-output-visitor.c | 20 +++- > > qemu-char.c | 35 ++ > > qerror.c| 33 + > > qerror.h|2 + > > qmp-commands.hx | 57 +++-- > > qmp.c | 92 +++ > > scripts/qapi-commands.py| 98 --- > > scripts/qapi-types.py |5 + > > scripts/qapi-visit.py |4 +- > > scripts/qapi.py |4 +- > > test-qmp-commands.c | 29 + > > test-visitor.c | 48 +++-- > > vl.c| 12 ++ > > 25 files changed, 877 insertions(+), 332 deletions(-) > > > > >
Re: [Qemu-devel] [RFC][PATCH 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
On 09/29/2011 08:47 AM, Lluís Vilanova wrote: Provides the ability for the guest to communicate with user-provided code inside QEMU itself, using a lightweight mechanism. See first commit for a full description. Signed-off-by: Lluís Vilanova We already have two "backdoors" in QEMU: ivshmem and virtio-serial. Can you discuss why these are insufficient for your purposes? Also, what's the advantage of having a backdoor mechanism both for softmmu and user? I can't think of a practical use-case for it. Regards, Anthony Liguori --- Lluís Vilanova (5): backdoor: Add documentation backdoor: Add build infrastructure backdoor: [*-user] Add QEMU-side proxy to "libbackdoor.a" backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a" backdoor: Add guest-side library Makefile |3 - Makefile.objs | 21 Makefile.target|4 + backdoor/guest/Makefile| 18 backdoor/guest/common.c| 130 +++ backdoor/guest/qemu-backdoor.h | 50 ++ backdoor/qemu/qemu-backdoor.h | 29 ++ backdoor/qemu/softmmu.c| 124 ++ backdoor/qemu/user.c | 194 backdoor/qemu/user.h | 17 bsd-user/main.c| 25 + bsd-user/mmap.c|7 + configure | 35 +++ darwin-user/main.c | 25 + darwin-user/mmap.c |7 + docs/backdoor.txt | 144 ++ hw/pci.h |1 linux-user/main.c | 30 ++ linux-user/mmap.c |7 + 19 files changed, 869 insertions(+), 2 deletions(-) create mode 100644 backdoor/guest/Makefile create mode 100644 backdoor/guest/common.c create mode 100644 backdoor/guest/qemu-backdoor.h create mode 100644 backdoor/qemu/qemu-backdoor.h create mode 100644 backdoor/qemu/softmmu.c create mode 100644 backdoor/qemu/user.c create mode 100644 backdoor/qemu/user.h create mode 100644 docs/backdoor.txt
[Qemu-devel] [PATCH 2/5] backdoor: Add build infrastructure
Signed-off-by: Lluís Vilanova
---
Makefile |3 ++-
Makefile.objs | 18 ++
Makefile.target |4 +++-
backdoor/qemu/qemu-backdoor.h | 29 +
configure | 32
5 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 backdoor/qemu/qemu-backdoor.h
diff --git a/Makefile b/Makefile
index 6ed3194..fd7d9d9 100644
--- a/Makefile
+++ b/Makefile
@@ -40,7 +40,8 @@ else
DOCS=
endif
-SUBDIR_MAKEFLAGS=$(if $(V),,--no-print-directory) BUILD_DIR=$(BUILD_DIR)
+SUBDIR_MAKEFLAGS_=$(if $(V),,--no-print-directory) BUILD_DIR=$(BUILD_DIR)
+SUBDIR_MAKEFLAGS=$(SUBDIR_MAKEFLAGS_) SUBDIR_MAKEFLAGS="$(SUBDIR_MAKEFLAGS_)"
SUBDIR_DEVICES_MAK=$(patsubst %, %/config-devices.mak, $(TARGET_DIRS))
SUBDIR_DEVICES_MAK_DEP=$(patsubst %, %/config-devices.mak.d, $(TARGET_DIRS))
diff --git a/Makefile.objs b/Makefile.objs
index 1c65087..2493e59 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -395,6 +395,24 @@ trace-obj-y += $(addprefix trace/, $(trace-nested-y))
$(trace-obj-y): $(GENERATED_HEADERS)
##
+# backdoor
+
+backdoor-obj-y += $(addprefix backdoor/qemu/, $(backdoor-nested-y))
+
+ifdef CONFIG_BACKDOOR
+LIBBACKDOOR = libbackdoor/libbackdoor.a
+
+.PHONY: force
+force:
+
+$(LIBBACKDOOR): $(dir $(LIBBACKDOOR))/Makefile force
+ $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C $(dir $@) \
+ QEMU_CFLAGS="$(QEMU_CFLAGS)"\
+ TARGET_DIR="$(TARGET_DIR)$(dir $@)/" VPATH="$(VPATH)" \
+ SRC_PATH="$(SRC_PATH)" V="$(V)" "$(notdir $@)")
+endif
+
+##
# smartcard
libcacard-y = cac.o event.o vcard.o vreader.o vcard_emul_nss.o
vcard_emul_type.o card_7816.o
diff --git a/Makefile.target b/Makefile.target
index b00ff4e..565d0a8 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -79,6 +79,8 @@ libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
libobj-y += disas.o
+libobj-$(CONFIG_BACKDOOR) += $(backdoor-obj-y)
+
$(libobj-y): $(GENERATED_HEADERS)
# libqemu
@@ -397,7 +399,7 @@ endif # CONFIG_LINUX_USER
obj-$(CONFIG_GDBSTUB_XML) += gdbstub-xml.o
-$(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y)
+$(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) $(LIBBACKDOOR)
$(call LINK,$^)
diff --git a/backdoor/qemu/qemu-backdoor.h b/backdoor/qemu/qemu-backdoor.h
new file mode 100644
index 000..95cb53f
--- /dev/null
+++ b/backdoor/qemu/qemu-backdoor.h
@@ -0,0 +1,29 @@
+/*
+ * QEMU-side user-provided callbacks for the backdoor communication channel.
+ *
+ * Copyright (C) 2011 Lluís Vilanova
+ *
+ * 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
+#include
+
+
+/* Initialize the backdoor channel.
+ *
+ * @param data_size Size of the data channel.
+ */
+void qemu_backdoor_init(uint64_t data_size);
+
+/* Handle an invocation of the backdoor channel.
+ *
+ * The command argument can be used to achieve concurrency among different
+ * clients (e.g., threads in the guest system) of the backdoor channel (e.g.,
+ * different clients write to different parts of the data channel).
+ *
+ * @param cmd Command to invoke.
+ * @param data Pointer to the beginning of the data channel.
+ */
+void qemu_backdoor(uint64_t cmd, void *data);
diff --git a/configure b/configure
index 24b8df4..e2be271 100755
--- a/configure
+++ b/configure
@@ -174,6 +174,7 @@ user_pie="no"
zero_malloc=""
trace_backend="nop"
trace_file="trace"
+backdoor=""
spice=""
rbd=""
smartcard=""
@@ -540,6 +541,8 @@ for opt do
;;
--with-trace-file=*) trace_file="$optarg"
;;
+ --with-backdoor=*) backdoor="$optarg"
+ ;;
--enable-gprof) gprof="yes"
;;
--static)
@@ -1037,6 +1040,7 @@ echo " --enable-trace-backend=B Set trace backend"
echo " Available backends:"
$("$source_path"/scripts/tracetool --list-backends)
echo " --with-trace-file=NAME Full PATH,NAME of file to store traces"
echo " Default:trace-"
+echo " --with-backdoor=PATH Directory to build user-provided backdoor
library"
echo " --disable-spice disable spice"
echo " --enable-spice enable spice"
echo " --enable-rbd enable building the rados block device (rbd)"
@@ -2514,6 +2518,20 @@ if test "$trace_backend" = "dtrace"; then
fi
##
+# check for a valid directory for backdoor
+if test -n "$backdoor"; then
+if test ! -f "$backdoor/Makefile"; then
+echo
+echo "Error: cannot make into '$backdoor'"
+echo "Please choose a directory where I can run 'make'"
+echo
+exit 1
+fi
+backdoor=`readlink -f "$backdoor"`
+fi
+
+
+#
[Qemu-devel] [PATCH] tap: Add optional parameters to up/down script
This allows the user to add custom parameters to the up or down
scripts.
Cc: Anthony Liguori
Signed-off-by: Sasha Levin
---
net.c |8
net/tap.c | 37 ++---
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/net.c b/net.c
index d05930c..bb27598 100644
--- a/net.c
+++ b/net.c
@@ -952,10 +952,18 @@ static const struct {
.type = QEMU_OPT_STRING,
.help = "script to initialize the interface",
}, {
+.name = "scriptparams",
+.type = QEMU_OPT_STRING,
+.help = "parameters for the initialization script",
+}, {
.name = "downscript",
.type = QEMU_OPT_STRING,
.help = "script to shut down the interface",
}, {
+.name = "downscriptparams",
+.type = QEMU_OPT_STRING,
+.help = "parameters for the deinitialization script",
+}, {
.name = "sndbuf",
.type = QEMU_OPT_SIZE,
.help = "send buffer limit"
diff --git a/net/tap.c b/net/tap.c
index 1f26dc9..5a9141e 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -52,7 +52,7 @@ typedef struct TAPState {
VLANClientState nc;
int fd;
char down_script[1024];
-char down_script_arg[128];
+char down_script_arg[1024];
uint8_t buf[TAP_BUFSIZE];
unsigned int read_poll : 1;
unsigned int write_poll : 1;
@@ -392,7 +392,8 @@ static int net_tap_init(QemuOpts *opts, int *vnet_hdr)
{
int fd, vnet_hdr_required;
char ifname[128] = {0,};
-const char *setup_script;
+const char *setup_script, *setup_script_params;
+char setup_script_formatted[1024];
if (qemu_opt_get(opts, "ifname")) {
pstrcpy(ifname, sizeof(ifname), qemu_opt_get(opts, "ifname"));
@@ -411,10 +412,16 @@ static int net_tap_init(QemuOpts *opts, int *vnet_hdr)
}
setup_script = qemu_opt_get(opts, "script");
+setup_script_params = qemu_opt_get(opts, "scriptparams");
+if (setup_script_params == NULL)
+setup_script_params = "";
+
+snprintf(setup_script_formatted, sizeof(setup_script_formatted),
+ "%s %s", ifname, setup_script_params);
if (setup_script &&
setup_script[0] != '\0' &&
strcmp(setup_script, "no") != 0 &&
-launch_script(setup_script, ifname, fd)) {
+launch_script(setup_script, setup_script_formatted, fd)) {
close(fd);
return -1;
}
@@ -432,9 +439,12 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name, VLANState *vlan
if (qemu_opt_get(opts, "fd")) {
if (qemu_opt_get(opts, "ifname") ||
qemu_opt_get(opts, "script") ||
+qemu_opt_get(opts, "scriptparams") ||
qemu_opt_get(opts, "downscript") ||
+qemu_opt_get(opts, "downscriptparams") ||
qemu_opt_get(opts, "vnet_hdr")) {
-error_report("ifname=, script=, downscript= and vnet_hdr= is
invalid with fd=");
+error_report("ifname=, script=, downscript=, scriptparams=, "
+ "downscriptparams= and vnet_hdr= is invalid with
fd=");
return -1;
}
@@ -455,6 +465,14 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name, VLANState *vlan
qemu_opt_set(opts, "downscript", DEFAULT_NETWORK_DOWN_SCRIPT);
}
+if (!qemu_opt_get(opts, "scriptparams")) {
+qemu_opt_set(opts, "scriptparams", "");
+}
+
+if (!qemu_opt_get(opts, "downscriptparams")) {
+qemu_opt_set(opts, "downscriptparams", "");
+}
+
fd = net_tap_init(opts, &vnet_hdr);
if (fd == -1) {
return -1;
@@ -475,18 +493,23 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name, VLANState *vlan
snprintf(s->nc.info_str, sizeof(s->nc.info_str), "fd=%d", fd);
} else {
const char *ifname, *script, *downscript;
+ const char *scriptparams, *downscriptparams;
ifname = qemu_opt_get(opts, "ifname");
script = qemu_opt_get(opts, "script");
downscript = qemu_opt_get(opts, "downscript");
+scriptparams = qemu_opt_get(opts, "scriptparams");
+downscriptparams = qemu_opt_get(opts, "downscriptparams");
snprintf(s->nc.info_str, sizeof(s->nc.info_str),
- "ifname=%s,script=%s,downscript=%s",
- ifname, script, downscript);
+ "ifname=%s,script=%s,scriptparams=%s,downscript=%s,"
+ "downscriptparams=%s", ifname, script, scriptparams,
+ downscript, downscriptparams);
if (strcmp(downscript, "no") != 0) {
snprintf(s->down_script, sizeof(s->down_script), "%s", downscript);
-snprintf(s->down_script_arg, sizeof(s->down_script_arg), "%s",
ifname);
+snprintf(s->down_script_ar
Re: [Qemu-devel] [PATCH] tap: Add optional parameters to up/down script
On 2011-09-29 15:57, Sasha Levin wrote: > This allows the user to add custom parameters to the up or down > scripts. > What kind of parameters would you want to pass? Something that tells VMs apart (which can be solved without these extensions) or more? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH 3/5] backdoor: [*-user] Add QEMU-side proxy to "libbackdoor.a"
QEMU detects when the guest uses 'mmap' on the control channel file, and then
uses 'mprotect' to detect accesses to it, which are redirected to the
user-provided "libbackdoor.a".
Signed-off-by: Lluís Vilanova
---
Makefile.objs|2 +
backdoor/qemu/user.c | 194 ++
backdoor/qemu/user.h | 17
bsd-user/main.c | 25 ++
bsd-user/mmap.c |7 ++
configure|1
darwin-user/main.c | 25 ++
darwin-user/mmap.c |7 ++
linux-user/main.c| 30
linux-user/mmap.c|7 ++
10 files changed, 315 insertions(+), 0 deletions(-)
create mode 100644 backdoor/qemu/user.c
create mode 100644 backdoor/qemu/user.h
diff --git a/Makefile.objs b/Makefile.objs
index 2493e59..d39074d 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -397,6 +397,8 @@ $(trace-obj-y): $(GENERATED_HEADERS)
##
# backdoor
+backdoor-nested-$(CONFIG_USER_ONLY) += user.o
+
backdoor-obj-y += $(addprefix backdoor/qemu/, $(backdoor-nested-y))
ifdef CONFIG_BACKDOOR
diff --git a/backdoor/qemu/user.c b/backdoor/qemu/user.c
new file mode 100644
index 000..a236ca5
--- /dev/null
+++ b/backdoor/qemu/user.c
@@ -0,0 +1,194 @@
+/*
+ * QEMU-side management of backdoor channels in user-level emulation.
+ *
+ * Copyright (C) 2011 Lluís Vilanova
+ *
+ * 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 "backdoor/qemu/user.h"
+
+#include
+
+#include "qemu-common.h"
+#include "backdoor/qemu/qemu-backdoor.h"
+
+
+static char *data_path = NULL;
+static char *control_path = NULL;
+static int data_fd = -1;
+static int control_fd = -1;
+
+static void *data = NULL;
+static void *qemu_control_0 = NULL;
+static void *qemu_control_1 = NULL;
+
+static struct stat control_fd_stat;
+
+struct sigaction segv_next;
+static void segv_handler(int signum, siginfo_t *siginfo, void *sigctxt);
+
+
+static void init_channel(const char *base, const char *suffix, size_t size,
+ char ** path, int *fd, void **addr)
+{
+*path = g_malloc(strlen(base) + strlen(suffix) + 1);
+sprintf(*path, "%s%s", base, suffix);
+
+*fd = open(*path, O_CREAT | O_EXCL | O_RDWR, S_IRUSR | S_IWUSR);
+if (*fd == -1) {
+fprintf(stderr, "error: open(%s): %s\n", *path, strerror(errno));
+abort();
+}
+
+off_t lres = lseek(*fd, size - 1, SEEK_SET);
+if (lres == (off_t)-1) {
+fprintf(stderr, "error: lseek(%s): %s\n", *path, strerror(errno));
+abort();
+}
+
+char tmp;
+ssize_t wres = write(*fd, &tmp, 1);
+if (wres == -1) {
+fprintf(stderr, "error: write(%s): %s\n", *path, strerror(errno));
+abort();
+}
+
+if (addr) {
+*addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, *fd, 0);
+if (*addr == MAP_FAILED) {
+fprintf(stderr, "error: mmap(%s): %s\n", *path, strerror(errno));
+abort();
+}
+}
+}
+
+void backdoor_init(const char *base, uint64_t data_size)
+{
+if (base == NULL) {
+return;
+}
+
+init_channel(base, "-data", data_size, &data_path, &data_fd, &data);
+void *control;
+init_channel(base, "-control", getpagesize() * 2, &control_path,
&control_fd, &control);
+
+/* store channel size in first 64bits; command goes into 2nd slot */
+*(uint64_t*)control = data_size;
+
+if (fstat(control_fd, &control_fd_stat) == -1) {
+fprintf(stderr, "error: fstat(backdoor_control): %s\n",
strerror(errno));
+abort();
+}
+
+struct sigaction segv;
+memset(&segv, 0, sizeof(segv));
+segv.sa_sigaction = segv_handler;
+segv.sa_flags = SA_SIGINFO | SA_RESTART;
+sigemptyset(&segv.sa_mask);
+
+if (sigaction(SIGSEGV, &segv, &segv_next) != 0) {
+fprintf(stderr, "error: sigaction(SIGSEGV): %s\n", strerror(errno));
+abort();
+}
+
+qemu_backdoor_init(data_size);
+}
+
+
+static void fini_channel(int *fd, char **path)
+{
+if (*fd != -1) {
+if (close(*fd) == -1) {
+fprintf(stderr, "error: close: %s\n", strerror(errno));
+abort();
+}
+if (unlink(*path) == -1) {
+fprintf(stderr, "error: unlink(%s): %s\n", *path, strerror(errno));
+abort();
+}
+*fd = -1;
+}
+if (*path != NULL) {
+g_free(path);
+*path = NULL;
+}
+}
+
+void backdoor_fini(void)
+{
+static bool atexit_in = false;
+if (atexit_in) {
+return;
+}
+atexit_in = true;
+
+if (sigaction(SIGSEGV, &segv_next, NULL) != 0) {
+fprintf(stderr, "error: sigaction(SIGSEGV): %s\n", strerror(errno));
+abort();
+}
+fini_channel(&data_fd, &data_path);
+fini_channel(&control_fd, &control_path);
+}
+
+
+void backdoor_guest_mmap(int fd, void *qemu_addr)
+{
+
[Qemu-devel] [PATCH 4/5] backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a"
Uses a virtual device to proxy uses of the backdoor communication channel to the
user-provided code.
Signed-off-by: Lluís Vilanova
---
Makefile.objs |1
backdoor/qemu/softmmu.c | 124 +++
hw/pci.h|1
3 files changed, 126 insertions(+), 0 deletions(-)
create mode 100644 backdoor/qemu/softmmu.c
diff --git a/Makefile.objs b/Makefile.objs
index d39074d..5f54d10 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -398,6 +398,7 @@ $(trace-obj-y): $(GENERATED_HEADERS)
# backdoor
backdoor-nested-$(CONFIG_USER_ONLY) += user.o
+backdoor-nested-$(CONFIG_SOFTMMU) += softmmu.o
backdoor-obj-y += $(addprefix backdoor/qemu/, $(backdoor-nested-y))
diff --git a/backdoor/qemu/softmmu.c b/backdoor/qemu/softmmu.c
new file mode 100644
index 000..fdd3a25
--- /dev/null
+++ b/backdoor/qemu/softmmu.c
@@ -0,0 +1,124 @@
+/*
+ * QEMU-side management of backdoor channels in softmmu emulation.
+ *
+ * Copyright (C) 2011 Lluís Vilanova
+ *
+ * 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/pci.h"
+#include "backdoor/qemu/qemu-backdoor.h"
+
+
+#define PAGE_SIZE TARGET_PAGE_SIZE
+#define CTRL_BYTES sizeof(uint64_t)
+
+
+typedef struct State
+{
+PCIDevice dev;
+
+uint8_t pages;
+uint64_t size;
+
+uint64_t cmd;
+
+void *data_ptr;
+MemoryRegion data;
+MemoryRegion control;
+} State;
+
+
+static uint64_t control_io_read(void *opaque, target_phys_addr_t addr,
unsigned size)
+{
+State *s = opaque;
+
+uint64_t res = ldq_p(&s->size);
+uint8_t *resb = (uint8_t*)&res;
+return resb[addr % CTRL_BYTES];
+}
+
+static void control_io_write(void *opaque, target_phys_addr_t addr, uint64_t
data, unsigned size)
+{
+State *s = opaque;
+
+uint8_t *cmdb = (uint8_t*)&s->cmd;
+cmdb[addr % CTRL_BYTES] = (uint8_t)data;
+
+if ((addr + size) % CTRL_BYTES == 0) {
+qemu_backdoor(ldq_p(&s->cmd), s->data_ptr);
+}
+}
+
+static const MemoryRegionOps control_ops = {
+.read = control_io_read,
+.write = control_io_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
+
+static int init(PCIDevice *dev)
+{
+State *s = DO_UPCAST(State, dev, dev);
+
+if (s->pages < 1) {
+fprintf(stderr, "error: backdoor: "
+"the data channel must have one or more pages\n");
+return -1;
+}
+s->size = s->pages * PAGE_SIZE;
+
+pci_set_word(s->dev.config + PCI_COMMAND,
+ PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
+
+memory_region_init_io(&s->control, &control_ops, s, "backdoor.control",
+ PAGE_SIZE);
+pci_register_bar(&s->dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->control);
+
+memory_region_init_ram(&s->data, &s->dev.qdev, "backdoor.data",
+ s->size);
+pci_register_bar(&s->dev, 1, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->data);
+s->data_ptr = qemu_get_ram_ptr(s->data.ram_addr);
+
+qemu_backdoor_init(s->size);
+
+return 0;
+}
+
+static int fini(PCIDevice *dev)
+{
+State *s = DO_UPCAST(State, dev, dev);
+
+memory_region_destroy(&s->data);
+memory_region_destroy(&s->control);
+
+return 0;
+}
+
+
+static PCIDeviceInfo info = {
+.qdev.name = "backdoor",
+.qdev.desc = "Backdoor communication channel",
+.qdev.size = sizeof(State),
+.init = init,
+.exit = fini,
+.vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
+.device_id = PCI_DEVICE_ID_BACKDOOR,
+.class_id = PCI_CLASS_MEMORY_RAM,
+.qdev.props = (Property[]) {
+DEFINE_PROP_UINT8("pages", State, pages, 1),
+DEFINE_PROP_END_OF_LIST(),
+}
+};
+
+static void register_device(void)
+{
+pci_qdev_register(&info);
+}
+
+device_init(register_device)
diff --git a/hw/pci.h b/hw/pci.h
index 86a81c8..4d7d161 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -75,6 +75,7 @@
#define PCI_DEVICE_ID_VIRTIO_BLOCK 0x1001
#define PCI_DEVICE_ID_VIRTIO_BALLOON 0x1002
#define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003
+#define PCI_DEVICE_ID_BACKDOOR 0x1004
#define FMT_PCIBUS PRIx64
[Qemu-devel] [PATCH 5/5] backdoor: Add guest-side library
Guest applications can link against "libqemu-backdoor-guest.a" to use the
backdoor communication channel.
Signed-off-by: Lluís Vilanova
---
backdoor/guest/Makefile| 18 ++
backdoor/guest/common.c| 130
backdoor/guest/qemu-backdoor.h | 50 +++
configure |2 +
4 files changed, 200 insertions(+), 0 deletions(-)
create mode 100644 backdoor/guest/Makefile
create mode 100644 backdoor/guest/common.c
create mode 100644 backdoor/guest/qemu-backdoor.h
diff --git a/backdoor/guest/Makefile b/backdoor/guest/Makefile
new file mode 100644
index 000..200ee3b
--- /dev/null
+++ b/backdoor/guest/Makefile
@@ -0,0 +1,18 @@
+include ../../../config-host.mak
+include ../../config-target.mak
+include $(SRC_PATH)/rules.mak
+
+vpath % $(SRC_PATH)/backdoor/guest
+
+QEMU_CFLAGS += $(GLIB_CFLAGS)
+QEMU_CFLAGS += -I../../../
+QEMU_CFLAGS += -I../../
+
+obj-y = common.o
+
+libqemu-backdoor-guest.a: $(obj-y)
+
+all: libqemu-backdoor-guest.a
+
+clean:
+ rm -f $(obj-y) libqemu-backdoor-guest.a
diff --git a/backdoor/guest/common.c b/backdoor/guest/common.c
new file mode 100644
index 000..7b4354f
--- /dev/null
+++ b/backdoor/guest/common.c
@@ -0,0 +1,130 @@
+/*
+ * Guest-side management of backdoor channels.
+ *
+ * Copyright (C) 2011 Lluís Vilanova
+ *
+ * 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 "qemu-backdoor.h"
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "config-target.h"
+
+
+static char *data_path = NULL;
+static char *control_path = NULL;
+static int data_fd = -1;
+static int control_fd = -1;
+
+static void *data_addr = NULL;
+static void *control_addr = NULL;
+
+
+static int init_channel_file(const char *base, const char *suffix, size_t size,
+ char ** path, int *fd, void **addr)
+{
+*path = malloc(strlen(base) + strlen(suffix) + 1);
+sprintf(*path, "%s%s", base, suffix);
+
+*fd = open(*path, O_RDWR);
+if (*fd == -1) {
+return -1;
+}
+
+*addr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, *fd, 0);
+if (*addr == MAP_FAILED) {
+return -1;
+}
+return 0;
+}
+
+int qemu_backdoor_init(const char *base)
+{
+#if defined(CONFIG_USER_ONLY)
+const char *control_suff = "-control";
+const size_t control_size = getpagesize() * 2;
+const char *data_suff = "-data";
+#elif defined(__linux__)
+const char *control_suff = "/resource0";
+const size_t control_size = getpagesize();
+const char *data_suff = "/resource1";
+#else
+#error Unsupported OS
+#endif
+
+int res;
+res = init_channel_file(base, control_suff, control_size,
+&control_path, &control_fd, &control_addr);
+if (res != 0) {
+return res;
+}
+
+res = init_channel_file(base, data_suff, qemu_backdoor_data_size(),
+&data_path, &data_fd, &data_addr);
+if (res != 0) {
+return res;
+}
+return 0;
+}
+
+
+static int fini_channel(int *fd, char **path)
+{
+if (*fd != -1) {
+if (close(*fd) == -1) {
+return -1;
+}
+*fd = -1;
+}
+if (*path != NULL) {
+free(path);
+*path = NULL;
+}
+return 0;
+}
+
+int qemu_backdoor_fini(void)
+{
+if (fini_channel(&data_fd, &data_path) != 0) {
+return -1;
+}
+if (fini_channel(&control_fd, &control_path) != 0) {
+return -1;
+}
+return 0;
+}
+
+
+uint64_t qemu_backdoor_data_size(void)
+{
+return *(uint64_t*)control_addr;
+}
+
+void *qemu_backdoor_data(void)
+{
+return data_addr;
+}
+
+void qemu_backdoor (uint64_t cmd)
+{
+uint64_t *ctrl;
+ctrl = control_addr;
+ctrl[1] = cmd;
+#if defined(CONFIG_USER_ONLY)
+/* QEMU in 'user' mode uses two faulting pages to detect invocations */
+ctrl = control_addr + getpagesize();
+ctrl[1] = cmd;
+#endif
+}
diff --git a/backdoor/guest/qemu-backdoor.h b/backdoor/guest/qemu-backdoor.h
new file mode 100644
index 000..99d4cb2
--- /dev/null
+++ b/backdoor/guest/qemu-backdoor.h
@@ -0,0 +1,50 @@
+/*
+ * Guest-side management of backdoor channels.
+ *
+ * Copyright (C) 2011 Lluís Vilanova
+ *
+ * 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
+#include
+
+
+/** Initialize the backdoor channel.
+ *
+ * The base path to the backdoor channel is dependant on the type of QEMU
+ * target:
+ *
+ * - User (single-application)
+ * The base path provided when starting QEMU ("-backdoor" commandline
option).
+ *
+ * - Softmmu (full-system); OS-dependant
+ * - Linux: The base path to the backdoor channel virtual device ("-device
+ * backdoor" commandline option).
+ *
+ * @param base Base path to the b
Re: [Qemu-devel] [PATCH 12/21] qapi: Convert query-version
On Thu, 29 Sep 2011 07:54:57 -0500
Anthony Liguori wrote:
> On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
> > The original conversion was done by Anthony Liguori. This commit
> > is just a rebase.
>
> For all of the rest of the patches, you can add my Signed-off-by: before your
> SoB. Then you don't need to have the disclaimer in the commit message.
And I let the author as being me?
>
> Regards,
>
> Anthony Liguori
>
> >
> > Signed-off-by: Luiz Capitulino
> > ---
> > hmp.c| 13 +
> > hmp.h|1 +
> > monitor.c| 46 +++---
> > qapi-schema.json | 37 +
> > qmp-commands.hx |6 ++
> > qmp.c| 16
> > 6 files changed, 76 insertions(+), 43 deletions(-)
> >
> > diff --git a/hmp.c b/hmp.c
> > index 47e1ff7..bb6c86f 100644
> > --- a/hmp.c
> > +++ b/hmp.c
> > @@ -24,3 +24,16 @@ void hmp_info_name(Monitor *mon)
> > }
> > qapi_free_NameInfo(info);
> > }
> > +
> > +void hmp_info_version(Monitor *mon)
> > +{
> > +VersionInfo *info;
> > +
> > +info = qmp_query_version(NULL);
> > +
> > +monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> > + info->qemu.major, info->qemu.minor, info->qemu.micro,
> > + info->package);
> > +
> > +qapi_free_VersionInfo(info);
> > +}
> > diff --git a/hmp.h b/hmp.h
> > index 5fe73f1..2aa75a2 100644
> > --- a/hmp.h
> > +++ b/hmp.h
> > @@ -18,5 +18,6 @@
> > #include "qapi-types.h"
> >
> > void hmp_info_name(Monitor *mon);
> > +void hmp_info_version(Monitor *mon);
> >
> > #endif
> > diff --git a/monitor.c b/monitor.c
> > index 8af0e27..9edc38c 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -730,37 +730,6 @@ help:
> > help_cmd(mon, "info");
> > }
> >
> > -static void do_info_version_print(Monitor *mon, const QObject *data)
> > -{
> > -QDict *qdict;
> > -QDict *qemu;
> > -
> > -qdict = qobject_to_qdict(data);
> > -qemu = qdict_get_qdict(qdict, "qemu");
> > -
> > -monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
> > - qdict_get_int(qemu, "major"),
> > - qdict_get_int(qemu, "minor"),
> > - qdict_get_int(qemu, "micro"),
> > - qdict_get_str(qdict, "package"));
> > -}
> > -
> > -static void do_info_version(Monitor *mon, QObject **ret_data)
> > -{
> > -const char *version = QEMU_VERSION;
> > -int major = 0, minor = 0, micro = 0;
> > -char *tmp;
> > -
> > -major = strtol(version,&tmp, 10);
> > -tmp++;
> > -minor = strtol(tmp,&tmp, 10);
> > -tmp++;
> > -micro = strtol(tmp,&tmp, 10);
> > -
> > -*ret_data = qobject_from_jsonf("{ 'qemu': { 'major': %d, 'minor': %d, \
> > -'micro': %d }, 'package': %s }", major, minor, micro,
> > QEMU_PKGVERSION);
> > -}
> > -
> > static QObject *get_cmd_dict(const char *name)
> > {
> > const char *p;
> > @@ -2866,8 +2835,7 @@ static const mon_cmd_t info_cmds[] = {
> > .args_type = "",
> > .params = "",
> > .help = "show the version of QEMU",
> > -.user_print = do_info_version_print,
> > -.mhandler.info_new = do_info_version,
> > +.mhandler.info = hmp_info_version,
> > },
> > {
> > .name = "network",
> > @@ -3159,14 +3127,6 @@ static const mon_cmd_t qmp_cmds[] = {
> >
> > static const mon_cmd_t qmp_query_cmds[] = {
> > {
> > -.name = "version",
> > -.args_type = "",
> > -.params = "",
> > -.help = "show the version of QEMU",
> > -.user_print = do_info_version_print,
> > -.mhandler.info_new = do_info_version,
> > -},
> > -{
> > .name = "commands",
> > .args_type = "",
> > .params = "",
> > @@ -5172,9 +5132,9 @@ void monitor_resume(Monitor *mon)
> >
> > static QObject *get_qmp_greeting(void)
> > {
> > -QObject *ver;
> > +QObject *ver = NULL;
> >
> > -do_info_version(NULL,&ver);
> > +qmp_marshal_input_query_version(NULL, NULL,&ver);
> > return qobject_from_jsonf("{'QMP':{'version': %p,'capabilities':
> > []}}",ver);
> > }
> >
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index 3585324..3c0ac4e 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -23,3 +23,40 @@
> > # Since 0.14.0
> > ##
> > { 'command': 'query-name', 'returns': 'NameInfo' }
> > +
> > +##
> > +# @VersionInfo:
> > +#
> > +# A description of QEMU's version.
> > +#
> > +# @qemu.major: The major version of QEMU
> > +#
> > +# @qemu.minor: The minor version of QEMU
> > +#
> > +# @qemu.micro: The micro version of QEMU. By current convention, a micro
> > +# version of 50 signifies a development branch. A micro
> > version
> > +# greater than or equal to 90 signifies a release candidat
[Qemu-devel] [PATCH 1/5] backdoor: Add documentation
Signed-off-by: Lluís Vilanova
---
docs/backdoor.txt | 144 +
1 files changed, 144 insertions(+), 0 deletions(-)
create mode 100644 docs/backdoor.txt
diff --git a/docs/backdoor.txt b/docs/backdoor.txt
new file mode 100644
index 000..3b26b70
--- /dev/null
+++ b/docs/backdoor.txt
@@ -0,0 +1,144 @@
+= Backdoor communication channel =
+
+== Introduction ==
+
+This document describes how the guest can use the backdoor communication
channel
+to interact with user-provided code inside QEMU.
+
+The backdoor provides a lightweight and guest-initiated communication channel
+between code running inside the guest system and code in QEMU, including both
+QEMU in 'softmmu' and 'user' modes.
+
+The semantics of the backdoor channel are up to the user, who must provide the
+implementation of the QEMU-side callbacks used when the backdoor channel is
+invoked.
+
+On the guest side, code can simply link against a simple library provided in
+QEMU to interface with the backdoor channel.
+
+The features of this mechanism are:
+
+* Minimal setup for the guest.
+* Independent of guest architecture.
+* Works with 'softmmu' and 'user' mode.
+* Low overhead; capturing memory accesses to specific addresses does not go
+ through any OS abstraction, except during the setup of the communication
+ channel.
+
+
+== QEMU-side code ==
+
+1. Create the "Makefile" to build the user-provided backdoor channel library:
+
+mkdir /tmp/my-backdoor-qemu
+cat > /tmp/my-backdoor-qemu/Makefile < /tmp/my-backdoor-qemu/backdoor.c <
+
+
+void qemu_backdoor_init(uint64_t data_size)
+{
+printf("+ %ld\n", data_size);
+}
+
+void qemu_backdoor(uint64_t cmd, void *data)
+{
+/* Perform any endianess-wise loads to interpret the data */
+uint64_t d = ldq_p(data);
+printf("-> %x :: %x\n", cmd, *(uint64_t*)data);
+}
+EOF
+
+3. Build QEMU with the backdoor feature:
+
+/path/to/qemu/configure --with-backdoor=/tmp/my-backdoor-qemu
+
+
+== Guest-side code ==
+
+1. Compile the corresponding guest-side interface library:
+
+make -C /path/to/qemu-build/x86_64-linux-user/backdoor/guest
+
+2. Create your own application to interact with the backdoor channel:
+
+cat > /tmp/my-backdoor-guest.c <
+#include
+#include
+#include
+
+
+int main()
+{
+/* This base path is only applicable to 'user' mode */
+if (qemu_backdoor_init("/tmp/backdoor") != 0) {
+fprintf(stderr, "error: qemu_backdoor_init: %s\n",
strerror(errno));
+abort();
+}
+
+/* Get a pointer to beginning of the data channel */
+uint32_t * data = qemu_backdoor_data();
+/* Write anything into the channel */
+*data = 0xcafe;
+/* Invoke the channel */
+qemu_backdoor(0xbabe);
+}
+EOF
+
+3. Link your application against "libqemu-backdoor-guest.a":
+
+gcc -o /tmp/my-backdoor-guest /tmp/my-backdoor-guest.c
/path/to/qemu-build/x86_64-linux-user/backdoor/guest/libqemu-backdoor-guest.a
+
+
+== Running QEMU ==
+
+If you want to use QEMU's 'softmmu' mode:
+
+/path/to/qemu-build/x86_64-softmmu/qemu-system-x86_64 -device backdoor
+sudo /tmp/my-backdoor-guest # inside the VM
+
+If you want to use QEMU's 'user' mode:
+
+/path/to/qemu-build/x86_64-linux-user/qemu-x86_64 -backdoor /tmp/backdoor
/tmp/my-backdoor-guest
+
+
+== Implementation details ==
+
+The backdoor channel is composed of two channels that are handled as 'mmap'ed
+files. The data channel is used to contain arbitrary data to communicate back
+and forth between the guest and QEMU. The control channel is used by the guest
+to signal that the data channel is ready to be used.
+
+When using the 'softmmu' mode, the backdoor communication channels are provided
+as a virtual device used through MMIO. The data channel acts as regular memory
+and the control channel intercepts all accesses to it to proxy them to the
+user-provided backdoor library.
+
+When using the 'user' mode, the backdoor communication channels are provided as
+regular files in the host system that the guest must 'mmap' into its address
+space. The data channel acts as regular memory and the 'mmap' of the control
+channel is intercepted in QEMU to establish if it's an 'mmap' for the control
+channel file. If that's the case, the memory that QEMU allocates for the guest
+is 'mprotect'ed to intercept all accesses to it performed by the guest and
proxy
+them to the user-provided backdoor library.
Re: [Qemu-devel] [PATCH] tap: Add optional parameters to up/down script
On 2011-09-29 16:11 jan kiszka wrote > What kind of parameters would you want to pass? Something that tells VMs > apart (which can be solved without these extensions) or more? > > Jan In our Case: We want to simulate an larger environment with multiple switches realized in openvswitch. Openvswitch requires a up- and downscript for each switch. So the idea was, have a single and variable up- and downscript and feed it with parameters (like switch to use, vlan id and so on) through the scriptparams. Greetings
Re: [Qemu-devel] [PATCH 12/21] qapi: Convert query-version
On 09/29/2011 09:32 AM, Luiz Capitulino wrote:
On Thu, 29 Sep 2011 07:54:57 -0500
Anthony Liguori wrote:
On 09/28/2011 09:44 AM, Luiz Capitulino wrote:
The original conversion was done by Anthony Liguori. This commit
is just a rebase.
For all of the rest of the patches, you can add my Signed-off-by: before your
SoB. Then you don't need to have the disclaimer in the commit message.
And I let the author as being me?
Sure.
Regards,
Anthony Liguori
Regards,
Anthony Liguori
Signed-off-by: Luiz Capitulino
---
hmp.c| 13 +
hmp.h|1 +
monitor.c| 46 +++---
qapi-schema.json | 37 +
qmp-commands.hx |6 ++
qmp.c| 16
6 files changed, 76 insertions(+), 43 deletions(-)
diff --git a/hmp.c b/hmp.c
index 47e1ff7..bb6c86f 100644
--- a/hmp.c
+++ b/hmp.c
@@ -24,3 +24,16 @@ void hmp_info_name(Monitor *mon)
}
qapi_free_NameInfo(info);
}
+
+void hmp_info_version(Monitor *mon)
+{
+VersionInfo *info;
+
+info = qmp_query_version(NULL);
+
+monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
+ info->qemu.major, info->qemu.minor, info->qemu.micro,
+ info->package);
+
+qapi_free_VersionInfo(info);
+}
diff --git a/hmp.h b/hmp.h
index 5fe73f1..2aa75a2 100644
--- a/hmp.h
+++ b/hmp.h
@@ -18,5 +18,6 @@
#include "qapi-types.h"
void hmp_info_name(Monitor *mon);
+void hmp_info_version(Monitor *mon);
#endif
diff --git a/monitor.c b/monitor.c
index 8af0e27..9edc38c 100644
--- a/monitor.c
+++ b/monitor.c
@@ -730,37 +730,6 @@ help:
help_cmd(mon, "info");
}
-static void do_info_version_print(Monitor *mon, const QObject *data)
-{
-QDict *qdict;
-QDict *qemu;
-
-qdict = qobject_to_qdict(data);
-qemu = qdict_get_qdict(qdict, "qemu");
-
-monitor_printf(mon, "%" PRId64 ".%" PRId64 ".%" PRId64 "%s\n",
- qdict_get_int(qemu, "major"),
- qdict_get_int(qemu, "minor"),
- qdict_get_int(qemu, "micro"),
- qdict_get_str(qdict, "package"));
-}
-
-static void do_info_version(Monitor *mon, QObject **ret_data)
-{
-const char *version = QEMU_VERSION;
-int major = 0, minor = 0, micro = 0;
-char *tmp;
-
-major = strtol(version,&tmp, 10);
-tmp++;
-minor = strtol(tmp,&tmp, 10);
-tmp++;
-micro = strtol(tmp,&tmp, 10);
-
-*ret_data = qobject_from_jsonf("{ 'qemu': { 'major': %d, 'minor': %d, \
-'micro': %d }, 'package': %s }", major, minor, micro, QEMU_PKGVERSION);
-}
-
static QObject *get_cmd_dict(const char *name)
{
const char *p;
@@ -2866,8 +2835,7 @@ static const mon_cmd_t info_cmds[] = {
.args_type = "",
.params = "",
.help = "show the version of QEMU",
-.user_print = do_info_version_print,
-.mhandler.info_new = do_info_version,
+.mhandler.info = hmp_info_version,
},
{
.name = "network",
@@ -3159,14 +3127,6 @@ static const mon_cmd_t qmp_cmds[] = {
static const mon_cmd_t qmp_query_cmds[] = {
{
-.name = "version",
-.args_type = "",
-.params = "",
-.help = "show the version of QEMU",
-.user_print = do_info_version_print,
-.mhandler.info_new = do_info_version,
-},
-{
.name = "commands",
.args_type = "",
.params = "",
@@ -5172,9 +5132,9 @@ void monitor_resume(Monitor *mon)
static QObject *get_qmp_greeting(void)
{
-QObject *ver;
+QObject *ver = NULL;
-do_info_version(NULL,&ver);
+qmp_marshal_input_query_version(NULL, NULL,&ver);
return qobject_from_jsonf("{'QMP':{'version': %p,'capabilities':
[]}}",ver);
}
diff --git a/qapi-schema.json b/qapi-schema.json
index 3585324..3c0ac4e 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -23,3 +23,40 @@
# Since 0.14.0
##
{ 'command': 'query-name', 'returns': 'NameInfo' }
+
+##
+# @VersionInfo:
+#
+# A description of QEMU's version.
+#
+# @qemu.major: The major version of QEMU
+#
+# @qemu.minor: The minor version of QEMU
+#
+# @qemu.micro: The micro version of QEMU. By current convention, a micro
+# version of 50 signifies a development branch. A micro version
+# greater than or equal to 90 signifies a release candidate for
+# the next minor version. A micro version of less than 50
+# signifies a stable release.
+#
+# @package: QEMU will always set this field to an empty string. Downstream
+# versions of QEMU should set this to a non-empty string. The
+# exact format depends on the downstream however it highly
+# recommended that a unique name is used.
+#
+# Since: 0.14.0
+##
+{ 'type': 'VersionInfo',
+ 'data
[Qemu-devel] [PATCH] linux-user: Fix broken "-version" option
Fix the "-version" option, which was accidentally broken in commit
fc9c541:
* exit after printing version information rather than proceeding
blithely onward (and likely printing the full usage message)
* correct the cut-n-paste error in the usage message for it
* don't insist on the presence of a following argument for
options which don't take an argument (this was preventing
'qemu-arm -version' from working)
* remove a spurious argc check from the beginning of main() which
meant 'QEMU_VERSION=1 qemu-arm' didn't work.
Signed-off-by: Peter Maydell
---
linux-user/main.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 186358b..e7dad54 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -3084,6 +3084,7 @@ static void handle_arg_version(const char *arg)
{
printf("qemu-" TARGET_ARCH " version " QEMU_VERSION QEMU_PKGVERSION
", Copyright (c) 2003-2008 Fabrice Bellard\n");
+exit(0);
}
struct qemu_argument {
@@ -3129,7 +3130,7 @@ struct qemu_argument arg_table[] = {
{"strace", "QEMU_STRACE", false, handle_arg_strace,
"", "log system calls"},
{"version","QEMU_VERSION", false, handle_arg_version,
- "", "log system calls"},
+ "", "display version information and exit"},
{NULL, NULL, false, NULL, NULL, NULL}
};
@@ -3231,16 +3232,15 @@ static int parse_args(int argc, char **argv)
for (arginfo = arg_table; arginfo->handle_opt != NULL; arginfo++) {
if (!strcmp(r, arginfo->argv)) {
-if (optind >= argc) {
-usage();
-}
-
-arginfo->handle_opt(argv[optind]);
-
if (arginfo->has_arg) {
+if (optind >= argc) {
+usage();
+}
+arginfo->handle_opt(argv[optind]);
optind++;
+} else {
+arginfo->handle_opt(NULL);
}
-
break;
}
}
@@ -3276,9 +3276,6 @@ int main(int argc, char **argv, char **envp)
int i;
int ret;
-if (argc <= 1)
-usage();
-
qemu_cache_utils_init(envp);
if ((envlist = envlist_create()) == NULL) {
--
1.7.4.1
Re: [Qemu-devel] [PATCH] tap: Add optional parameters to up/down script
On 09/29/2011 08:57 AM, Sasha Levin wrote:
This allows the user to add custom parameters to the up or down
scripts.
Cc: Anthony Liguori
Signed-off-by: Sasha Levin
---
net.c |8
net/tap.c | 37 ++---
2 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/net.c b/net.c
index d05930c..bb27598 100644
--- a/net.c
+++ b/net.c
@@ -952,10 +952,18 @@ static const struct {
.type = QEMU_OPT_STRING,
.help = "script to initialize the interface",
}, {
+.name = "scriptparams",
+.type = QEMU_OPT_STRING,
+.help = "parameters for the initialization script",
+}, {
.name = "downscript",
.type = QEMU_OPT_STRING,
.help = "script to shut down the interface",
}, {
+.name = "downscriptparams",
+.type = QEMU_OPT_STRING,
+.help = "parameters for the deinitialization script",
+}, {
.name = "sndbuf",
.type = QEMU_OPT_SIZE,
.help = "send buffer limit"
diff --git a/net/tap.c b/net/tap.c
index 1f26dc9..5a9141e 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -52,7 +52,7 @@ typedef struct TAPState {
VLANClientState nc;
int fd;
char down_script[1024];
-char down_script_arg[128];
+char down_script_arg[1024];
uint8_t buf[TAP_BUFSIZE];
unsigned int read_poll : 1;
unsigned int write_poll : 1;
@@ -392,7 +392,8 @@ static int net_tap_init(QemuOpts *opts, int *vnet_hdr)
{
int fd, vnet_hdr_required;
char ifname[128] = {0,};
-const char *setup_script;
+const char *setup_script, *setup_script_params;
+char setup_script_formatted[1024];
if (qemu_opt_get(opts, "ifname")) {
pstrcpy(ifname, sizeof(ifname), qemu_opt_get(opts, "ifname"));
@@ -411,10 +412,16 @@ static int net_tap_init(QemuOpts *opts, int *vnet_hdr)
}
setup_script = qemu_opt_get(opts, "script");
+setup_script_params = qemu_opt_get(opts, "scriptparams");
+if (setup_script_params == NULL)
+setup_script_params = "";
+
+snprintf(setup_script_formatted, sizeof(setup_script_formatted),
+ "%s %s", ifname, setup_script_params);
if (setup_script&&
setup_script[0] != '\0'&&
strcmp(setup_script, "no") != 0&&
-launch_script(setup_script, ifname, fd)) {
+launch_script(setup_script, setup_script_formatted, fd)) {
This is a little awkward. launch_script uses execv() so you'll effectively do:
/etc/qemu-ifup "tap0 myargument"
When what you'd expect to happen is:
/etc/qemu-ifup "tap0" "myargument"
I'd suggest adding another parameter to launch script so that you can preserve
the argument ordering. As an added bonus, you won't have to truncate at 1024
bytes anymore.
Regards,
Anthony Liguori
close(fd);
return -1;
}
@@ -432,9 +439,12 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name, VLANState *vlan
if (qemu_opt_get(opts, "fd")) {
if (qemu_opt_get(opts, "ifname") ||
qemu_opt_get(opts, "script") ||
+qemu_opt_get(opts, "scriptparams") ||
qemu_opt_get(opts, "downscript") ||
+qemu_opt_get(opts, "downscriptparams") ||
qemu_opt_get(opts, "vnet_hdr")) {
-error_report("ifname=, script=, downscript= and vnet_hdr= is invalid
with fd=");
+error_report("ifname=, script=, downscript=, scriptparams=, "
+ "downscriptparams= and vnet_hdr= is invalid with
fd=");
return -1;
}
@@ -455,6 +465,14 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name, VLANState *vlan
qemu_opt_set(opts, "downscript", DEFAULT_NETWORK_DOWN_SCRIPT);
}
+if (!qemu_opt_get(opts, "scriptparams")) {
+qemu_opt_set(opts, "scriptparams", "");
+}
+
+if (!qemu_opt_get(opts, "downscriptparams")) {
+qemu_opt_set(opts, "downscriptparams", "");
+}
+
fd = net_tap_init(opts,&vnet_hdr);
if (fd == -1) {
return -1;
@@ -475,18 +493,23 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char
*name, VLANState *vlan
snprintf(s->nc.info_str, sizeof(s->nc.info_str), "fd=%d", fd);
} else {
const char *ifname, *script, *downscript;
+ const char *scriptparams, *downscriptparams;
ifname = qemu_opt_get(opts, "ifname");
script = qemu_opt_get(opts, "script");
downscript = qemu_opt_get(opts, "downscript");
+scriptparams = qemu_opt_get(opts, "scriptparams");
+downscriptparams = qemu_opt_get(opts, "downscriptparams");
snprintf(s->nc.info_str, sizeof(s->nc.info_str),
- "ifname=%s,script=%s,downscript=%s",
-
Re: [Qemu-devel] Qemu varying performance
"Edgar E. Iglesias" writes:
> But running Debian's 64-bit kernel vmlinux-2.6.32-5-5kc-malta under
> qemu-system-mips64 consumes 100% on the host system, whether the guest
> is idle or busy. (And for qemu-system-mips64el, the same is true for the
> corresponding 64-bit el kernel.)
Hi, It could be any of them or both. You'll have to dig a bit deeper and
see if WAIT insns are beeing issued and if QEMU is successfully decoding
them etc.
Thanks for this advice!
I naively ran 'objdump -dw' on the kernel, looked for wait, and thanks
to the naming of kernel idle loop functions, was able to make educated
guesses about which processors would be fed the 'wait' instruction.
The feeble conclusion made, that passing '-cpu 5Kc' to
qemu-system-mips64{el,} would help, turned out to be correct--now my
mips64 systems uses insignificant host CPU when they idle.
--
Torbjörn
Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes
On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" wrote: > From: "Daniel P. Berrange" > > The Linux guest kernel does not appear to have a problem handling > a mount_tag larger than 32 bytes. Increase the limit to 255 bytes, > though perhaps it can be made larger still, or not limited at all ? > > Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length. > > * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255 mount_tag is passed via pci config space, do we want to have 255 bytes out of that for device identification. Is this change driven by the virt-manager UI where we specify source and target directory for file system ?. I would like to understand how that target directory is used in case of other user like NFS ?. If this is something used to get automout (I am not sure how we drive such an automount) of those mounts points, then it should be ok for VirtFS to generate mount tag internally which will fit 32 byte limit and use the target directory for automounting the mount point using the internally generated mount tag > > Signed-off-by: Daniel P. Berrange > --- > hw/9pfs/virtio-9p.h |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/hw/9pfs/virtio-9p.h b/hw/9pfs/virtio-9p.h > index 17d44b4..b133b33 100644 > --- a/hw/9pfs/virtio-9p.h > +++ b/hw/9pfs/virtio-9p.h > @@ -144,7 +144,7 @@ struct V9fsPDU > /* The ID for virtio console */ > #define VIRTIO_ID_9P9 > #define MAX_REQ 128 > -#define MAX_TAG_LEN 32 > +#define MAX_TAG_LEN 255 > > #define BUG_ON(cond) assert(!(cond)) > -aneesh
Re: [Qemu-devel] [PATCH v2] tcg-i386: Introduce limited deposit support
On 09/29/2011 04:31 AM, Jan Kiszka wrote: > x86 cannot provide an optimized generic deposit implementation. But at > least for a few special cases, namely for writing bits 0..7, 8..15, and > 0..15, versions using only a single instruction are feasible. > Introducing such limited support improves emulating 16-bit x86 code on > x86, but also rarer cases where 32-bit or 64-bit code accesses bytes or > words. > > Signed-off-by: Jan Kiszka > --- > > Changes in v2: > - introduce restricting predicates TCG_TARGET_deposit_i32/64_valid >to decide if deposit support can be used > - express register constraints via new 'Q' symbol That's what I had in mind, yes. The only thing that's missing now is a default version of > +#define TCG_TARGET_deposit_i32_valid(ofs, len) \ > +(((ofs) == 0 && (len) == 8) || ((ofs) == 8 && (len) == 8) || \ > + ((ofs) == 0 && (len) == 16)) > +#define TCG_TARGET_deposit_i64_validTCG_TARGET_deposit_i32_valid These. r~
Re: [Qemu-devel] [PATCH] Ensure an error is reported to user if 9pfs mount tag is too long
On Thu, 29 Sep 2011 11:33:44 +0100, "Daniel P. Berrange"
wrote:
> From: "Daniel P. Berrange"
>
> If the 9pfs mount tag is longer than MAX_TAG_LEN bytes, rather than
> silently truncating the tag which will likely break the guest OS,
> report an immediate error and exit QEMU
>
> * hw/9pfs/virtio-9p-device.c: Report error & exit if mount tag is
> too long
>
> Signed-off-by: Daniel P. Berrange
Applied to the VirtFS (git://repo.or.cz/qemu/v9fs.git). I have to apply
by hand, because it didn't apply cleanly. I also fixed checkpatch.pl errors.
> ---
> hw/9pfs/virtio-9p-device.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
> index 97f2da5..8ca38d3 100644
> --- a/hw/9pfs/virtio-9p-device.c
> +++ b/hw/9pfs/virtio-9p-device.c
> @@ -117,7 +117,9 @@ VirtIODevice *virtio_9p_init(DeviceState *dev, V9fsConf
> *conf)
> s->ctx.fs_root = g_strdup(fse->path);
> len = strlen(conf->tag);
> if (len > MAX_TAG_LEN) {
> -len = MAX_TAG_LEN;
> + fprintf(stderr, "mount tag '%s' (%d bytes) is longer than maximum (%d
> bytes)",
> + conf->tag, len, MAX_TAG_LEN);
> + exit(1);
> }
> /* s->tag is non-NULL terminated string */
> s->tag = g_malloc(len);
> --
> 1.7.6.2
>
>
-aneesh
Re: [Qemu-devel] [PATCH v2] tcg-i386: Introduce limited deposit support
On 2011-09-29 16:58, Richard Henderson wrote: > On 09/29/2011 04:31 AM, Jan Kiszka wrote: >> x86 cannot provide an optimized generic deposit implementation. But at >> least for a few special cases, namely for writing bits 0..7, 8..15, and >> 0..15, versions using only a single instruction are feasible. >> Introducing such limited support improves emulating 16-bit x86 code on >> x86, but also rarer cases where 32-bit or 64-bit code accesses bytes or >> words. >> >> Signed-off-by: Jan Kiszka >> --- >> >> Changes in v2: >> - introduce restricting predicates TCG_TARGET_deposit_i32/64_valid >>to decide if deposit support can be used >> - express register constraints via new 'Q' symbol > > That's what I had in mind, yes. > > The only thing that's missing now is a default version of > >> +#define TCG_TARGET_deposit_i32_valid(ofs, len) \ >> +(((ofs) == 0 && (len) == 8) || ((ofs) == 8 && (len) == 8) || \ >> + ((ofs) == 0 && (len) == 16)) >> +#define TCG_TARGET_deposit_i64_validTCG_TARGET_deposit_i32_valid > > These. Interestingly, that didn't break the build here. Seems like gcc became too smart to report this. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] tap: Add optional parameters to up/down script
On 2011-09-29 16:40, Thomas Jung wrote: > On 2011-09-29 16:11 jan kiszka wrote >> What kind of parameters would you want to pass? Something that tells VMs >> apart (which can be solved without these extensions) or more? >> >> Jan > > In our Case: > > We want to simulate an larger environment with multiple switches realized in > openvswitch. > Openvswitch requires a up- and downscript for each switch. So the idea was, > have a single and variable up- and downscript and feed it with parameters > (like switch to use, vlan id and so on) through the scriptparams. Sounds reasonable. A short note on the "why" in the description would have been nice. The patch has some style issues that should be addressed first (checkpatch will tell). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH] Raise 9pfs mount_tag limit from 32 to 255 bytes
On Thu, Sep 29, 2011 at 08:23:49PM +0530, Aneesh Kumar K.V wrote: > On Thu, 29 Sep 2011 11:34:21 +0100, "Daniel P. Berrange" > wrote: > > From: "Daniel P. Berrange" > > > > The Linux guest kernel does not appear to have a problem handling > > a mount_tag larger than 32 bytes. Increase the limit to 255 bytes, > > though perhaps it can be made larger still, or not limited at all ? > > > > Tested with a 3.0.4 kernel and a mount_tag 255 bytes in length. > > > > * hw/9pfs/virtio-9p.h: Change MAX_TAG_LEN to 255 > > > mount_tag is passed via pci config space, do we want to have 255 bytes > out of that for device identification. How big is the config space available for each 9pfs device and what other info does it need to keep there ? >Is this change driven by > the virt-manager UI where we specify source and target directory for > file system ?. I would like to understand how that target > directory is used in case of other user like NFS ?. If this is something > used to get automout (I am not sure how we drive such an automount) of > those mounts points, then it should be ok for VirtFS to generate mount tag > internally > which will fit 32 byte limit and use the target directory for > automounting the mount point using the internally generated mount tag There's no virt-manager involved in what I'm working on. It is a tiny app with KVM embedded behind the scenes. All that runs inside the virtual machine is a minature 'init' process which mounts any 9pfs filesystems it finds, creates some device nodes, and then runs the application bianry. The 'init' code does not have any knowledge of where the 9pfs filesystems need to be mounted, that info must come from the host, because it can vary on each boot. I don't want to have to pass separate 'mount_tag'; -> 'mount point' mapping data through to the guest via a side-channel. I just want to put the target mount point path, directly in the mount tag. Originally I was trying to namespace my mount tags org.virttools.dir:/mount/point/path but this hit the 32 byte limit almost immediately, so now I just put the raw '/mount/point/path' in each mount tag. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
[Qemu-devel] [PATCH v3] tcg-i386: Introduce limited deposit support
x86 cannot provide an optimized generic deposit implementation. But at
least for a few special cases, namely for writing bits 0..7, 8..15, and
0..15, versions using only a single instruction are feasible.
Introducing such limited support improves emulating 16-bit x86 code on
x86, but also rarer cases where 32-bit or 64-bit code accesses bytes or
words.
Signed-off-by: Jan Kiszka
---
Changes in v3:
- provide default TCG_TARGET_deposit_i32_valid - just in case
Changes in v2:
- introduce restricting predicates TCG_TARGET_deposit_i32/64_valid
to decide if deposit support can be used
- express register constraints via new 'Q' symbol
tcg/i386/tcg-target.c | 24
tcg/i386/tcg-target.h |9 +++--
tcg/tcg-op.h |4 ++--
tcg/tcg.h |7 +++
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index 281f87d..3069e53 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -168,6 +168,10 @@ static int target_parse_constraint(TCGArgConstraint *ct,
const char **pct_str)
tcg_regset_set32(ct->u.regs, 0, 0xf);
}
break;
+case 'Q':
+ct->ct |= TCG_CT_REG;
+tcg_regset_set32(ct->u.regs, 0, 0xf);
+break;
case 'r':
ct->ct |= TCG_CT_REG;
if (TCG_TARGET_REG_BITS == 64) {
@@ -1747,6 +1751,22 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
break;
#endif
+OP_32_64(deposit):
+if (args[3] == 0 && args[4] == 8) {
+/* load bits 0..7 */
+tcg_out_modrm(s, OPC_MOVB_EvGv | P_REXB_R | P_REXB_RM,
+ args[2], args[0]);
+} else if (args[3] == 8 && args[4] == 8) {
+/* load bits 8..15 */
+tcg_out_modrm(s, OPC_MOVB_EvGv, args[2], args[0] + 4);
+} else if (args[3] == 0 && args[4] == 16) {
+/* load bits 0..15 */
+tcg_out_modrm(s, OPC_MOVL_EvGv | P_DATA16, args[2], args[0]);
+} else {
+tcg_abort();
+}
+break;
+
default:
tcg_abort();
}
@@ -1802,6 +1822,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_setcond_i32, { "q", "r", "ri" } },
+{ INDEX_op_deposit_i32, { "Q", "0", "Q" } },
+
#if TCG_TARGET_REG_BITS == 32
{ INDEX_op_mulu2_i32, { "a", "d", "a", "r" } },
{ INDEX_op_add2_i32, { "r", "r", "0", "1", "ri", "ri" } },
@@ -1853,6 +1875,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_ext8u_i64, { "r", "r" } },
{ INDEX_op_ext16u_i64, { "r", "r" } },
{ INDEX_op_ext32u_i64, { "r", "r" } },
+
+{ INDEX_op_deposit_i64, { "Q", "0", "Q" } },
#endif
#if TCG_TARGET_REG_BITS == 64
diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
index 5088e47..b9c9d4e 100644
--- a/tcg/i386/tcg-target.h
+++ b/tcg/i386/tcg-target.h
@@ -90,7 +90,7 @@ enum {
#define TCG_TARGET_HAS_eqv_i32 0
#define TCG_TARGET_HAS_nand_i32 0
#define TCG_TARGET_HAS_nor_i32 0
-#define TCG_TARGET_HAS_deposit_i32 0
+#define TCG_TARGET_HAS_deposit_i32 1
#if TCG_TARGET_REG_BITS == 64
#define TCG_TARGET_HAS_div2_i64 1
@@ -111,9 +111,14 @@ enum {
#define TCG_TARGET_HAS_eqv_i64 0
#define TCG_TARGET_HAS_nand_i64 0
#define TCG_TARGET_HAS_nor_i64 0
-#define TCG_TARGET_HAS_deposit_i64 0
+#define TCG_TARGET_HAS_deposit_i64 1
#endif
+#define TCG_TARGET_deposit_i32_valid(ofs, len) \
+(((ofs) == 0 && (len) == 8) || ((ofs) == 8 && (len) == 8) || \
+ ((ofs) == 0 && (len) == 16))
+#define TCG_TARGET_deposit_i64_validTCG_TARGET_deposit_i32_valid
+
#define TCG_TARGET_HAS_GUEST_BASE
/* Note: must be synced with dyngen-exec.h */
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index 404b637..fea5983 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -2045,7 +2045,7 @@ static inline void tcg_gen_deposit_i32(TCGv_i32 ret,
TCGv_i32 arg1,
TCGv_i32 arg2, unsigned int ofs,
unsigned int len)
{
-if (TCG_TARGET_HAS_deposit_i32) {
+if (TCG_TARGET_HAS_deposit_i32 && TCG_TARGET_deposit_i32_valid(ofs, len)) {
tcg_gen_op5ii_i32(INDEX_op_deposit_i32, ret, arg1, arg2, ofs, len);
} else {
uint32_t mask = (1u << len) - 1;
@@ -2064,7 +2064,7 @@ static inline void tcg_gen_deposit_i64(TCGv_i64 ret,
TCGv_i64 arg1,
TCGv_i64 arg2, unsigned int ofs,
unsigned int len)
{
-if (TCG_TARGET_HAS_deposit_i64) {
+if (TCG_TARGET_HAS_deposit_i64 && TCG_TARGET_deposit_i64_valid(ofs, len)) {
tcg_gen_op5ii_i64(INDEX_op_deposit_i64, ret, arg1, arg2, ofs, len);
} else {
uint64_t mask = (1ull << len) - 1;
diff --git a/tcg/tcg.h b/tcg/tcg.h
index dc5e9c9..520255a 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -71,6 +71,13 @@ typedef uint64_t TCGRegSet;
#defi
Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
On Wed, 28 Sep 2011 16:18:07 +0100, "Daniel P. Berrange"
wrote:
> On Wed, Sep 28, 2011 at 05:22:06PM +0530, Harsh Bora wrote:
> > On 09/22/2011 11:12 PM, Daniel P. Berrange wrote:
> > >I've noticed that if you use a virtio 9p filesystem with a mount_tag
> > >property value that is longer than 32 bytes, it gets silently truncated.
> > >
> > >In virtio-9p-device.c
> > >
> > > len = strlen(conf->tag);
> > > if (len> MAX_TAG_LEN) {
> > > len = MAX_TAG_LEN;
> >
> > I think its better to return here with a failure message saying
> > mount_tag too long. IIUC, The 32 byte limit has been kept because of
> > understanding that mount_tag is a device name in guest (and not a
> > path location).
>
> While I appreciate the fact that 'mount_tag' is not required to be
> a path name, so you can allow symbolic naming for exports, in some
> use cases it is important / significantly simpler to be able to just
> set a path name. I don't think we should mandate symbolic naming,
> or path based naming - we should just allow users to choose which
> best suits their needs.
>
> For example, I am building appliances which have multiple 9p devices
> exported to the guest. These 9p filesystems are all mounted by the
> 'init' process in the initrd. If I'm forced to use symbolic naming
> for devices, it means I need to create a custom initrd for every
> appliance configuration I have (many many many of them), with the
> init process knowing how to map from symbolic names back to the
> mount paths I actually want. If I can just use a path for the
> mount_tag, then one single initrd can be used for all my appliances.
>
> So I really would like 'mount_tag' to be significantly larger upto
> at least 255 bytes, or more.
>
Will you not be able to have well defined mount tags, that map these
directories. I guess we don't want to claim 255 bytes out of config
space for mount tag. That is one of the reason it is limited to 32
bytes.
-aneesh
Re: [Qemu-devel] [PATCH] tap: Add optional parameters to up/down script
On Thu, 2011-09-29 at 17:20 +0200, Jan Kiszka wrote: > On 2011-09-29 16:40, Thomas Jung wrote: > > On 2011-09-29 16:11 jan kiszka wrote > >> What kind of parameters would you want to pass? Something that tells VMs > >> apart (which can be solved without these extensions) or more? > >> > >> Jan > > > > In our Case: > > > > We want to simulate an larger environment with multiple switches realized in > > openvswitch. > > Openvswitch requires a up- and downscript for each switch. So the idea was, > > have a single and variable up- and downscript and feed it with parameters > > (like switch to use, vlan id and so on) through the scriptparams. > > Sounds reasonable. A short note on the "why" in the description would > have been nice. Sure, I'll add the use case to the patch note. > The patch has some style issues that should be addressed first > (checkpatch will tell). I wasn't aware that there was a checkpatch for qemu, now I do :) I'll fix it and resend. -- Sasha.
Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
On Thu, Sep 29, 2011 at 08:52:14PM +0530, Aneesh Kumar K.V wrote:
> On Wed, 28 Sep 2011 16:18:07 +0100, "Daniel P. Berrange"
> wrote:
> > On Wed, Sep 28, 2011 at 05:22:06PM +0530, Harsh Bora wrote:
> > > On 09/22/2011 11:12 PM, Daniel P. Berrange wrote:
> > > >I've noticed that if you use a virtio 9p filesystem with a mount_tag
> > > >property value that is longer than 32 bytes, it gets silently truncated.
> > > >
> > > >In virtio-9p-device.c
> > > >
> > > > len = strlen(conf->tag);
> > > > if (len> MAX_TAG_LEN) {
> > > > len = MAX_TAG_LEN;
> > >
> > > I think its better to return here with a failure message saying
> > > mount_tag too long. IIUC, The 32 byte limit has been kept because of
> > > understanding that mount_tag is a device name in guest (and not a
> > > path location).
> >
> > While I appreciate the fact that 'mount_tag' is not required to be
> > a path name, so you can allow symbolic naming for exports, in some
> > use cases it is important / significantly simpler to be able to just
> > set a path name. I don't think we should mandate symbolic naming,
> > or path based naming - we should just allow users to choose which
> > best suits their needs.
> >
> > For example, I am building appliances which have multiple 9p devices
> > exported to the guest. These 9p filesystems are all mounted by the
> > 'init' process in the initrd. If I'm forced to use symbolic naming
> > for devices, it means I need to create a custom initrd for every
> > appliance configuration I have (many many many of them), with the
> > init process knowing how to map from symbolic names back to the
> > mount paths I actually want. If I can just use a path for the
> > mount_tag, then one single initrd can be used for all my appliances.
> >
> > So I really would like 'mount_tag' to be significantly larger upto
> > at least 255 bytes, or more.
> >
>
> Will you not be able to have well defined mount tags, that map these
> directories. I guess we don't want to claim 255 bytes out of config
> space for mount tag. That is one of the reason it is limited to 32
> bytes.
The reason for using paths instead of symbolic names in the
mount tag is because the guest code does not know what paths it
might be asked to mount at runtime. Symbolic names in the mount
tags are only useful if the guest can be told ahead of time about
a finite set of tag -> path mappings, which is not a reasonable
assumption in general.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On (Wed) 03 Aug 2011 [13:24:22], Jan Kiszka wrote:
> From: Fabien Chouteau
>
> In the current implementation, if Slirp tries to send an IP packet to a client
> with an unknown hardware address, the packet is simply dropped and an ARP
> request is sent (if_encap in slirp/slirp.c).
>
> With this patch, Slirp will send the ARP request, re-queue the packet and try
> to send it later. The packet is dropped after one second if the ARP reply is
> not received.
This patch causes a segfault when guests wake up from hibernate.
Recipe:
1. Start guest with -net user -net nic,model=virtio
2. (guest) ping 10.0.2.2
3. (guest) echo "disk" > /sys/power/state
4. Re-start guest with same command line
5. Ping has stopped receiving replies.
6. Kill that ping process and start a new one. qemu segfaults.
This needs the not-upstream-yet virtio S4 handling patches, found at
http://thread.gmane.org/gmane.linux.kernel/1197141
The backtrace is:
(gdb) bt
#0 0x77e421f7 in slirp_insque (a=0x0, b=0x78f95d50) at
/home/amit/src/qemu/slirp/misc.c:27
#1 0x77e40738 in if_start (slirp=0x78a9cdf0) at
/home/amit/src/qemu/slirp/if.c:194
#2 0x77e44828 in slirp_select_poll (readfds=0x7fffd930,
writefds=0x7fffd9b0, xfds=0x7fffda30, select_error=0)
at /home/amit/src/qemu/slirp/slirp.c:588
#3 0x77e110f1 in main_loop_wait (nonblocking=)
at /home/amit/src/qemu/vl.c:1549
#4 0x77d7dc47 in main_loop () at
/home/amit/src/qemu/vl.c:1579
#5 main (argc=, argv=, envp=) at /home/amit/src/qemu/vl.c:3574
Reverting the patch keeps the ping going on after resume.
Leaving the patch in context:
>
> Signed-off-by: Fabien Chouteau
> Signed-off-by: Jan Kiszka
> ---
> slirp/if.c| 28 +++---
> slirp/main.h |2 +-
> slirp/mbuf.c |2 +
> slirp/mbuf.h |2 +
> slirp/slirp.c | 72 +++-
> 5 files changed, 69 insertions(+), 37 deletions(-)
>
> diff --git a/slirp/if.c b/slirp/if.c
> index 0f04e13..2d79e45 100644
> --- a/slirp/if.c
> +++ b/slirp/if.c
> @@ -6,6 +6,7 @@
> */
>
> #include
> +#include "qemu-timer.h"
>
> #define ifs_init(ifm) ((ifm)->ifs_next = (ifm)->ifs_prev = (ifm))
>
> @@ -105,6 +106,9 @@ if_output(struct socket *so, struct mbuf *ifm)
> ifs_init(ifm);
> insque(ifm, ifq);
>
> +/* Expiration date = Now + 1 second */
> +ifm->expiration_date = qemu_get_clock_ns(rt_clock) + 10ULL;
> +
> diddit:
> slirp->if_queued++;
>
> @@ -153,6 +157,9 @@ diddit:
> void
> if_start(Slirp *slirp)
> {
> +int requeued = 0;
> +uint64_t now;
> +
> struct mbuf *ifm, *ifqt;
>
> DEBUG_CALL("if_start");
> @@ -165,6 +172,8 @@ if_start(Slirp *slirp)
> if (!slirp_can_output(slirp->opaque))
> return;
>
> +now = qemu_get_clock_ns(rt_clock);
> +
> /*
>* See which queue to get next packet from
>* If there's something in the fastq, select it immediately
> @@ -199,11 +208,22 @@ if_start(Slirp *slirp)
> ifm->ifq_so->so_nqueued = 0;
> }
>
> - /* Encapsulate the packet for sending */
> -if_encap(slirp, (uint8_t *)ifm->m_data, ifm->m_len);
> -
> -m_free(ifm);
> +if (ifm->expiration_date < now) {
> +/* Expired */
> +m_free(ifm);
> +} else {
> +/* Encapsulate the packet for sending */
> +if (if_encap(slirp, ifm)) {
> +m_free(ifm);
> +} else {
> +/* re-queue */
> +insque(ifm, ifqt);
> +requeued++;
> +}
> +}
>
> if (slirp->if_queued)
> goto again;
> +
> +slirp->if_queued = requeued;
> }
> diff --git a/slirp/main.h b/slirp/main.h
> index 0dd8d81..028df4b 100644
> --- a/slirp/main.h
> +++ b/slirp/main.h
> @@ -42,5 +42,5 @@ extern int tcp_keepintvl;
> #define PROTO_PPP 0x2
> #endif
>
> -void if_encap(Slirp *slirp, const uint8_t *ip_data, int ip_data_len);
> +int if_encap(Slirp *slirp, struct mbuf *ifm);
> ssize_t slirp_send(struct socket *so, const void *buf, size_t len, int
> flags);
> diff --git a/slirp/mbuf.c b/slirp/mbuf.c
> index ce2eb84..c699c75 100644
> --- a/slirp/mbuf.c
> +++ b/slirp/mbuf.c
> @@ -70,6 +70,8 @@ m_get(Slirp *slirp)
> m->m_len = 0;
> m->m_nextpkt = NULL;
> m->m_prevpkt = NULL;
> +m->arp_requested = false;
> +m->expiration_date = (uint64_t)-1;
> end_error:
> DEBUG_ARG("m = %lx", (long )m);
> return m;
> diff --git a/slirp/mbuf.h b/slirp/mbuf.h
> index b74544b..55170e5 100644
> --- a/slirp/mbuf.h
> +++ b/slirp/mbuf.h
> @@ -86,6 +86,8 @@ struct mbuf {
> charm_dat_[1]; /* ANSI don't like 0 sized arrays */
> char*m_ext_;
> } M_dat;
> +bool arp_requested;
> +uint64_t expiration_date;
> };
>
> #define m_next m_hdr.mh_next
> diff --gi
Re: [Qemu-devel] [PATCH v3] tcg-i386: Introduce limited deposit support
On 09/29/2011 08:23 AM, Jan Kiszka wrote: > +#ifndef TCG_TARGET_deposit_i32_valid > +#define TCG_TARGET_deposit_i32_valid(ofs, len) 0 > +#endif > +#ifndef TCG_TARGET_deposit_i64_valid > +#define TCG_TARGET_deposit_i64_valid(ofs, len) 0 > +#endif Err, no. The default is true. The targets that currently implement deposit at present can handle arbitrary inputs. r~
[Qemu-devel] [PATCH v4] tcg-i386: Introduce limited deposit support
On 2011-09-29 18:11, Richard Henderson wrote:
> On 09/29/2011 08:23 AM, Jan Kiszka wrote:
>> +#ifndef TCG_TARGET_deposit_i32_valid
>> +#define TCG_TARGET_deposit_i32_valid(ofs, len) 0
>> +#endif
>> +#ifndef TCG_TARGET_deposit_i64_valid
>> +#define TCG_TARGET_deposit_i64_valid(ofs, len) 0
>> +#endif
>
> Err, no. The default is true. The targets that currently
> implement deposit at present can handle arbitrary inputs.
Grr, of course.
---
x86 cannot provide an optimized generic deposit implementation. But at
least for a few special cases, namely for writing bits 0..7, 8..15, and
0..15, versions using only a single instruction are feasible.
Introducing such limited support improves emulating 16-bit x86 code on
x86, but also rarer cases where 32-bit or 64-bit code accesses bytes or
words.
Signed-off-by: Jan Kiszka
---
Changes in v4:
- provide correct default TCG_TARGET_deposit_i32_valid
Changes in v3:
- provide default TCG_TARGET_deposit_i32_valid - just in case
Changes in v2:
- introduce restricting predicates TCG_TARGET_deposit_i32/64_valid
to decide if deposit support can be used
- express register constraints via new 'Q' symbol
tcg/i386/tcg-target.c | 24
tcg/i386/tcg-target.h |9 +++--
tcg/tcg-op.h |4 ++--
tcg/tcg.h |7 +++
4 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/tcg/i386/tcg-target.c b/tcg/i386/tcg-target.c
index 281f87d..3069e53 100644
--- a/tcg/i386/tcg-target.c
+++ b/tcg/i386/tcg-target.c
@@ -168,6 +168,10 @@ static int target_parse_constraint(TCGArgConstraint *ct,
const char **pct_str)
tcg_regset_set32(ct->u.regs, 0, 0xf);
}
break;
+case 'Q':
+ct->ct |= TCG_CT_REG;
+tcg_regset_set32(ct->u.regs, 0, 0xf);
+break;
case 'r':
ct->ct |= TCG_CT_REG;
if (TCG_TARGET_REG_BITS == 64) {
@@ -1747,6 +1751,22 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode
opc,
break;
#endif
+OP_32_64(deposit):
+if (args[3] == 0 && args[4] == 8) {
+/* load bits 0..7 */
+tcg_out_modrm(s, OPC_MOVB_EvGv | P_REXB_R | P_REXB_RM,
+ args[2], args[0]);
+} else if (args[3] == 8 && args[4] == 8) {
+/* load bits 8..15 */
+tcg_out_modrm(s, OPC_MOVB_EvGv, args[2], args[0] + 4);
+} else if (args[3] == 0 && args[4] == 16) {
+/* load bits 0..15 */
+tcg_out_modrm(s, OPC_MOVL_EvGv | P_DATA16, args[2], args[0]);
+} else {
+tcg_abort();
+}
+break;
+
default:
tcg_abort();
}
@@ -1802,6 +1822,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_setcond_i32, { "q", "r", "ri" } },
+{ INDEX_op_deposit_i32, { "Q", "0", "Q" } },
+
#if TCG_TARGET_REG_BITS == 32
{ INDEX_op_mulu2_i32, { "a", "d", "a", "r" } },
{ INDEX_op_add2_i32, { "r", "r", "0", "1", "ri", "ri" } },
@@ -1853,6 +1875,8 @@ static const TCGTargetOpDef x86_op_defs[] = {
{ INDEX_op_ext8u_i64, { "r", "r" } },
{ INDEX_op_ext16u_i64, { "r", "r" } },
{ INDEX_op_ext32u_i64, { "r", "r" } },
+
+{ INDEX_op_deposit_i64, { "Q", "0", "Q" } },
#endif
#if TCG_TARGET_REG_BITS == 64
diff --git a/tcg/i386/tcg-target.h b/tcg/i386/tcg-target.h
index 5088e47..b9c9d4e 100644
--- a/tcg/i386/tcg-target.h
+++ b/tcg/i386/tcg-target.h
@@ -90,7 +90,7 @@ enum {
#define TCG_TARGET_HAS_eqv_i32 0
#define TCG_TARGET_HAS_nand_i32 0
#define TCG_TARGET_HAS_nor_i32 0
-#define TCG_TARGET_HAS_deposit_i32 0
+#define TCG_TARGET_HAS_deposit_i32 1
#if TCG_TARGET_REG_BITS == 64
#define TCG_TARGET_HAS_div2_i64 1
@@ -111,9 +111,14 @@ enum {
#define TCG_TARGET_HAS_eqv_i64 0
#define TCG_TARGET_HAS_nand_i64 0
#define TCG_TARGET_HAS_nor_i64 0
-#define TCG_TARGET_HAS_deposit_i64 0
+#define TCG_TARGET_HAS_deposit_i64 1
#endif
+#define TCG_TARGET_deposit_i32_valid(ofs, len) \
+(((ofs) == 0 && (len) == 8) || ((ofs) == 8 && (len) == 8) || \
+ ((ofs) == 0 && (len) == 16))
+#define TCG_TARGET_deposit_i64_validTCG_TARGET_deposit_i32_valid
+
#define TCG_TARGET_HAS_GUEST_BASE
/* Note: must be synced with dyngen-exec.h */
diff --git a/tcg/tcg-op.h b/tcg/tcg-op.h
index 404b637..fea5983 100644
--- a/tcg/tcg-op.h
+++ b/tcg/tcg-op.h
@@ -2045,7 +2045,7 @@ static inline void tcg_gen_deposit_i32(TCGv_i32 ret,
TCGv_i32 arg1,
TCGv_i32 arg2, unsigned int ofs,
unsigned int len)
{
-if (TCG_TARGET_HAS_deposit_i32) {
+if (TCG_TARGET_HAS_deposit_i32 && TCG_TARGET_deposit_i32_valid(ofs, len)) {
tcg_gen_op5ii_i32(INDEX_op_deposit_i32, ret, arg1, arg2, ofs, len);
} else {
uint32_t mask = (1u << len) - 1;
@@ -2064,7 +2064,7 @@ static inline void tcg_gen_deposit_i64(TCGv_i64 ret,
TCGv_i64 arg1,
[Qemu-devel] (no subject)
I wonder if it is possible to compile a newer version of qemu with (the defunct) kqemu on Windows (XP)? The winkvm project doesn't seem to be usable yet. -- Ottavio
[Qemu-devel] Kqemu support in current qemu
Sorry, I had forgotten to add a title -- Forwarded message -- From: Ottavio Date: 29 September 2011 17:55 Subject: To: qemu-devel@nongnu.org Cc: qemu-us...@yahoogroups.com I wonder if it is possible to compile a newer version of qemu with (the defunct) kqemu on Windows (XP)? The winkvm project doesn't seem to be usable yet. -- Ottavio
Re: [Qemu-devel] [RFC][PATCH 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
Anthony Liguori writes: > On 09/29/2011 08:47 AM, Lluís Vilanova wrote: >> Provides the ability for the guest to communicate with user-provided code >> inside >> QEMU itself, using a lightweight mechanism. >> >> See first commit for a full description. >> >> Signed-off-by: Lluís Vilanova > We already have two "backdoors" in QEMU: ivshmem and virtio-serial. Can you > discuss why these are insufficient for your purposes? The main point is that I want the user to be able to provide (at compile time, although it could also be done through dlopen or similar) her own implementation of what to do immediately after the backdoor channel is invoked *and* to be able to use QEMU internal routines from that code. I also want the mechanism to be as lightweight as possible (i.e., no OS involvement through syscalls to use the device); right now, channel invocation is reduced to just a single write to memory. Is this possible to achieve with virtio-serial or ivshmem? Maybe I just missed the details in them that would allow me to do that without yet another device. > Also, what's the advantage of having a backdoor mechanism both for softmmu and > user? I can't think of a practical use-case for it. The intent is to have the same guest interface to interact with the user-implemented backdoor code, regardless of which QEMU "mode" we're running on (user or softmmu). In the use-mode case, now I can link the application against the backdoor interface library and add some calls to the backdoor in the points I'm interested in. Then moving the app into softmmu would just work without further changes (provided the guest uses the softmmu-capable version of the library). The contents of the user implementation can be arbitrary, although my target is to use it coupled together with the patchset for tracing guest code at the TCG level (which I haven't sent yet in its new form). Thus you could add just a pair of lines in the guest code to enable tracing of the executed guest instructions only for whichever part of the program you're interested in. Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth
Re: [Qemu-devel] Kqemu support in current qemu
Am 29.09.2011 um 18:57 schrieb Ottavio : > Sorry, I had forgotten to add a title > > -- Forwarded message -- > From: Ottavio > Date: 29 September 2011 17:55 > Subject: > To: qemu-devel@nongnu.org > Cc: qemu-us...@yahoogroups.com > > > I wonder if it is possible to compile a newer version of qemu with > (the defunct) kqemu on Windows (XP)? > > The winkvm project doesn't seem to be usable yet. Nobody was willing to maintain kqemu in upstream, so it's long gone. Just use 0.9 if you need it :) Alex >
[Qemu-devel] [PATCH v3] Add AACI audio playback support to the ARM Versatile/PB platform
This driver emulates the ARM AACI interface (PL041) connected to a
LM4549 codec.
It enables audio playback for the Versatile/PB platform.
Limitations:
- Supports only a playback on one channel (Versatile/Vexpress)
- Supports only a TX FIFO in compact-mode.
- Record is not supported.
- The PL041 is hardwired to a LM4549 codec.
Versatile/PB test build:
linux-2.6.38.5
buildroot-2010.11
alsa-lib-1.0.22
alsa-utils-1.0.22
mpg123-0.66
Qemu host: Ubuntu 10.04 in Vmware/OS X
Playback tested successfully with speaker-test/aplay/mpg123.
Signed-off-by: Mathieu Sonet
---
v2->v3
This version takes into account the remarks from Peter Maydell's review:
* Both pl041 and lm4549 source code has been simplified by removing
extraneous abstractions.
* hw_error occurences has been replaced by warnings.
* The FIFO depth is now a qdev property.
* The model now has load/save support.
Makefile.target |1 +
hw/lm4549.c | 326 +++
hw/lm4549.h | 44 +
hw/pl041.c | 501
++
hw/pl041.h | 135 +++
hw/pl041.hx | 81 +
hw/versatilepb.c |8 +
7 files changed, 1096 insertions(+), 0 deletions(-)
create mode 100644 hw/lm4549.c
create mode 100644 hw/lm4549.h
create mode 100644 hw/pl041.c
create mode 100644 hw/pl041.h
create mode 100644 hw/pl041.hx
diff --git a/Makefile.target b/Makefile.target
index 88d2f1f..cb1e86a 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -355,6 +355,7 @@ obj-arm-y += syborg_virtio.o
obj-arm-y += vexpress.o
obj-arm-y += strongarm.o
obj-arm-y += collie.o
+obj-arm-y += pl041.o lm4549.o
obj-sh4-y = shix.o r2d.o sh7750.o sh7750_regnames.o tc58128.o
obj-sh4-y += sh_timer.o sh_serial.o sh_intc.o sh_pci.o sm501.o
diff --git a/hw/lm4549.c b/hw/lm4549.c
new file mode 100644
index 000..55b7105
--- /dev/null
+++ b/hw/lm4549.c
@@ -0,0 +1,326 @@
+/*
+ * LM4549 Audio Codec Interface
+ *
+ * Copyright (c) 2011
+ * Written by Mathieu Sonet - www.elasticsheep.com
+ *
+ * This code is licenced under the GPL.
+ *
+ * *
+ *
+ * This driver emulates the LM4549 codec.
+ *
+ * It supports only one playback voice and no record voice.
+ */
+
+#include "hw.h"
+#include "audio/audio.h"
+#include "lm4549.h"
+
+#if 0
+#define LM4549_DEBUG 1
+#endif
+
+#if 0
+#define LM4549_DUMP_DAC_INPUT 1
+#endif
+
+#ifdef LM4549_DEBUG
+#define DPRINTF(fmt, ...) \
+do { printf("lm4549: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while (0)
+#endif
+
+#if defined(LM4549_DUMP_DAC_INPUT)
+#include
+static FILE *fp_dac_input;
+#endif
+
+/* LM4549 register list */
+enum {
+LM4549_Reset= 0x00,
+LM4549_Master_Volume= 0x02,
+LM4549_Line_Out_Volume = 0x04,
+LM4549_Master_Volume_Mono = 0x06,
+LM4549_PC_Beep_Volume = 0x0A,
+LM4549_Phone_Volume = 0x0C,
+LM4549_Mic_Volume = 0x0E,
+LM4549_Line_In_Volume = 0x10,
+LM4549_CD_Volume= 0x12,
+LM4549_Video_Volume = 0x14,
+LM4549_Aux_Volume = 0x16,
+LM4549_PCM_Out_Volume = 0x18,
+LM4549_Record_Select= 0x1A,
+LM4549_Record_Gain = 0x1C,
+LM4549_General_Purpose = 0x20,
+LM4549_3D_Control = 0x22,
+LM4549_Powerdown_Ctrl_Stat = 0x26,
+LM4549_Ext_Audio_ID = 0x28,
+LM4549_Ext_Audio_Stat_Ctrl = 0x2A,
+LM4549_PCM_Front_DAC_Rate = 0x2C,
+LM4549_PCM_ADC_Rate = 0x32,
+LM4549_Vendor_ID1 = 0x7C,
+LM4549_Vendor_ID2 = 0x7E
+};
+
+static void lm4549_reset(lm4549_state *s)
+{
+uint16_t *regfile = s->regfile;
+
+regfile[LM4549_Reset] = 0x0d50;
+regfile[LM4549_Master_Volume] = 0x8008;
+regfile[LM4549_Line_Out_Volume] = 0x8000;
+regfile[LM4549_Master_Volume_Mono] = 0x8000;
+regfile[LM4549_PC_Beep_Volume] = 0x;
+regfile[LM4549_Phone_Volume]= 0x8008;
+regfile[LM4549_Mic_Volume] = 0x8008;
+regfile[LM4549_Line_In_Volume] = 0x8808;
+regfile[LM4549_CD_Volume] = 0x8808;
+regfile[LM4549_Video_Volume]= 0x8808;
+regfile[LM4549_Aux_Volume] = 0x8808;
+regfile[LM4549_PCM_Out_Volume] = 0x8808;
+regfile[LM4549_Record_Select] = 0x;
+regfile[LM4549_Record_Gain] = 0x8000;
+regfile[LM4549_General_Purpose] = 0x;
+regfile[LM4549_3D_Control] = 0x0101;
+regfile[LM4549_Powerdown_Ctrl_Stat] = 0x000f;
+regfile[LM4549_Ext_Audio_ID]= 0x0001;
+regfile[LM4549_Ext_Audio_Stat_Ctrl] = 0x;
+regfile[LM4549_PCM_Front_DAC_Rate] = 0xBB80;
+regfile[LM4549_PCM_ADC_Rate]= 0xBB80;
+regfile[LM4549_Vendor_ID1] = 0x4e53;
+regfile[LM
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On 2011-09-29 18:06, Amit Shah wrote: > On (Wed) 03 Aug 2011 [13:24:22], Jan Kiszka wrote: >> From: Fabien Chouteau >> >> In the current implementation, if Slirp tries to send an IP packet to a >> client >> with an unknown hardware address, the packet is simply dropped and an ARP >> request is sent (if_encap in slirp/slirp.c). >> >> With this patch, Slirp will send the ARP request, re-queue the packet and try >> to send it later. The packet is dropped after one second if the ARP reply is >> not received. > > This patch causes a segfault when guests wake up from hibernate. > > Recipe: > 1. Start guest with -net user -net nic,model=virtio > 2. (guest) ping 10.0.2.2 > 3. (guest) echo "disk" > /sys/power/state > 4. Re-start guest with same command line > 5. Ping has stopped receiving replies. > 6. Kill that ping process and start a new one. qemu segfaults. Can't reproduce, I'm not getting stable hibernation here even without any network configured. Could you check if the recent pull request [1] changes the picture for you? Thanks, Jan [1] http://thread.gmane.org/gmane.comp.emulators.qemu/118992 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On (Thu) 29 Sep 2011 [19:41:33], Jan Kiszka wrote: > On 2011-09-29 18:06, Amit Shah wrote: > > On (Wed) 03 Aug 2011 [13:24:22], Jan Kiszka wrote: > >> From: Fabien Chouteau > >> > >> In the current implementation, if Slirp tries to send an IP packet to a > >> client > >> with an unknown hardware address, the packet is simply dropped and an ARP > >> request is sent (if_encap in slirp/slirp.c). > >> > >> With this patch, Slirp will send the ARP request, re-queue the packet and > >> try > >> to send it later. The packet is dropped after one second if the ARP reply > >> is > >> not received. > > > > This patch causes a segfault when guests wake up from hibernate. > > > > Recipe: > > 1. Start guest with -net user -net nic,model=virtio > > 2. (guest) ping 10.0.2.2 > > 3. (guest) echo "disk" > /sys/power/state > > 4. Re-start guest with same command line > > 5. Ping has stopped receiving replies. > > 6. Kill that ping process and start a new one. qemu segfaults. > > Can't reproduce, I'm not getting stable hibernation here even without > any network configured. With virtio devices and the patches applied? Can you tell me what you're seeing? > Could you check if the recent pull request [1] changes the picture for you? Thanks, that series fixes the problem. Amit
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On 2011-09-29 19:50, Amit Shah wrote: > On (Thu) 29 Sep 2011 [19:41:33], Jan Kiszka wrote: >> On 2011-09-29 18:06, Amit Shah wrote: >>> On (Wed) 03 Aug 2011 [13:24:22], Jan Kiszka wrote: From: Fabien Chouteau In the current implementation, if Slirp tries to send an IP packet to a client with an unknown hardware address, the packet is simply dropped and an ARP request is sent (if_encap in slirp/slirp.c). With this patch, Slirp will send the ARP request, re-queue the packet and try to send it later. The packet is dropped after one second if the ARP reply is not received. >>> >>> This patch causes a segfault when guests wake up from hibernate. >>> >>> Recipe: >>> 1. Start guest with -net user -net nic,model=virtio >>> 2. (guest) ping 10.0.2.2 >>> 3. (guest) echo "disk" > /sys/power/state >>> 4. Re-start guest with same command line >>> 5. Ping has stopped receiving replies. >>> 6. Kill that ping process and start a new one. qemu segfaults. >> >> Can't reproduce, I'm not getting stable hibernation here even without >> any network configured. > > With virtio devices and the patches applied? Can you tell me what > you're seeing? No, I didn't patch my guest. I was using standard IDE with an emulated NIC (or without) against a 3.1-rc3 (or so) guest. > >> Could you check if the recent pull request [1] changes the picture for you? > > Thanks, that series fixes the problem. Perfect! Right in time. :) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On (Thu) 29 Sep 2011 [19:53:47], Jan Kiszka wrote: > >> Can't reproduce, I'm not getting stable hibernation here even without > >> any network configured. > > > > With virtio devices and the patches applied? Can you tell me what > > you're seeing? > > No, I didn't patch my guest. I was using standard IDE with an emulated > NIC (or without) against a 3.1-rc3 (or so) guest. Strange, using qemu.git and an F14 guest (2.6.38) using this cmd line: ./x86_64-softmmu/qemu-system-x86_64 -m 512 /guests/f14-suspend.qcow2 -net none -enable-kvm -smp 2 I could successfully hibernate and resume. > >> Could you check if the recent pull request [1] changes the picture for you? > > > > Thanks, that series fixes the problem. > > Perfect! Right in time. :) And people say slirp is neglected and unmaintainable :-) Amit
Re: [Qemu-devel] [PATCH v3] Add AACI audio playback support to the ARM Versatile/PB platform
On Thu, 29 Sep 2011, Mathieu Sonet wrote: > This driver emulates the ARM AACI interface (PL041) connected to a LM4549 > codec. > It enables audio playback for the Versatile/PB platform. > > Limitations: > - Supports only a playback on one channel (Versatile/Vexpress) > - Supports only a TX FIFO in compact-mode. > - Record is not supported. > - The PL041 is hardwired to a LM4549 codec. > > Versatile/PB test build: > linux-2.6.38.5 > buildroot-2010.11 > alsa-lib-1.0.22 > alsa-utils-1.0.22 > mpg123-0.66 > > Qemu host: Ubuntu 10.04 in Vmware/OS X > > Playback tested successfully with speaker-test/aplay/mpg123. No objections from me. [..snip..] -- mailto:av1...@comtv.ru
Re: [Qemu-devel] [RFC] Adding new filesystem 'proxy' to 9p
On Wednesday, September 28, 2011 08:29:06 PM Daniel P. Berrange wrote: > On Wed, Sep 28, 2011 at 07:49:34PM +0530, M. Mohan Kumar wrote: > > Pass-through security model in QEMU 9p server needs root privilege to do > > few file operations (like chown, chmod to any mode/uid:gid). There are > > two issues in pass-through security model > > > > 1) TOCTTOU vulnerability: Following symbolic links in the server could > > provide access to files beyond 9p export path. > > > > 2) When libvirt is configured to run qemu as non-root user (for example, > > if qemu is configured to run as normal user 'qemu'), running file > > operations on pass-through security model would fail because it needs > > root privileges. > > > > To overcome above issues, following approach is suggested: A new > > filesytem type 'proxy' is introduced. Proxy FS uses chroot + socket > > combination for securing the vulnerability known with following symbolic > > links. Intention of adding a new filesystem type is to allow qemu to run > > in non-root mode, but doing privileged operations using socket IO. > > > > A new binary (known as proxy helper) will be provided as part of qemu. > > Proxy helper will chroot into 9p export path and create a socket pair or > > a named socket based on the command line parameter. Qemu and proxy > > helper will communicate using this socket. > > > > We need following changes in the libvirt code to accomodate new 'proxy' > > filesystem type: > > If qemu 9p server is configured to use 'proxy' FS, libvirt will do > > * Create a socket pair > > * invoke proxy_helper binary with one of the socket id from the pair as > > command line parameters to it with root privilege > > * invoke qemu with one of socket id from the pair as paramter to qemu > > virtfs after dropping to the configured user privilege. > > > > ie, libvirt will invoke proxy_helper as: > > proxy_helper -i -p <9p-path-to-export> > > > > and qemu will be invoked with following virtfs parameter: > > -virtfs proxy,id=,sock_fd= > > > > ,path=/tmp/,security_model=prox,mount_tag=v_pass > Thank you Daniel for the quick response, I was on leave and I could not respond to you immediately. > Interesting proposal. Explicitly comparing the security characteristics > of running QEMU as root, vs using the proxy helper > > * QEMU run as root > > - QEMU is root, with full capabilities > - QEMU has read/write any file/dir, regardless of whether it is >exported via 9p > > * QEMU run as non-root, with proxy_helper root > > - QEMU is non-root, with no capabilities > - QEMU has write to only files with matching UID/GID > - proxy_helper is root, with full capabilities > - proxy_helper has read/write to any file/dir > > Since QEMU can send arbitrary FS calls to the proxy_helper, the overall > security of the system clearly depends on the security of the proxy_helper > process. QEMU can't send arbitrary FS calls to the proxy helper. All interfaces are defined and if qemu sends arbitrary FS command, proxy helper would return an EIO. For example T_OPEN is one of the supported interface between 9p qemu server and proxy helper. For more information please look at my chroot patchset that I posted to qemu-devel few weeks ago. http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00671.html > > If we assume that QEMU gets exploited, and that QEMU can find some flaw > in the proxy_helper that it can exploit, what damage can the proxy_helper > do ? Clearly we want it to not be able to read/write any files other > than those exported, even when it becomes compromised, ideally also > without requiring SELinux/AppArmour to make it safe. If proxy_helper > is running as root with full capabilities, it can trivially escape > the chroot[1], so this isn't all that nice for overall system security. When proxy helper process is forked, its made sure that all open file descriptor are closed except the socket descriptor, so that proxy helper can't escape chroot jail. Main aim of providing proxy helper is to 1) Access beyond 9p export path should not be given 2) Remove the limitation that qemu should be run by root user to use pass- through security model > The attacker simply needs to find a vulnerability in QEMU and in the > proxy_helper, instead of just in QEMU. We want a stronger guarantee > than that. > > In order to be able to chown/chmod files etc, the proxy_helper is going > to require some elevated privileges, however, this does not actually > imply that proxy_helper needs to run as root. You don't want the > proxy_helper to be allowed todo various other things that root would be > allowed, even if it is inside a chroot. eg you don't want it being allowed > to reboot, mlock, change network setting, mount volumes, make device > nodes, and quite alot more. Proxy helper operations are categorized as: 1) Open/create file and return the descriptor 2) Create directory, link, symbolic link, device nodes, FIFOs
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On 2011-09-29 20:05, Amit Shah wrote: > On (Thu) 29 Sep 2011 [19:53:47], Jan Kiszka wrote: Can't reproduce, I'm not getting stable hibernation here even without any network configured. >>> >>> With virtio devices and the patches applied? Can you tell me what >>> you're seeing? >> >> No, I didn't patch my guest. I was using standard IDE with an emulated >> NIC (or without) against a 3.1-rc3 (or so) guest. > > Strange, using qemu.git and an F14 guest (2.6.38) using this cmd line: > > ./x86_64-softmmu/qemu-system-x86_64 -m 512 /guests/f14-suspend.qcow2 -net > none -enable-kvm -smp 2 > > I could successfully hibernate and resume. -cpu qemu64,-kvmclock makes it work. Would have to check a different kernel version to find out if it's a guest kernel or qemu/kvm issue. > Could you check if the recent pull request [1] changes the picture for you? >>> >>> Thanks, that series fixes the problem. >> >> Perfect! Right in time. :) > > And people say slirp is neglected and unmaintainable :-) Who says this? I think slirp just needed some attention. It already presented two fairly old bugs to me, but strangely right after I adopted it... ;) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH 3/3] Delayed IP packets
On (Thu) 29 Sep 2011 [20:19:42], Jan Kiszka wrote: > On 2011-09-29 20:05, Amit Shah wrote: > > On (Thu) 29 Sep 2011 [19:53:47], Jan Kiszka wrote: > Can't reproduce, I'm not getting stable hibernation here even without > any network configured. > >>> > >>> With virtio devices and the patches applied? Can you tell me what > >>> you're seeing? > >> > >> No, I didn't patch my guest. I was using standard IDE with an emulated > >> NIC (or without) against a 3.1-rc3 (or so) guest. > > > > Strange, using qemu.git and an F14 guest (2.6.38) using this cmd line: > > > > ./x86_64-softmmu/qemu-system-x86_64 -m 512 /guests/f14-suspend.qcow2 -net > > none -enable-kvm -smp 2 > > > > I could successfully hibernate and resume. > > -cpu qemu64,-kvmclock makes it work. Would have to check a different > kernel version to find out if it's a guest kernel or qemu/kvm issue. Aha, yes. I disable kvmclock in my kernels as that has known issues with hibernate. I haven't checked if the 2.6.38 f14 kernel had it disabled, or maybe I didn't hit its problem point soon enough. Amit
Re: [Qemu-devel] [PULL] lm32 fixes and new milkymist hardware support
On 09/15/2011 05:58 PM, Michael Walle wrote: Hi Anthony, here is a patch for target-lm32, which is broken with the current master. Additionally, support for the new uart of the milkymist SoC is added. The following changes since commit ef4f97cba2a354656b00eb8659bf61ab2321fa4e: Merge remote-tracking branch 'qemu-kvm-tmp/memory/core' into staging (2011-09-15 13:33:03 -0500) are available in the git repository at: http://git.serverraum.org/git/mw/qemu-lm32.git for-upstream Please publish a git URI. Fetching over HTTP is painful, particularly when the connection to the server isn't very good. Regards, Anthony Liguori Michael Walle (3): lm32: add missing qemu_init_vcpu() call milkymist_uart: support new core version milkymist: new interrupt map hw/milkymist-hw.h|5 +-- hw/milkymist-uart.c | 72 +++-- hw/milkymist.c | 14 +- target-lm32/helper.c |1 + trace-events |4 +- 5 files changed, 75 insertions(+), 21 deletions(-)
Re: [Qemu-devel] [RFC PATCH 0/2] Replace 9p debug infrastructure with Qemu Tracing
On Thu, Sep 29, 2011 at 06:09:47PM +0530, Harsh Prateek Bora wrote: > This patchset introduces Qemu Tracing to 9p pdu handlers and removes the > existing debug infrastructure which becomes less meaningful after the > introduction of coroutines. Parallel operations creates a messy output and > filtering becomes difficult. With Qemu tracing in place, we can selectively > enable/disable trace-events and the trace log can be further filtered using > analysis scripts. > > Harsh Prateek Bora (2): > Introduce tracing for 9p pdu handlers > Remove virtio-9p-debug.* infra since we are using Qemu Tracing now. > > Makefile.objs |2 +- > hw/9pfs/virtio-9p-debug.c | 646 > - > hw/9pfs/virtio-9p-debug.h |6 - > hw/9pfs/virtio-9p.c | 70 +- > trace-events | 47 > 5 files changed, 110 insertions(+), 661 deletions(-) > delete mode 100644 hw/9pfs/virtio-9p-debug.c > delete mode 100644 hw/9pfs/virtio-9p-debug.h Reviewed-by: Stefan Hajnoczi It would also be neat to wire up 9p pdu's to the pcap code in net/dump.c so it's possible to capture 9p sessions and look at them with wireshark. Stefan
[Qemu-devel] QEMU Live Snapshots / Commiting
Hello, I still have a problem with the "Live Snapshot" feature of QEMU and before migrating to XEN, VMware or something similare, a quick post here: OS: Ubuntu Natty 64bit First, i'm starting my KVM Machine with an image like this: qemu-img create -f qcow2 -o backing_file= If i stop the KVM Machine later, and i commit into , all the new changes are in the . That would be ok. --- The Problem: Actually i'm trying to create "live snapshots" periodically while the machine is running, like this (host2Qemu is just a special function of mine (it works), to send a string to qemu-monitor). host2Qemu "cont" host2Qemu "guest-agent-fsfreeze" host2Qemu "stop" host2Qemu "info block" host2Qemu "snapshot_blkdev ide0-hd0 qcow2" host2Qemu "cont" host2Qemu "guest-agent-fsthaw" My idea is, to commit them one by one afterwards, when the KVM Machine is down into the BaseImage. So, the Snapshots are beeing written, and everytime i call that function new data is beeing written to the new "alllocated" snapshot. BUT, committing of that live-snapshots fails, and i've no idea why ?! I would commit it like that: qemu-img commit -f qcow2 qemu-img commit -f qcow2 qemu-img commit -f qcow2 ... and so on. So in that constellation, only changes from the Snapshot, with KVM was started are in the Base-Image. And another question: I have a Windows XP Guest also in KVM, but the write performance into the (qcow2 Image) (scp, rsync, e.g) Guest seems to be pretty poor - Are there any hints or is there a special Parameter to avoid this? The write Performance to a Linux Guest with a similar configuration and also qcow2 seems to very close to the "native" Performance. Thanks. Robert
Re: [Qemu-devel] [PATCH 16/21] qapi: Convert query-chardev
Looks good, tested qmp/hmp commands.
Reviewed-by: Michael Roth
Tested-by: Michael Roth
On Wed, 28 Sep 2011 11:44:40 -0300, Luiz Capitulino
wrote:
> The original conversion was done by Anthony Liguori. This commit
> is just a rebase.
>
> Signed-off-by: Luiz Capitulino
> ---
> hmp.c| 13 +
> hmp.h|1 +
> monitor.c| 11 +--
> qapi-schema.json | 26 ++
> qemu-char.c | 35 +++
> qmp-commands.hx |6 ++
> 6 files changed, 58 insertions(+), 34 deletions(-)
>
> diff --git a/hmp.c b/hmp.c
> index 1cd40ae..91de86c 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -80,3 +80,16 @@ void hmp_info_uuid(Monitor *mon)
> monitor_printf(mon, "%s\n", info->UUID);
> qapi_free_UuidInfo(info);
> }
> +
> +void hmp_info_chardev(Monitor *mon)
> +{
> +ChardevInfoList *char_info, *info;
> +
> +char_info = qmp_query_chardev(NULL);
> +for (info = char_info; info; info = info->next) {
> +monitor_printf(mon, "%s: filename=%s\n", info->value->label,
> + info->value->filename);
> +}
> +
> +qapi_free_ChardevInfoList(char_info);
> +}
> diff --git a/hmp.h b/hmp.h
> index 49a5971..7388f9a 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -22,5 +22,6 @@ void hmp_info_version(Monitor *mon);
> void hmp_info_kvm(Monitor *mon);
> void hmp_info_status(Monitor *mon);
> void hmp_info_uuid(Monitor *mon);
> +void hmp_info_chardev(Monitor *mon);
>
> #endif
> diff --git a/monitor.c b/monitor.c
> index d294bc9..66b3004 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2777,8 +2777,7 @@ static const mon_cmd_t info_cmds[] = {
> .args_type = "",
> .params = "",
> .help = "show the character devices",
> -.user_print = qemu_chr_info_print,
> -.mhandler.info_new = qemu_chr_info,
> +.mhandler.info = hmp_info_chardev,
> },
> {
> .name = "block",
> @@ -3060,14 +3059,6 @@ static const mon_cmd_t qmp_query_cmds[] = {
> .mhandler.info_new = do_info_commands,
> },
> {
> -.name = "chardev",
> -.args_type = "",
> -.params = "",
> -.help = "show the character devices",
> -.user_print = qemu_chr_info_print,
> -.mhandler.info_new = qemu_chr_info,
> -},
> -{
> .name = "block",
> .args_type = "",
> .params = "",
> diff --git a/qapi-schema.json b/qapi-schema.json
> index b678f07..2ebcb1c 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -176,3 +176,29 @@
> ##
> { 'command': 'query-uuid', 'returns': 'UuidInfo' }
>
> +##
> +# @ChardevInfo:
> +#
> +# Information about a character device.
> +#
> +# @label: the label of the character device
> +#
> +# @filename: the filename of the character device
> +#
> +# Notes: @filename is encoded using the QEMU command line character device
> +#encoding. See the QEMU man page for details.
> +#
> +# Since: 0.14.0
> +##
> +{ 'type': 'ChardevInfo', 'data': {'label': 'str', 'filename': 'str'} }
> +
> +##
> +# @query-chardev:
> +#
> +# Returns information about current character devices.
> +#
> +# Returns: a list of @ChardevInfo
> +#
> +# Since: 0.14.0
> +##
> +{ 'command': 'query-chardev', 'returns': ['ChardevInfo'] }
> diff --git a/qemu-char.c b/qemu-char.c
> index 09d2309..8bdbcfd 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -31,7 +31,7 @@
> #include "hw/usb.h"
> #include "hw/baum.h"
> #include "hw/msmouse.h"
> -#include "qemu-objects.h"
> +#include "qmp-commands.h"
>
> #include
> #include
> @@ -2650,35 +2650,22 @@ void qemu_chr_delete(CharDriverState *chr)
> g_free(chr);
> }
>
> -static void qemu_chr_qlist_iter(QObject *obj, void *opaque)
> +ChardevInfoList *qmp_query_chardev(Error **errp)
> {
> -QDict *chr_dict;
> -Monitor *mon = opaque;
> -
> -chr_dict = qobject_to_qdict(obj);
> -monitor_printf(mon, "%s: filename=%s\n", qdict_get_str(chr_dict,
> "label"),
> - qdict_get_str(chr_dict,
> "filename"));
> -}
> -
> -void qemu_chr_info_print(Monitor *mon, const QObject *ret_data)
> -{
> -qlist_iter(qobject_to_qlist(ret_data), qemu_chr_qlist_iter, mon);
> -}
> -
> -void qemu_chr_info(Monitor *mon, QObject **ret_data)
> -{
> -QList *chr_list;
> +ChardevInfoList *chr_list = NULL;
> CharDriverState *chr;
>
> -chr_list = qlist_new();
> -
> QTAILQ_FOREACH(chr, &chardevs, next) {
> -QObject *obj = qobject_from_jsonf("{ 'label': %s, 'filename': %s }",
> - chr->label, chr->filename);
> -qlist_append_obj(chr_list, obj);
> +ChardevInfoList *info = g_malloc0(sizeof(*info));
> +info->value = g_malloc0(sizeof(*info->value));
> +info->value->label = g_strdup(chr->label);
> +info->value->filename = g_strdup(chr->filename);
> +
Re: [Qemu-devel] [PATCH 17/21] qapi: Convert query-commands
Reviewed-by: Michael Roth
Tested-by: Michael Roth
On Wed, 28 Sep 2011 11:44:41 -0300, Luiz Capitulino
wrote:
> Signed-off-by: Luiz Capitulino
> ---
> monitor.c| 40 +++-
> qapi-schema.json | 23 +++
> qmp-commands.hx |6 ++
> 3 files changed, 44 insertions(+), 25 deletions(-)
>
> diff --git a/monitor.c b/monitor.c
> index 66b3004..d546bad 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -730,39 +730,37 @@ help:
> help_cmd(mon, "info");
> }
>
> -static QObject *get_cmd_dict(const char *name)
> +static CommandInfoList *alloc_cmd_entry(const char *cmd_name)
> {
> -const char *p;
> +CommandInfoList *info;
>
> -/* Remove '|' from some commands */
> -p = strchr(name, '|');
> -if (p) {
> -p++;
> -} else {
> -p = name;
> -}
> +info = g_malloc0(sizeof(*info));
> +info->value = g_malloc0(sizeof(*info->value));
> +info->value->name = g_strdup(cmd_name);
>
> -return qobject_from_jsonf("{ 'name': %s }", p);
> +return info;
> }
>
> -static void do_info_commands(Monitor *mon, QObject **ret_data)
> +CommandInfoList *qmp_query_commands(Error **errp)
> {
> -QList *cmd_list;
> +CommandInfoList *info, *cmd_list = NULL;
> const mon_cmd_t *cmd;
>
> -cmd_list = qlist_new();
> -
> for (cmd = qmp_cmds; cmd->name != NULL; cmd++) {
> -qlist_append_obj(cmd_list, get_cmd_dict(cmd->name));
> +info = alloc_cmd_entry(cmd->name);
> +info->next = cmd_list;
> +cmd_list = info;
> }
>
> for (cmd = qmp_query_cmds; cmd->name != NULL; cmd++) {
> char buf[128];
> snprintf(buf, sizeof(buf), "query-%s", cmd->name);
> -qlist_append_obj(cmd_list, get_cmd_dict(buf));
> +info = alloc_cmd_entry(buf);
> +info->next = cmd_list;
> +cmd_list = info;
> }
>
> -*ret_data = QOBJECT(cmd_list);
> +return cmd_list;
> }
>
> /* get the current CPU defined by the user */
> @@ -3051,14 +3049,6 @@ static const mon_cmd_t qmp_cmds[] = {
>
> static const mon_cmd_t qmp_query_cmds[] = {
> {
> -.name = "commands",
> -.args_type = "",
> -.params = "",
> -.help = "list QMP available commands",
> -.user_print = monitor_user_noop,
> -.mhandler.info_new = do_info_commands,
> -},
> -{
> .name = "block",
> .args_type = "",
> .params = "",
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 2ebcb1c..b26dd25 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -202,3 +202,26 @@
> # Since: 0.14.0
> ##
> { 'command': 'query-chardev', 'returns': ['ChardevInfo'] }
> +
> +##
> +# @CommandInfo:
> +#
> +# Information about a QMP command
> +#
> +# @name: The command name
> +#
> +# Since: 0.14.0
> +##
> +{ 'type': 'CommandInfo', 'data': {'name': 'str'} }
> +
> +##
> +# @query-commands:
> +#
> +# Return a list of supported QMP commands by this server
> +#
> +# Returns: A list of @CommandInfo for all supported commands
> +#
> +# Since: 0.14.0
> +##
> +{ 'command': 'query-commands', 'returns': ['CommandInfo'] }
> +
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index dfc02af..0fda5c3 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -1090,6 +1090,12 @@ Note: This example has been shortened as the real
> response is too long.
>
> EQMP
>
> +{
> +.name = "query-commands",
> +.args_type = "",
> +.mhandler.cmd_new = qmp_marshal_input_query_commands,
> +},
> +
> SQMP
> query-chardev
> -
> --
> 1.7.7.rc0.72.g4b5ea
>
--
Sincerely,
Mike Roth
IBM Linux Technology Center
Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)
On Wed, Sep 28, 2011 at 9:21 PM, Alexander Graf wrote:
>
> On 27.09.2011, at 21:19, Blue Swirl wrote:
>
> On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity wrote:
>
> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>
>
> Well, it's not that easy. As the other mapping is part of an ordinary
>
> BAR,
>
> you need to setup the device (at least PCI_COMMAND and
>
> PCI_BASE_ADDRESS_0)
>
> so it responds to memory requests, and also enable the bridge.
>
> We could hack it by having a low-priority mapping at 0x80013000, but it
>
> seems wrong. Maybe the firmware should configure that BAR first? What
>
> happens on real hardware?
>
> In this message I seem to confess that the address is arbitrary and in
>
> the subsequent messages the overlap with PCI region is also discussed.
>
> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>
> Maybe the address of macio should be fixed as Laurent suggested.
>
> I'll leave it up to you - I'm out of my depth here.
>
> Meanwhile I suggest applying the pci alias patch - the bug is independent of
>
> the vga issue.
>
> OK, pushed.
>
>
> Ah, after digging into the issue for a while myself I stumbled over this
> thread, explaining what I figured would be the culprit. Please CC qemu-ppc
> for these discussions :).
> Either way, I'm seeing 2 issues here. I enhanced the "info mtree" command to
> also display the region we're currently looking at, so the first tuple shows
> the region we're in, the second tuple the region we're trying to map into
> the first region (addresses aligned on each other). I also print out alias
> information directly:
That way you miss for example vga.chain4.
> [ -7ffe ] -7ffe : system
> [ 80013000-8001303f ] 80013000-8001303f : escc
> [ fee0-fee00fff ] fee0-fee00fff : pci-data-idx
> [ fec0-fec00fff ] fec0-fec00fff : pci-conf-idx
> [ 8000-fdff ] 8000-fdff : pci-hole
> -> alias (8000, )
> [ 8000-fdff ] - : pci-mmio
> [ 8088-808f ] 8088-808f : macio
> [ 808e-808f ] 808e-808f : macio-nvram
> [ 808a-808a0fff ] 808a-808a0fff : pmac-ide
> [ 80896000-80897fff ] 80896000-80897fff : cuda
> [ 80893000-8089303f ] 80893000-8089303f : escc-bar
> -> alias (, 80013000)
> [ 80893000-8089303f ] 80893000-8089303f : escc
> [ 80888000-80888fff ] 80888000-80888fff : dbdma
> [ 8088-80880fff ] 8088-80880fff : heathrow-pic
> [ 8080-8080 ] 8080-8080 : vga.rom
> [ 8000-807f ] 8000-807f : vga.vram
> [ fe00-fe1f ] fe00-fe1f : isa-mmio
> I/O
> [ - ] - : io
> [ 0700-070f ] 0700-070f : cmd646-bmdma
> [ 070c-070f ] 070c-070f : cmd646-bmdma-ioport
> [ 0708-070b ] 0708-070b : cmd646-bmdma-bus
> [ 0704-0707 ] 0704-0707 : cmd646-bmdma-ioport
> [ 0700-0703 ] 0700-0703 : cmd646-bmdma-bus
> [ 0680-0683 ] 0680-0683 : cmd646-cmd
> [ 0600-0607 ] 0600-0607 : cmd646-data
> [ 0580-0583 ] 0580-0583 : cmd646-cmd
> [ 0500-0507 ] 0500-0507 : cmd646-data
> [ 0400-04ff ] 0400-04ff : ne2000
> I did another small hack to display the flat memory view:
> ranges[0] = { 8000, 13000 } vga.vram
> ranges[1] = { 80013000, 40 } escc
> ranges[2] = { 80013040, 7ecfc0 } vga.vram
> ranges[3] = { 8080, 1 } vga.rom
> ranges[4] = { 8088, 1000 } heathrow-pic
> ranges[5] = { 80888000, 1000 } dbdma
> ranges[6] = { 80893000, 40 } escc
> ranges[7] = { 80896000, 2000 } cuda
> ranges[8] = { 808a, 1000 } pmac-ide
> ranges[9] = { 808e, 2 } macio-nvram
> ranges[10] = { fe00, 20 } isa-mmio
> ranges[11] = { fec0, 1000 } pci-conf-idx
> ranges[12] = { fee0, 1000 } pci-data-idx
> Now to the issues:
> 1)
> ESCC is mapped inside the VGA region. That's what you discussed in this
> thread. It's wrong. Please check this bug for a dump of a real G3 Beige's
> memory layout:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555651
> I don't think we really need to have serial available before PCI enum, so
> let's just ditch the first map.
OK, though it would be useful for -nographic mode. OpenBIOS can queue
the output until a serial device has been probed and then print the
buffer, but if it crashes before that, we're out of luck.
BTW, -nographic does not work anymore for PPC, there is no output.
> 2)
> vga.vram continues to be mapped, but apparently isn't accessible. I would
> expect the hole of 40 bytes to be non-accessible / broken, but what ends up
> happening is that the whole second region apparently is unusable. What
> exactly is going on there? Sounds like a memory API bug to me.
>
> Alex
Re: [Qemu-devel] [PATCH 21/22] monitor: Restrict pic/irq_info to supporting targets
On Wed, Sep 28, 2011 at 9:26 PM, Jan Kiszka wrote:
> On 2011-09-28 20:19, Blue Swirl wrote:
>>
>> On Wed, Sep 28, 2011 at 11:01 AM, Jan Kiszka
>> wrote:
>>>
>>> Signed-off-by: Jan Kiszka
>>> ---
>>> hw/an5206.c | 10 --
>>> hw/arm_pic.c | 11 ---
>>> hw/cris_pic_cpu.c | 6 --
>>> hw/etraxfs.h | 1 +
>>> hw/lm32_pic.c | 4 ++--
>>> hw/lm32_pic.h | 3 +++
>>> hw/microblaze_pic_cpu.c | 6 --
>>> hw/s390-virtio.c | 11 ---
>>> hw/shix.c | 11 ---
>>> hw/slavio_intctl.c | 14 ++
>>> hw/sun4m.c | 16 ++--
>>> hw/sun4m.h | 6 --
>>> hw/sun4u.c | 8
>>> hw/xtensa_pic.c | 10 --
>>> monitor.c | 21 +
>>> 15 files changed, 43 insertions(+), 95 deletions(-)
>>>
>>> diff --git a/hw/an5206.c b/hw/an5206.c
>>> index 481ae60..3fe1f00 100644
>>> --- a/hw/an5206.c
>>> +++ b/hw/an5206.c
>>> @@ -7,7 +7,6 @@
>>> */
>>>
>>> #include "hw.h"
>>> -#include "pc.h"
>>> #include "mcf.h"
>>> #include "boards.h"
>>> #include "loader.h"
>>> @@ -18,15 +17,6 @@
>>> #define AN5206_MBAR_ADDR 0x1000
>>> #define AN5206_RAMBAR_ADDR 0x2000
>>>
>>> -/* Stub functions for hardware that doesn't exist. */
>>> -void pic_info(Monitor *mon)
>>> -{
>>> -}
>>> -
>>> -void irq_info(Monitor *mon)
>>> -{
>>> -}
>>> -
>>> /* Board init. */
>>>
>>> static void an5206_init(ram_addr_t ram_size,
>>> diff --git a/hw/arm_pic.c b/hw/arm_pic.c
>>> index 985148a..4e63845 100644
>>> --- a/hw/arm_pic.c
>>> +++ b/hw/arm_pic.c
>>> @@ -8,19 +8,8 @@
>>> */
>>>
>>> #include "hw.h"
>>> -#include "pc.h"
>>> #include "arm-misc.h"
>>>
>>> -/* Stub functions for hardware that doesn't exist. */
>>> -void pic_info(Monitor *mon)
>>> -{
>>> -}
>>> -
>>> -void irq_info(Monitor *mon)
>>> -{
>>> -}
>>> -
>>> -
>>> /* Input 0 is IRQ and input 1 is FIQ. */
>>> static void arm_pic_cpu_handler(void *opaque, int irq, int level)
>>> {
>>> diff --git a/hw/cris_pic_cpu.c b/hw/cris_pic_cpu.c
>>> index 7f1e4ab..06ae484 100644
>>> --- a/hw/cris_pic_cpu.c
>>> +++ b/hw/cris_pic_cpu.c
>>> @@ -24,16 +24,10 @@
>>>
>>> #include "sysbus.h"
>>> #include "hw.h"
>>> -#include "pc.h"
>>> #include "etraxfs.h"
>>>
>>> #define D(x)
>>>
>>> -void pic_info(Monitor *mon)
>>> -{}
>>> -void irq_info(Monitor *mon)
>>> -{}
>>> -
>>> static void cris_pic_cpu_handler(void *opaque, int irq, int level)
>>> {
>>> CPUState *env = (CPUState *)opaque;
>>> diff --git a/hw/etraxfs.h b/hw/etraxfs.h
>>> index 1554b0b..24e8fd8 100644
>>> --- a/hw/etraxfs.h
>>> +++ b/hw/etraxfs.h
>>> @@ -22,6 +22,7 @@
>>> * THE SOFTWARE.
>>> */
>>>
>>> +#include "net.h"
>>> #include "etraxfs_dma.h"
>>>
>>> qemu_irq *cris_pic_init_cpu(CPUState *env);
>>> diff --git a/hw/lm32_pic.c b/hw/lm32_pic.c
>>> index 02941a7..8dd0050 100644
>>> --- a/hw/lm32_pic.c
>>> +++ b/hw/lm32_pic.c
>>> @@ -39,7 +39,7 @@ struct LM32PicState {
>>> typedef struct LM32PicState LM32PicState;
>>>
>>> static LM32PicState *pic;
>>> -void pic_info(Monitor *mon)
>>> +void lm32_do_pic_info(Monitor *mon)
>>> {
>>> if (pic == NULL) {
>>> return;
>>> @@ -49,7 +49,7 @@ void pic_info(Monitor *mon)
>>> pic->im, pic->ip, pic->irq_state);
>>> }
>>>
>>> -void irq_info(Monitor *mon)
>>> +void lm32_irq_info(Monitor *mon)
>>> {
>>> int i;
>>> uint32_t count;
>>> diff --git a/hw/lm32_pic.h b/hw/lm32_pic.h
>>> index e6479b8..14456f3 100644
>>> --- a/hw/lm32_pic.h
>>> +++ b/hw/lm32_pic.h
>>> @@ -8,4 +8,7 @@ uint32_t lm32_pic_get_im(DeviceState *d);
>>> void lm32_pic_set_ip(DeviceState *d, uint32_t ip);
>>> void lm32_pic_set_im(DeviceState *d, uint32_t im);
>>>
>>> +void lm32_do_pic_info(Monitor *mon);
>>> +void lm32_irq_info(Monitor *mon);
>>> +
>>> #endif /* QEMU_HW_LM32_PIC_H */
>>> diff --git a/hw/microblaze_pic_cpu.c b/hw/microblaze_pic_cpu.c
>>> index 9ad48b4..8b5623c 100644
>>> --- a/hw/microblaze_pic_cpu.c
>>> +++ b/hw/microblaze_pic_cpu.c
>>> @@ -23,16 +23,10 @@
>>> */
>>>
>>> #include "hw.h"
>>> -#include "pc.h"
>>> #include "microblaze_pic_cpu.h"
>>>
>>> #define D(x)
>>>
>>> -void pic_info(Monitor *mon)
>>> -{}
>>> -void irq_info(Monitor *mon)
>>> -{}
>>> -
>>> static void microblaze_pic_cpu_handler(void *opaque, int irq, int level)
>>> {
>>> CPUState *env = (CPUState *)opaque;
>>> diff --git a/hw/s390-virtio.c b/hw/s390-virtio.c
>>> index acbf026..778cffe 100644
>>> --- a/hw/s390-virtio.c
>>> +++ b/hw/s390-virtio.c
>>> @@ -62,17 +62,6 @@
>>> static VirtIOS390Bus *s390_bus;
>>> static CPUState **ipi_states;
>>>
>>> -void irq_info(Monitor *mon);
>>> -void pic_info(Monitor *mon);
>>> -
>>> -void irq_info(Monitor *mon)
>>> -{
>>> -}
>>> -
>>> -void pic_info(Monitor *mon)
>>> -{
>>> -}
>>> -
>>> CPUState *s390_cpu_addr2state(uint16_t cpu_addr)
>>> {
>>> if (cpu_addr>= smp_cpus) {
>>> diff --git a/hw/shix
Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset
On Wed, Sep 28, 2011 at 9:38 PM, Peter Maydell wrote: > On 28 September 2011 19:42, Blue Swirl wrote: >> We also assume that the reset states of devices and their outputs are >> coherent i.e. the output of one device during reset would not change >> the state of another device from its reset state. > > This seems a very dubious assumption to make. Consider the > realview board: the 'card present' line from the pl181 > MMC card controller is wired up to (1) a GPIO input on the > 'sysctl' system register module [which causes it to appear > as a status bit in a register] and (2) via an inverter to > an input on a pl061 GPIO module. On coming out of reset > something has to be done to make the reset value of the > output from the pl181 be reflected in the internal status > of the sysctl and pl061 devices. > > (On real hardware this happens when the pl061/sysctl > devices come out of reset and sample their input pins. > If we wanted to model it that way we'd need internal state > on all gpio lines and a two phase "enter reset"+"leave reset" > or something.) Maybe the rule should be that during reset, all inputs should be in high impedance mode. We'd need a two-phase reset for QEMU for that too, or to disconnect all signals before reset and then reconnect them after that.
Re: [Qemu-devel] [PATCH 11/22] i8259: Update IRQ state after reset
On Wed, Sep 28, 2011 at 9:18 PM, Jan Kiszka wrote: > On 2011-09-28 20:01, Blue Swirl wrote: >> >> On Wed, Sep 28, 2011 at 11:00 AM, Jan Kiszka >> wrote: >>> >>> As we clearly modify the PIC state on pic_reset, we also have to update >>> the IRQ output. This only happened on init so far. Apply this >>> consistently. >> >> Nack, IRQ lines shouldn't be touched on reset. The other side may not >> be ready for receiving the interrupt change and qemu_irqs are >> stateless anyway. > > Sorry, but failing to clear the line (this is what pic_update_irq will > effectively do) is a clear bug in the current code. This patch is 100% > analogue to what, e.g. the PCI layer does on reset. Please re-read. Reset will happen also when the devices are created. At that time, qemu_irq callback triggered by changing of the state may produce undesired effects on the other side. There have been bugs earlier, see bc26e55a6615dc594be425d293db40d5cdcdb84b and 42f1ced228c9b616cfa2b69846025271618e4ef5 and discussion in http://lists.nongnu.org/archive/html/qemu-devel/2009-06/msg01024.html.
Re: [Qemu-devel] [PATCH v4] tcg-i386: Introduce limited deposit support
On 09/29/2011 09:52 AM, Jan Kiszka wrote: > x86 cannot provide an optimized generic deposit implementation. But at > least for a few special cases, namely for writing bits 0..7, 8..15, and > 0..15, versions using only a single instruction are feasible. > Introducing such limited support improves emulating 16-bit x86 code on > x86, but also rarer cases where 32-bit or 64-bit code accesses bytes or > words. > > Signed-off-by: Jan Kiszka > --- > > Changes in v4: > - provide correct default TCG_TARGET_deposit_i32_valid > > Changes in v3: > - provide default TCG_TARGET_deposit_i32_valid - just in case > > Changes in v2: > - introduce restricting predicates TCG_TARGET_deposit_i32/64_valid >to decide if deposit support can be used > - express register constraints via new 'Q' symbol > > tcg/i386/tcg-target.c | 24 > tcg/i386/tcg-target.h |9 +++-- > tcg/tcg-op.h |4 ++-- > tcg/tcg.h |7 +++ > 4 files changed, 40 insertions(+), 4 deletions(-) Reviewed-by: Richard Henderson r~
Re: [Qemu-devel] [PATCH 0/2] [PULL] slirp: Small fixes
On 09/28/2011 06:12 AM, Jan Kiszka wrote: The following changes since commit 46f3069cba94aab44b3b4f87bc270759b4a700fa: PPC: use memory API to construct the PCI hole (2011-09-27 19:16:46 +) are available in the git repository at: git://git.kiszka.org/qemu.git queues/slirp Pulled. Thanks. Regards, Anthony Liguori CC: Fabien Chouteau CC: Thomas Huth Jan Kiszka (1): slirp: Fix use after release on tcp_input Thomas Huth (1): slirp: Fix packet expiration slirp/mbuf.h |5 +++-- slirp/tcp_input.c | 22 ++ 2 files changed, 13 insertions(+), 14 deletions(-)
Re: [Qemu-devel] [PULL] VirtFS update
On 09/27/2011 04:11 AM, Aneesh Kumar K.V wrote: The following changes since commit d85a1302a91912c52cdc3fe459b313848a8a0792: Merge remote-tracking branch 'kwolf/for-anthony' into staging (2011-09-22 10:31:26 -0500) are available in the git repository at: git://repo.or.cz/qemu/v9fs.git for-upstream-5 Pulled. Thanks. Regards, Anthony Liguori Aneesh Kumar K.V (8): hw/9pfs: Make v9fs_string* functions non-static hw/9pfs: Use read-write lock for protecting fid path. hw/9pfs: Move fid pathname tracking to seperate data type. hw/9pfs: Add init callback to fs driver hw/9pfs: Add fs driver specific details to fscontext hw/9pfs: Avoid unnecessary get_fid in v9fs_clunk hw/9pfs: Implement TFLUSH operation hw/9pfs: Add handle based fs driver Makefile.objs |8 +- fsdev/file-op-9p.h | 54 ++- fsdev/qemu-fsdev.c |1 + fsdev/qemu-fsdev.h |1 + hw/9pfs/codir.c| 64 +++- hw/9pfs/cofile.c | 110 +-- hw/9pfs/cofs.c | 195 ++-- hw/9pfs/coxattr.c | 41 ++- hw/9pfs/virtio-9p-coth.h | 72 +++-- hw/9pfs/virtio-9p-device.c | 10 +- hw/9pfs/virtio-9p-handle.c | 611 + hw/9pfs/virtio-9p-local.c | 213 +--- hw/9pfs/virtio-9p.c| 820 hw/9pfs/virtio-9p.h| 50 +++- 14 files changed, 1712 insertions(+), 538 deletions(-) create mode 100644 hw/9pfs/virtio-9p-handle.c
Re: [Qemu-devel] [PATCH] Remove line buffering from log file
On Thu, Sep 29, 2011 at 7:57 AM, Peter Maydell wrote: > On 29 September 2011 06:03, Peter Chubb wrote: >> Stefan> That's the reason why line buffering is needed today. I >> Stefan> enable log file output to see what happened last before the >> Stefan> crash. >> >> Thanks for this, I didn't think of this use-case. I don't think I've >> ever seen a qemu crash that wasn't caused by something really obvious. > > You don't need the logging for the obvious ones :-) > >> abort() already flushes all open streams. So only signals that cause >> immediate death are a problem: SIGSEGV is the obvious one. If its >> handler called abort() then that would flush too. abort() is >> guaranteed by the POSIX spec to be callable from a signal handler. > > Catching SIGSEGV is likely to interact badly with the signal > handling in linux-user mode, I expect. > >> Stefan> Speed is not the primary target when somebody runs qemu -d ... >> >> It is if it takes hours to reach the problem that causes >> the abort(). Speeding up by an order of magnitude is worth it. > > One tactic I've found useful in these cases is to run without > logging up to nearly the point where things fail, and then > do a savevm. Then you can loadvm on a qemu with logging enabled > and only look at the section of execution that causes the problem. This sounds like it should be possible to enable and disable logging during run time. The performance could be improved by taking a trace point like approach, where all possible processing is postponed to outside process. Guest and host code disassembly and op printout could be left to postprocessing, the logs should contain only binary data.
Re: [Qemu-devel] [PATCH 14/21] qapi: Convert query-status
On Wed, 28 Sep 2011 11:44:38 -0300, Luiz Capitulino
wrote:
> The original conversion was done by Anthony Liguori. This commit
> is just a rebase.
>
> Signed-off-by: Luiz Capitulino
> ---
> hmp.c| 19 +++
> hmp.h|1 +
> monitor.c| 41 +
> qapi-schema.json | 67
> ++
> qmp-commands.hx |6 +
> vl.c | 12 +
> 6 files changed, 106 insertions(+), 40 deletions(-)
>
> diff --git a/hmp.c b/hmp.c
> index 94a7f74..9e7f07e 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -53,3 +53,22 @@ void hmp_info_kvm(Monitor *mon)
> qapi_free_KvmInfo(info);
> }
>
> +void hmp_info_status(Monitor *mon)
> +{
> +StatusInfo *info;
> +
> +info = qmp_query_status(NULL);
> +
> +monitor_printf(mon, "VM status: %s%s",
> + info->running ? "running" : "paused",
> + info->singlestep ? " (single step mode)" : "");
> +
> +if (!info->running && info->status != VM_RUN_STATUS_PAUSED) {
> +monitor_printf(mon, " (%s)", VmRunStatus_lookup[info->status]);
> +}
> +
> +monitor_printf(mon, "\n");
> +
> +qapi_free_StatusInfo(info);
> +}
> +
> diff --git a/hmp.h b/hmp.h
> index a93ac1f..df4242f 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -20,5 +20,6 @@
> void hmp_info_name(Monitor *mon);
> void hmp_info_version(Monitor *mon);
> void hmp_info_kvm(Monitor *mon);
> +void hmp_info_status(Monitor *mon);
>
> #endif
> diff --git a/monitor.c b/monitor.c
> index edb56b9..f641504 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2544,36 +2544,6 @@ static int do_inject_nmi(Monitor *mon, const QDict
> *qdict, QObject **ret_data)
> }
> #endif
>
> -static void do_info_status_print(Monitor *mon, const QObject *data)
> -{
> -QDict *qdict;
> -const char *status;
> -
> -qdict = qobject_to_qdict(data);
> -
> -monitor_printf(mon, "VM status: ");
> -if (qdict_get_bool(qdict, "running")) {
> -monitor_printf(mon, "running");
> -if (qdict_get_bool(qdict, "singlestep")) {
> -monitor_printf(mon, " (single step mode)");
> -}
> -} else {
> -monitor_printf(mon, "paused");
> -}
> -
> -status = qdict_get_str(qdict, "status");
> -if (strcmp(status, "paused") && strcmp(status, "running")) {
> -monitor_printf(mon, " (%s)", status);
> -}
> -
> -monitor_printf(mon, "\n");
> -}
> -
> -static void do_info_status(Monitor *mon, QObject **ret_data)
> -{
> -*ret_data = qobject_from_jsonf("{ 'running': %i, 'singlestep': %i,
> 'status': %s }", runstate_is_running(), singlestep, runstate_as_string());
> -}
> -
> static qemu_acl *find_acl(Monitor *mon, const char *name)
> {
> qemu_acl *acl = qemu_acl_find(name);
> @@ -2966,8 +2936,7 @@ static const mon_cmd_t info_cmds[] = {
> .args_type = "",
> .params = "",
> .help = "show the current VM status (running|paused)",
> -.user_print = do_info_status_print,
> -.mhandler.info_new = do_info_status,
> +.mhandler.info = hmp_info_status,
> },
> {
> .name = "pcmcia",
> @@ -3149,14 +3118,6 @@ static const mon_cmd_t qmp_query_cmds[] = {
> .mhandler.info_new = do_pci_info,
> },
> {
> -.name = "status",
> -.args_type = "",
> -.params = "",
> -.help = "show the current VM status (running|paused)",
> -.user_print = do_info_status_print,
> -.mhandler.info_new = do_info_status,
> -},
> -{
> .name = "mice",
> .args_type = "",
> .params = "",
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 641f12d..de0f807 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -85,3 +85,70 @@
> ##
> { 'command': 'query-kvm', 'returns': 'KvmInfo' }
>
> +##
> +# @VmRunStatus
> +#
> +# An enumation of VM run status.
> +#
Maybe add a description for no-status here for completeness
> +# @debug: QEMU is running on a debugger
> +#
> +# @inmigrate: guest is paused waiting for an incoming migration
> +#
> +# @internal-error: An internal error that prevents further guest execution
> +# has occurred
> +#
> +# @io-error: the last IOP has failed and the device is configured to pause
> +# on I/O errors
> +#
> +# @paused: guest has been paused via the 'stop' command
> +#
> +# @postmigrate: guest is paused following a successful 'migrate'
> +#
> +# @prelaunch: QEMU was started with -S and guest has not started
> +#
> +# @finish-migrate: guest is paused to finish the migration process
> +#
> +# @restore-vm: guest is paused to restore VM state
> +#
> +# @running: guest is actively running
> +#
> +# @save-vm: guest is paused to save the VM state
> +#
> +# @shutdown: guest is shut down (and -no-shutdown is in use)
> +#
> +# @watchdog: the watchdog action is configured to pause and has been
> triggered
> +##
> +{ 'enum': '
Re: [Qemu-devel] Bug in helper_pcmpestrm and helper_pcmpistrm
On Thu, Sep 29, 2011 at 8:12 AM, Frank Mehnert wrote:
> Hi,
>
> the two functions helper_pcmpestrm() and helper_pcmpistrm() in
> target-i386/ops_sse.h contain obviously typos. I think that at
> all 4 marked places should increment the index 'i', not decrement
> it during the loop:
>
>
> void glue(helper_pcmpestrm, SUFFIX) (Reg *d, Reg *s, uint32_t ctrl)
> {
> int i;
> unsigned int res = pcmpxstrx(d, s, ctrl,
> pcmp_elen(R_EDX, ctrl),
> pcmp_elen(R_EAX, ctrl));
>
> if ((ctrl >> 6) & 1) {
> if (ctrl & 1)
> for (i = 0; i <= 8; i--, res >>= 1)
> ^^^
> d->W(i) = (res & 1) ? ~0 : 0;
I think this line will also fill the entire memory with 0xff and 0x00.
Please make a patch, http://wiki.qemu.org/Contribute/SubmitAPatch
should tell how (seems to be down ATM).
> else
> for (i = 0; i <= 16; i--, res >>= 1)
>
> d->B(i) = (res & 1) ? ~0 : 0;
> } else {
> d->Q(1) = 0;
> d->Q(0) = res;
> }
> }
>
>
> void glue(helper_pcmpistrm, SUFFIX) (Reg *d, Reg *s, uint32_t ctrl)
> {
> int i;
> unsigned int res = pcmpxstrx(d, s, ctrl,
> pcmp_ilen(s, ctrl),
> pcmp_ilen(d, ctrl));
>
> if ((ctrl >> 6) & 1) {
> if (ctrl & 1)
> for (i = 0; i <= 8; i--, res >>= 1)
> ^^^
> d->W(i) = (res & 1) ? ~0 : 0;
> else
> for (i = 0; i <= 16; i--, res >>= 1)
>
> d->B(i) = (res & 1) ? ~0 : 0;
> } else {
> d->Q(1) = 0;
> d->Q(0) = res;
> }
> }
>
>
> Kind regards,
>
> Frank
> --
> Dr.-Ing. Frank Mehnert
> Senior Manager Software Development Desktop Virtualization, VirtualBox
> ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany
>
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
>
Re: [Qemu-devel] [PATCH v1 00/21]: First round of QAPI conversions
On Thu, 29 Sep 2011 10:52:30 -0300, Luiz Capitulino wrote: > On Thu, 29 Sep 2011 07:55:37 -0500 > Anthony Liguori wrote: > > > On 09/28/2011 09:44 AM, Luiz Capitulino wrote: > > > This series is a bundle of three things: > > > > > > 1. Patches 01 to 04 add the middle mode feature to the current QMP > > > server. > > > That mode allows for the current server to support QAPI commands. The > > > Original author is Anthony, you can find his original post here: > > > > > > > > > http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00374.html > > > > > > 2. Patches 05 to 10 are fixes from Anthony and Michael to the QAPI > > > handling of the list type. > > > > > > 3. Patches 11 to 21 are simple monitor commands conversions to the QAPI. > > > This is just a rebase of a previous conversion work by Anthony. > > > > Great series! > > > > Other than the one minor comment re: strdup and commit messages, I think > > it's > > ready to go. > > Actually, I've found a few small problems with the enumeration in > patch 14: > > 1. I'm not using VmRunStatus internally in QEMU, I'm using RunState (which > has to be dropped, right? - Is VmRunStatus a good name btw?) Ideally, yes, especially since you're directly assigning enum values from RunState to VmRunStatus. VmRunStatus seems reasonable to me, though if you call it RunState you can just drop the previous declaration of RunState to convert everythin over to using the schema definition. > > 2. RunState has a RSTATE_NO_STATE enum, which is used for initialization. To > have that in VmRunStatus I had to add a 'no-status' value in the schema, > is that ok? Seems fine to me... the visitor routine assumes enumeration for schema-defined enums starts at 0, so if that corresponds to RSTATE_NO_STATE you're fine. > > 3. The code generator is replacing "-" by "_" (eg. 'no-status becomes > 'no_status') but I have already fixed this and will include the patch > in v2 Sounds good. > > Also, it would be nice if Michael could review how I'm doing lists in > patches 16 and 17. > Sure, reviewed those and they look good. Also did some quick tests on all the converted commands and didn't notice any other issues. > Thanks! > > > > > Regards, > > > > Anthony Liguori > > > > > > > > Makefile| 12 ++ > > > Makefile.objs |3 + > > > Makefile.target |6 +- > > > error.c |4 + > > > hmp-commands.hx | 11 +- > > > hmp.c | 116 ++ > > > hmp.h | 31 + > > > monitor.c | 273 > > > +-- > > > qapi-schema.json| 273 > > > +++ > > > qapi/qapi-dealloc-visitor.c | 34 +- > > > qapi/qapi-types-core.h |3 + > > > qapi/qmp-input-visitor.c|4 +- > > > qapi/qmp-output-visitor.c | 20 +++- > > > qemu-char.c | 35 ++ > > > qerror.c| 33 + > > > qerror.h|2 + > > > qmp-commands.hx | 57 +++-- > > > qmp.c | 92 +++ > > > scripts/qapi-commands.py| 98 --- > > > scripts/qapi-types.py |5 + > > > scripts/qapi-visit.py |4 +- > > > scripts/qapi.py |4 +- > > > test-qmp-commands.c | 29 + > > > test-visitor.c | 48 +++-- > > > vl.c| 12 ++ > > > 25 files changed, 877 insertions(+), 332 deletions(-) > > > > > > > > > -- Sincerely, Mike Roth IBM Linux Technology Center
Re: [Qemu-devel] When do we need to do TB unchaining?
On Thu, Sep 29, 2011 at 7:55 AM, 陳韋任 wrote: > Hi, all > > I am looking for when TB unchaining is needed. Currently, I > can only see there are three spots (take i386-softmmu as an > example): > > 1. cpu_interrupt: > > When virtual devices raise interrupts, eventually apic_local_deliver > (apic.c) will call cpu_interrupt. cpu_interrupt will set up > env->interrupt_request, then call cpu_unlink_tb to unlink env's > TBs. > > Here I have a question. I though cpu_interrupt is only used > in system mode to deliever virtual devices' interrupt. But it > seems process mode also has cpu_interrupt. > > I have ran some small programs in process mode under GDB, but > I never see cpu_interrupt is called. Do I have to run something > bigger to see when cpu_interrupt is called in process mode? Or > cpu_interrupt in process mode is only used in some rare cases? I don't think it is possible. The only non-device cases for x86 are tb_invalidate_phys_page_range(), cpu_x86_set_a20() and do_inject_x86_mce(), none of which should be reachable from user emulator. Maybe these should be #ifdeffed out from user emulator builds. > 2. cpu_exit: > > QEMU will register a host SIGALRM handler, host_alarm_handler > (qemu-timer.c), when initialize the enviroment in system mode. > Then when host OS delivers SIGALRM to QEMU, host_alarm_handler > calls qemu_notify_event -> cpu_exit. cpu_exit raise env->exit_request > , then call cpu_unlink_tb to unlink env's TBs. > > There are other places where cpu_exit is called, like > > - cpu_signal: I think this is used when IOTHREAD is enabled. > > - DMA_init: I guess cpu_exit is called when DMA is done so > that control is gave back to QEMU from the code > cache. Yes, this is a questionable hack to improve performance. Maybe it's also not needed anymore since I/O thread was enabled. > - gdb_do_syscall: Don't know when it get called. > > - vm_stop -> cpu_stop_current: Don't know when it get called. grep -r is your friend. > 3. tb_phys_invalidate: > > QEMU will invalidate TBs related to a guest page which is > done by tb_invalidate_phys_page_range (exec.c), then > tb_invalidate_phys_page_range calls tb_phys_invalidate to > invalidate a TB and unlink links to the TB. > > > Please correct me if I am wrong or something miss. Thanks! > > > Regards, > chenwj > > -- > Wei-Ren Chen (陳韋任) > Computer Systems Lab, Institute of Information Science, > Academia Sinica, Taiwan (R.O.C.) > Tel:886-2-2788-3799 #1667 > >
Re: [Qemu-devel] [PATCH 4/5] backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a"
2011/9/29 Lluís Vilanova :
> Uses a virtual device to proxy uses of the backdoor communication channel to
> the
> user-provided code.
>
> Signed-off-by: Lluís Vilanova
> ---
> Makefile.objs | 1
> backdoor/qemu/softmmu.c | 124
> +++
> hw/pci.h | 1
> 3 files changed, 126 insertions(+), 0 deletions(-)
> create mode 100644 backdoor/qemu/softmmu.c
>
> diff --git a/Makefile.objs b/Makefile.objs
> index d39074d..5f54d10 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -398,6 +398,7 @@ $(trace-obj-y): $(GENERATED_HEADERS)
> # backdoor
>
> backdoor-nested-$(CONFIG_USER_ONLY) += user.o
> +backdoor-nested-$(CONFIG_SOFTMMU) += softmmu.o
>
> backdoor-obj-y += $(addprefix backdoor/qemu/, $(backdoor-nested-y))
>
> diff --git a/backdoor/qemu/softmmu.c b/backdoor/qemu/softmmu.c
> new file mode 100644
> index 000..fdd3a25
> --- /dev/null
> +++ b/backdoor/qemu/softmmu.c
> @@ -0,0 +1,124 @@
> +/*
> + * QEMU-side management of backdoor channels in softmmu emulation.
> + *
> + * Copyright (C) 2011 Lluís Vilanova
> + *
> + * 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/pci.h"
> +#include "backdoor/qemu/qemu-backdoor.h"
> +
> +
> +#define PAGE_SIZE TARGET_PAGE_SIZE
> +#define CTRL_BYTES sizeof(uint64_t)
> +
> +
> +typedef struct State
> +{
> + PCIDevice dev;
> +
> + uint8_t pages;
> + uint64_t size;
> +
> + uint64_t cmd;
> +
> + void *data_ptr;
> + MemoryRegion data;
> + MemoryRegion control;
> +} State;
Please use BackdoorState.
> +
> +
> +static uint64_t control_io_read(void *opaque, target_phys_addr_t addr,
> unsigned size)
> +{
> + State *s = opaque;
> +
> + uint64_t res = ldq_p(&s->size);
> + uint8_t *resb = (uint8_t*)&res;
> + return resb[addr % CTRL_BYTES];
I don't think these lines do what you mean, but I'm also not sure what
it is supposed to mean.
> +}
> +
> +static void control_io_write(void *opaque, target_phys_addr_t addr, uint64_t
> data, unsigned size)
> +{
> + State *s = opaque;
> +
> + uint8_t *cmdb = (uint8_t*)&s->cmd;
> + cmdb[addr % CTRL_BYTES] = (uint8_t)data;
> +
> + if ((addr + size) % CTRL_BYTES == 0) {
> + qemu_backdoor(ldq_p(&s->cmd), s->data_ptr);
> + }
Same here.
> +}
> +
> +static const MemoryRegionOps control_ops = {
> + .read = control_io_read,
> + .write = control_io_write,
> + .endianness = DEVICE_NATIVE_ENDIAN,
> + .impl = {
> + .min_access_size = 1,
> + .max_access_size = 1,
> + },
> +};
> +
> +
> +static int init(PCIDevice *dev)
> +{
> + State *s = DO_UPCAST(State, dev, dev);
> +
> + if (s->pages < 1) {
> + fprintf(stderr, "error: backdoor: "
> + "the data channel must have one or more pages\n");
> + return -1;
> + }
> + s->size = s->pages * PAGE_SIZE;
> +
> + pci_set_word(s->dev.config + PCI_COMMAND,
> + PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
> +
> + memory_region_init_io(&s->control, &control_ops, s, "backdoor.control",
> + PAGE_SIZE);
> + pci_register_bar(&s->dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->control);
> +
> + memory_region_init_ram(&s->data, &s->dev.qdev, "backdoor.data",
> + s->size);
> + pci_register_bar(&s->dev, 1, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->data);
> + s->data_ptr = qemu_get_ram_ptr(s->data.ram_addr);
> +
> + qemu_backdoor_init(s->size);
> +
> + return 0;
> +}
> +
> +static int fini(PCIDevice *dev)
> +{
> + State *s = DO_UPCAST(State, dev, dev);
> +
> + memory_region_destroy(&s->data);
> + memory_region_destroy(&s->control);
> +
> + return 0;
> +}
> +
> +
> +static PCIDeviceInfo info = {
> + .qdev.name = "backdoor",
> + .qdev.desc = "Backdoor communication channel",
> + .qdev.size = sizeof(State),
> + .init = init,
> + .exit = fini,
> + .vendor_id = PCI_VENDOR_ID_REDHAT_QUMRANET,
> + .device_id = PCI_DEVICE_ID_BACKDOOR,
> + .class_id = PCI_CLASS_MEMORY_RAM,
> + .qdev.props = (Property[]) {
> + DEFINE_PROP_UINT8("pages", State, pages, 1),
> + DEFINE_PROP_END_OF_LIST(),
> + }
> +};
> +
> +static void register_device(void)
> +{
> + pci_qdev_register(&info);
> +}
> +
> +device_init(register_device)
> diff --git a/hw/pci.h b/hw/pci.h
> index 86a81c8..4d7d161 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -75,6 +75,7 @@
> #define PCI_DEVICE_ID_VIRTIO_BLOCK 0x1001
> #define PCI_DEVICE_ID_VIRTIO_BALLOON 0x1002
> #define PCI_DEVICE_ID_VIRTIO_CONSOLE 0x1003
> +#define PCI_DEVICE_ID_BACKDOOR 0x1004
>
> #define FMT_PCIBUS PRIx64
>
>
>
>
Re: [Qemu-devel] [RFC][PATCH 0/5] backdoor: lightweight guest-to-QEMU backdoor channel
2011/9/29 Anthony Liguori : > On 09/29/2011 08:47 AM, Lluís Vilanova wrote: >> >> Provides the ability for the guest to communicate with user-provided code >> inside >> QEMU itself, using a lightweight mechanism. >> >> See first commit for a full description. >> >> Signed-off-by: Lluís Vilanova > > We already have two "backdoors" in QEMU: ivshmem and virtio-serial. Can you > discuss why these are insufficient for your purposes? > > Also, what's the advantage of having a backdoor mechanism both for softmmu > and user? I can't think of a practical use-case for it. This can be used for instrumentation and maybe it could be used for test setups too instead of a dedicated test device. > Regards, > > Anthony Liguori > >> --- >> >> Lluís Vilanova (5): >> backdoor: Add documentation >> backdoor: Add build infrastructure >> backdoor: [*-user] Add QEMU-side proxy to "libbackdoor.a" >> backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a" >> backdoor: Add guest-side library >> >> >> Makefile | 3 - >> Makefile.objs | 21 >> Makefile.target | 4 + >> backdoor/guest/Makefile | 18 >> backdoor/guest/common.c | 130 +++ >> backdoor/guest/qemu-backdoor.h | 50 ++ >> backdoor/qemu/qemu-backdoor.h | 29 ++ >> backdoor/qemu/softmmu.c | 124 ++ >> backdoor/qemu/user.c | 194 >> >> backdoor/qemu/user.h | 17 >> bsd-user/main.c | 25 + >> bsd-user/mmap.c | 7 + >> configure | 35 +++ >> darwin-user/main.c | 25 + >> darwin-user/mmap.c | 7 + >> docs/backdoor.txt | 144 ++ >> hw/pci.h | 1 >> linux-user/main.c | 30 ++ >> linux-user/mmap.c | 7 + >> 19 files changed, 869 insertions(+), 2 deletions(-) >> create mode 100644 backdoor/guest/Makefile >> create mode 100644 backdoor/guest/common.c >> create mode 100644 backdoor/guest/qemu-backdoor.h >> create mode 100644 backdoor/qemu/qemu-backdoor.h >> create mode 100644 backdoor/qemu/softmmu.c >> create mode 100644 backdoor/qemu/user.c >> create mode 100644 backdoor/qemu/user.h >> create mode 100644 docs/backdoor.txt >> >> > > >
Re: [Qemu-devel] [PATCH v1 00/21]: First round of QAPI conversions
On Thu, 29 Sep 2011 15:15:17 -0500 Michael Roth wrote: > On Thu, 29 Sep 2011 10:52:30 -0300, Luiz Capitulino > wrote: > > On Thu, 29 Sep 2011 07:55:37 -0500 > > Anthony Liguori wrote: > > > > > On 09/28/2011 09:44 AM, Luiz Capitulino wrote: > > > > This series is a bundle of three things: > > > > > > > > 1. Patches 01 to 04 add the middle mode feature to the current QMP > > > > server. > > > > That mode allows for the current server to support QAPI commands. > > > > The > > > > Original author is Anthony, you can find his original post here: > > > > > > > > > > > > http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00374.html > > > > > > > > 2. Patches 05 to 10 are fixes from Anthony and Michael to the QAPI > > > > handling of the list type. > > > > > > > > 3. Patches 11 to 21 are simple monitor commands conversions to the > > > > QAPI. > > > > This is just a rebase of a previous conversion work by Anthony. > > > > > > Great series! > > > > > > Other than the one minor comment re: strdup and commit messages, I think > > > it's > > > ready to go. > > > > Actually, I've found a few small problems with the enumeration in > > patch 14: > > > > 1. I'm not using VmRunStatus internally in QEMU, I'm using RunState (which > > has to be dropped, right? - Is VmRunStatus a good name btw?) > > Ideally, yes, especially since you're directly assigning enum values from > RunState to VmRunStatus. VmRunStatus seems reasonable to me, though if you > call > it RunState you can just drop the previous declaration of RunState to convert > everythin over to using the schema definition. Yes, that's probably a good idea. I've called it VmRunStatus because RunState is a too generic name for a public API. > > > > > 2. RunState has a RSTATE_NO_STATE enum, which is used for initialization. > > To > > have that in VmRunStatus I had to add a 'no-status' value in the schema, > > is that ok? > > > Seems fine to me... the visitor routine assumes enumeration for schema-defined > enums starts at 0, so if that corresponds to RSTATE_NO_STATE you're fine. I've talked with Anthony about this and we decided to drop RSTATE_NO_STATE because it doesn't make sense to be part of the protocol. > > > > > 3. The code generator is replacing "-" by "_" (eg. 'no-status becomes > > 'no_status') but I have already fixed this and will include the patch > > in v2 > > Sounds good. > > > > > Also, it would be nice if Michael could review how I'm doing lists in > > patches 16 and 17. > > > > Sure, reviewed those and they look good. Also did some quick tests on all the > converted commands and didn't notice any other issues. Thanks a lot! Will send v2 soon. > > > Thanks! > > > > > > > > Regards, > > > > > > Anthony Liguori > > > > > > > > > > > Makefile| 12 ++ > > > > Makefile.objs |3 + > > > > Makefile.target |6 +- > > > > error.c |4 + > > > > hmp-commands.hx | 11 +- > > > > hmp.c | 116 ++ > > > > hmp.h | 31 + > > > > monitor.c | 273 > > > > +-- > > > > qapi-schema.json| 273 > > > > +++ > > > > qapi/qapi-dealloc-visitor.c | 34 +- > > > > qapi/qapi-types-core.h |3 + > > > > qapi/qmp-input-visitor.c|4 +- > > > > qapi/qmp-output-visitor.c | 20 +++- > > > > qemu-char.c | 35 ++ > > > > qerror.c| 33 + > > > > qerror.h|2 + > > > > qmp-commands.hx | 57 +++-- > > > > qmp.c | 92 +++ > > > > scripts/qapi-commands.py| 98 --- > > > > scripts/qapi-types.py |5 + > > > > scripts/qapi-visit.py |4 +- > > > > scripts/qapi.py |4 +- > > > > test-qmp-commands.c | 29 + > > > > test-visitor.c | 48 +++-- > > > > vl.c| 12 ++ > > > > 25 files changed, 877 insertions(+), 332 deletions(-) > > > > > > > > > > > > > >
Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away)
Am 29.09.2011 um 21:28 schrieb Blue Swirl :
> On Wed, Sep 28, 2011 at 9:21 PM, Alexander Graf wrote:
>>
>> On 27.09.2011, at 21:19, Blue Swirl wrote:
>>
>> On Tue, Sep 27, 2011 at 4:44 PM, Avi Kivity wrote:
>>
>> On 09/27/2011 07:39 PM, Blue Swirl wrote:
>>
>>
>> Well, it's not that easy. As the other mapping is part of an ordinary
>>
>> BAR,
>>
>> you need to setup the device (at least PCI_COMMAND and
>>
>> PCI_BASE_ADDRESS_0)
>>
>> so it responds to memory requests, and also enable the bridge.
>>
>> We could hack it by having a low-priority mapping at 0x80013000, but it
>>
>> seems wrong. Maybe the firmware should configure that BAR first? What
>>
>> happens on real hardware?
>>
>> In this message I seem to confess that the address is arbitrary and in
>>
>> the subsequent messages the overlap with PCI region is also discussed.
>>
>> http://lists.nongnu.org/archive/html/qemu-devel/2009-01/msg00542.html
>>
>> Maybe the address of macio should be fixed as Laurent suggested.
>>
>> I'll leave it up to you - I'm out of my depth here.
>>
>> Meanwhile I suggest applying the pci alias patch - the bug is independent of
>>
>> the vga issue.
>>
>> OK, pushed.
>>
>>
>> Ah, after digging into the issue for a while myself I stumbled over this
>> thread, explaining what I figured would be the culprit. Please CC qemu-ppc
>> for these discussions :).
>> Either way, I'm seeing 2 issues here. I enhanced the "info mtree" command to
>> also display the region we're currently looking at, so the first tuple shows
>> the region we're in, the second tuple the region we're trying to map into
>> the first region (addresses aligned on each other). I also print out alias
>> information directly:
>
> That way you miss for example vga.chain4.
>
>> [ -7ffe ] -7ffe : system
>> [ 80013000-8001303f ] 80013000-8001303f : escc
>> [ fee0-fee00fff ] fee0-fee00fff : pci-data-idx
>> [ fec0-fec00fff ] fec0-fec00fff : pci-conf-idx
>> [ 8000-fdff ] 8000-fdff : pci-hole
>>-> alias (8000, )
>> [ 8000-fdff ] - : pci-mmio
>> [ 8088-808f ] 8088-808f : macio
>> [ 808e-808f ] 808e-808f : macio-nvram
>> [ 808a-808a0fff ] 808a-808a0fff : pmac-ide
>> [ 80896000-80897fff ] 80896000-80897fff : cuda
>> [ 80893000-8089303f ] 80893000-8089303f : escc-bar
>> -> alias (, 80013000)
>> [ 80893000-8089303f ] 80893000-8089303f : escc
>> [ 80888000-80888fff ] 80888000-80888fff : dbdma
>> [ 8088-80880fff ] 8088-80880fff : heathrow-pic
>> [ 8080-8080 ] 8080-8080 : vga.rom
>> [ 8000-807f ] 8000-807f : vga.vram
>> [ fe00-fe1f ] fe00-fe1f : isa-mmio
>> I/O
>> [ - ] - : io
>> [ 0700-070f ] 0700-070f : cmd646-bmdma
>> [ 070c-070f ] 070c-070f : cmd646-bmdma-ioport
>> [ 0708-070b ] 0708-070b : cmd646-bmdma-bus
>> [ 0704-0707 ] 0704-0707 : cmd646-bmdma-ioport
>> [ 0700-0703 ] 0700-0703 : cmd646-bmdma-bus
>> [ 0680-0683 ] 0680-0683 : cmd646-cmd
>> [ 0600-0607 ] 0600-0607 : cmd646-data
>> [ 0580-0583 ] 0580-0583 : cmd646-cmd
>> [ 0500-0507 ] 0500-0507 : cmd646-data
>> [ 0400-04ff ] 0400-04ff : ne2000
>> I did another small hack to display the flat memory view:
>> ranges[0] = { 8000, 13000 } vga.vram
>> ranges[1] = { 80013000, 40 } escc
>> ranges[2] = { 80013040, 7ecfc0 } vga.vram
>> ranges[3] = { 8080, 1 } vga.rom
>> ranges[4] = { 8088, 1000 } heathrow-pic
>> ranges[5] = { 80888000, 1000 } dbdma
>> ranges[6] = { 80893000, 40 } escc
>> ranges[7] = { 80896000, 2000 } cuda
>> ranges[8] = { 808a, 1000 } pmac-ide
>> ranges[9] = { 808e, 2 } macio-nvram
>> ranges[10] = { fe00, 20 } isa-mmio
>> ranges[11] = { fec0, 1000 } pci-conf-idx
>> ranges[12] = { fee0, 1000 } pci-data-idx
>> Now to the issues:
>> 1)
>> ESCC is mapped inside the VGA region. That's what you discussed in this
>> thread. It's wrong. Please check this bug for a dump of a real G3 Beige's
>> memory layout:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555651
>> I don't think we really need to have serial available before PCI enum, so
>> let's just ditch the first map.
>
> OK, though it would be useful for -nographic mode. OpenBIOS can queue
> the output until a serial device has been probed and then print the
> buffer, but if it crashes before that, we're out of luck.
Then we need to gdb into openBIOS and read out the buffer. I do that with
Linux's log_buf all the time :)
>
> BTW, -nographic does not work anymore for PPC, there is no output.
Hrm. Th
Re: [Qemu-devel] [PATCH] Remove line buffering from log file
Am 29.09.2011 22:11, schrieb Blue Swirl: On Thu, Sep 29, 2011 at 7:57 AM, Peter Maydell wrote: On 29 September 2011 06:03, Peter Chubb wrote: Stefan> That's the reason why line buffering is needed today. I Stefan> enable log file output to see what happened last before the Stefan> crash. Thanks for this, I didn't think of this use-case. I don't think I've ever seen a qemu crash that wasn't caused by something really obvious. You don't need the logging for the obvious ones :-) abort() already flushes all open streams. So only signals that cause immediate death are a problem: SIGSEGV is the obvious one. If its handler called abort() then that would flush too. abort() is guaranteed by the POSIX spec to be callable from a signal handler. Catching SIGSEGV is likely to interact badly with the signal handling in linux-user mode, I expect. Stefan> Speed is not the primary target when somebody runs qemu -d ... It is if it takes hours to reach the problem that causes the abort(). Speeding up by an order of magnitude is worth it. One tactic I've found useful in these cases is to run without logging up to nearly the point where things fail, and then do a savevm. Then you can loadvm on a qemu with logging enabled and only look at the section of execution that causes the problem. This sounds like it should be possible to enable and disable logging during run time. The QEMU monitor already supports setting the log level via command 'log'. I used this command to examine problems with some user commands running in an emulated Linux. The performance could be improved by taking a trace point like approach, where all possible processing is postponed to outside process. Guest and host code disassembly and op printout could be left to postprocessing, the logs should contain only binary data.
