Re: [Qemu-devel] [PATCH] qtest: fix vhost-user-test compilation with old GLib
On Mon, Jul 14, 2014 at 01:26:34AM +0300, Michael S. Tsirkin wrote: > On Wed, Jul 09, 2014 at 06:06:32PM +0300, Nikolay Nikolaev wrote: > > Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib > > version before 2.26 does not have it. In such case just define it. > > > > Reported-by: Kevin Wolf > > Signed-off-by: Nikolay Nikolaev > > Applied, thanks! but again please put for-2.1 in subject. > > --- > > tests/vhost-user-test.c |4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c > > index b9dcec1..75fedf0 100644 > > --- a/tests/vhost-user-test.c > > +++ b/tests/vhost-user-test.c > > @@ -22,6 +22,10 @@ > > #include > > > > /* GLIB version compatibility flags */ > > +#if !GLIB_CHECK_VERSION(2, 26, 0) > > +#define G_TIME_SPAN_SECOND (G_GINT64_CONSTANT(100)) > > +#endif > > + > > #if GLIB_CHECK_VERSION(2, 28, 0) > > #define HAVE_MONOTONIC_TIME > > #endif
Re: [Qemu-devel] [PATCH] qtest: fix vhost-user-test compilation with old GLib
On 13 July 2014 23:26, Michael S. Tsirkin wrote: > On Wed, Jul 09, 2014 at 06:06:32PM +0300, Nikolay Nikolaev wrote: >> Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib >> version before 2.26 does not have it. In such case just define it. >> >> Reported-by: Kevin Wolf >> Signed-off-by: Nikolay Nikolaev > > Applied, thanks! Applied to what? This is already in master as commit 0a58991a (via Paolo's kvm tree). thanks -- PMM
Re: [Qemu-devel] [PATCH] Tap: fix vcpu long time io blocking on tap
> -Original Message- > From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Friday, July 11, 2014 9:04 PM > To: Wangkai (Kevin,C) > Cc: qemu-devel@nongnu.org; aligu...@amazon.com; Lee yang > Subject: Re: [PATCH] Tap: fix vcpu long time io blocking on tap > > On Fri, Jul 11, 2014 at 01:05:30AM +, Wangkai (Kevin,C) wrote: > > When used a tap as net driver for vm, if too many packets was > > delivered to the guest os via tap interface, the guest os will be > > blocked on io events for a long time, while tap driver was busying > process packets. > > > > kvm vcpu thread block on io lock call trace: > > __lll_lock_wait > > _L_lock_1004 > > __pthread_mutex_lock > > qemu_mutex_lock > > kvm_cpu_exec > > qemu_kvm_cpu_thread_fn > > start_thread > > > > qemu io thread call trace: > > ... > > qemu_net_queue_send > > tap_send > > qemu_iohandler_poll > > main_loop_wait > > main_loop > > > > > > I think the qemu io lock time should be as small as possible, and the > > io work slice should be limited at a particular ration or time. > > > > --- > > Signed-off-by: Wangkai > > How many packets are you seeing in a single tap_send() call? > > Have you profiled the tap_send() code path? Maybe it is performing > some operation that is very slow. > > By the way, if you want good performance you should use vhost_net > instead of userspace vhost_net. Userspace virtio-net is not very > optimized. > > Stefan Hi Stefan, I am not use profile, just debug with gdb and code review. When packets delivered, I found the VM was hung, and I check qemu run State by gdb, I see the call trace for IO thread and vcpu thread, and I add debug info to check how many packets within tap_send, the info below: total recv 393520 time 1539821 us total recv 1270 time 4931 us total recv 257872 time 995828 us total recv 10745 time 41438 us total recv 505387 time 2000925 us total recv 535 time 1891 us total recv 168934 time 646008 us regards, Wangkai
[Qemu-devel] [PATCH 1/2] loader: Add load_image_size() to replace load_image()
A subsequent patch to ppc/spapr needs to load the RTAS blob into
qemu memory rather than target memory (so it can later be copied
into the right spot at machine reset time).
I would use load_image() but it is marked deprecated because it
doesn't take a buffer size as argument, so let's add load_image_size()
that does.
Signed-off-by: Benjamin Herrenschmidt
---
hw/core/loader.c| 18 ++
include/hw/loader.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 2bf6b8f..06e8f1e 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -89,6 +89,24 @@ int load_image(const char *filename, uint8_t *addr)
return size;
}
+/* return the size or -1 if error */
+ssize_t load_image_size(const char *filename, void *addr, size_t size)
+{
+int fd;
+ssize_t actsize;
+
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd < 0)
+return -1;
+actsize = read(fd, addr, size);
+if (actsize < 0) {
+close(fd);
+return -1;
+}
+close(fd);
+return actsize;
+}
+
/* read()-like version */
ssize_t read_targphys(const char *name,
int fd, hwaddr dst_addr, size_t nbytes)
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 796cbf9..991f84a 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -13,6 +13,7 @@
*/
int get_image_size(const char *filename);
int load_image(const char *filename, uint8_t *addr); /* deprecated */
+ssize_t load_image_size(const char *filename, void *addr, size_t size);
int load_image_targphys(const char *filename, hwaddr,
uint64_t max_sz);
[Qemu-devel] [PATCH 1/2] loader: Add load_image_size() to replace load_image()
A subsequent patch to ppc/spapr needs to load the RTAS blob into
qemu memory rather than target memory (so it can later be copied
into the right spot at machine reset time).
I would use load_image() but it is marked deprecated because it
doesn't take a buffer size as argument, so let's add load_image_size()
that does.
Signed-off-by: Benjamin Herrenschmidt
---
hw/core/loader.c| 18 ++
include/hw/loader.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/hw/core/loader.c b/hw/core/loader.c
index 2bf6b8f..06e8f1e 100644
--- a/hw/core/loader.c
+++ b/hw/core/loader.c
@@ -89,6 +89,24 @@ int load_image(const char *filename, uint8_t *addr)
return size;
}
+/* return the size or -1 if error */
+ssize_t load_image_size(const char *filename, void *addr, size_t size)
+{
+int fd;
+ssize_t actsize;
+
+fd = open(filename, O_RDONLY | O_BINARY);
+if (fd < 0)
+return -1;
+actsize = read(fd, addr, size);
+if (actsize < 0) {
+close(fd);
+return -1;
+}
+close(fd);
+return actsize;
+}
+
/* read()-like version */
ssize_t read_targphys(const char *name,
int fd, hwaddr dst_addr, size_t nbytes)
diff --git a/include/hw/loader.h b/include/hw/loader.h
index 796cbf9..991f84a 100644
--- a/include/hw/loader.h
+++ b/include/hw/loader.h
@@ -13,6 +13,7 @@
*/
int get_image_size(const char *filename);
int load_image(const char *filename, uint8_t *addr); /* deprecated */
+ssize_t load_image_size(const char *filename, void *addr, size_t size);
int load_image_targphys(const char *filename, hwaddr,
uint64_t max_sz);
[Qemu-devel] [PATCH 2/2] ppc/spapr: Locate RTAS and device-tree based on real RMA
We currently calculate the final RTAS and FDT location based on
the early estimate of the RMA size, cropped to 256M on KVM since
we only know the real RMA size at reset time which happens much
later in the boot process.
This means the FDT and RTAS end up right below 256M while they
could be much higher, using precious RMA space and limiting
what the OS bootloader can put there which has proved to be
a problem with some OSes (such as when using very large initrd's)
Fortunately, we do the actual copy of the device-tree into guest
memory much later, during reset, late enough to be able to do it
using the final RMA value, we just need to move the calculation
to the right place.
However, RTAS is still loaded too early, so we change the code to
load the tiny blob into qemu memory early on, and then copy it into
guest memory at reset time. It's small enough that the memory usage
doesn't matter.
Signed-off-by: Benjamin Herrenschmidt
---
hw/ppc/spapr.c | 30 +++---
include/hw/ppc/spapr.h | 3 ++-
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 82f183f..949d5ba 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -866,16 +866,29 @@ static void spapr_reset_htab(sPAPREnvironment *spapr)
static void ppc_spapr_reset(void)
{
PowerPCCPU *first_ppc_cpu;
+uint32_t rtas_limit;
/* Reset the hash table & recalc the RMA */
spapr_reset_htab(spapr);
qemu_devices_reset();
+/* We place the device tree and RTAS just below either the top of the RMA,
+ * or just below 2GB, whichever is lowere, so that it can be
+ * processed with 32-bit real mode code if necessary
+ */
+rtas_limit = MIN(spapr->rma_size, 0x8000);
+spapr->rtas_addr = rtas_limit - RTAS_MAX_SIZE;
+spapr->fdt_addr = spapr->rtas_addr - FDT_MAX_SIZE;
+
/* Load the fdt */
spapr_finalize_fdt(spapr, spapr->fdt_addr, spapr->rtas_addr,
spapr->rtas_size);
+/* Copy RTAS over */
+cpu_physical_memory_write(spapr->rtas_addr, spapr->rtas_blob,
+ spapr->rtas_size);
+
/* Set up the entry state */
first_ppc_cpu = POWERPC_CPU(first_cpu);
first_ppc_cpu->env.gpr[3] = spapr->fdt_addr;
@@ -1293,7 +1306,7 @@ static void ppc_spapr_init(MachineState *machine)
hwaddr node0_size = (nb_numa_nodes > 1) ? numa_info[0].node_mem : ram_size;
uint32_t initrd_base = 0;
long kernel_size = 0, initrd_size = 0;
-long load_limit, rtas_limit, fw_size;
+long load_limit, fw_size;
bool kernel_le = false;
char *filename;
@@ -1338,13 +1351,8 @@ static void ppc_spapr_init(MachineState *machine)
exit(1);
}
-/* We place the device tree and RTAS just below either the top of the RMA,
- * or just below 2GB, whichever is lowere, so that it can be
- * processed with 32-bit real mode code if necessary */
-rtas_limit = MIN(spapr->rma_size, 0x8000);
-spapr->rtas_addr = rtas_limit - RTAS_MAX_SIZE;
-spapr->fdt_addr = spapr->rtas_addr - FDT_MAX_SIZE;
-load_limit = spapr->fdt_addr - FW_OVERHEAD;
+/* Setup a load limit for the ramdisk leaving room for SLOF and FDT */
+load_limit = MIN(spapr->rma_size, 0x8000) - FW_OVERHEAD;
/* We aim for a hash table of size 1/128 the size of RAM. The
* normal rule of thumb is 1/64 the size of RAM, but that's much
@@ -1410,9 +1418,9 @@ static void ppc_spapr_init(MachineState *machine)
}
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, "spapr-rtas.bin");
-spapr->rtas_size = load_image_targphys(filename, spapr->rtas_addr,
- rtas_limit - spapr->rtas_addr);
-if (spapr->rtas_size < 0) {
+spapr->rtas_size = get_image_size(filename);
+spapr->rtas_blob = g_malloc(spapr->rtas_size);
+if (load_image_size(filename, spapr->rtas_blob, spapr->rtas_size) < 0) {
hw_error("qemu: could not load LPAR rtas '%s'\n", filename);
exit(1);
}
diff --git a/include/hw/ppc/spapr.h b/include/hw/ppc/spapr.h
index e3e7aff..5b399b8 100644
--- a/include/hw/ppc/spapr.h
+++ b/include/hw/ppc/spapr.h
@@ -24,7 +24,8 @@ typedef struct sPAPREnvironment {
hwaddr rma_size;
int vrma_adjust;
hwaddr fdt_addr, rtas_addr;
-long rtas_size;
+ssize_t rtas_size;
+void *rtas_blob;
void *fdt_skel;
target_ulong entry_point;
uint32_t next_irq;
Re: [Qemu-devel] [PATCH] scsi: Report error when lun number is in use
On Tue, 06/10 14:55, Fam Zheng wrote:
> In the case that the lun number is taken by another scsi device, don't
> release the existing device siliently, but report an error to user.
>
> Signed-off-by: Fam Zheng
Do we want this in 2.1?
Fam
> ---
> hw/scsi/scsi-bus.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
> index 06399fa..d219da3 100644
> --- a/hw/scsi/scsi-bus.c
> +++ b/hw/scsi/scsi-bus.c
> @@ -177,7 +177,8 @@ static int scsi_qdev_init(DeviceState *qdev)
> d = scsi_device_find(bus, dev->channel, dev->id, dev->lun);
> assert(d);
> if (d->lun == dev->lun && dev != d) {
> -object_unparent(OBJECT(d));
> +error_report("lun already used by '%s'", d->qdev.id);
> +goto err;
> }
> }
>
> --
> 2.0.0
>
>
Re: [Qemu-devel] [PATCH v2] configure: make libnfs not_found message user friendly
On Sat, 07/12 11:17, Liu Yuan wrote: > Cc: Kevin Wolf > Signed-off-by: Liu Yuan > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index 7dd43fd..78e7baf 100755 > --- a/configure > +++ b/configure > @@ -3996,7 +3996,7 @@ if test "$libnfs" != "no" ; then > LIBS="$LIBS $libnfs_libs" >else > if test "$libnfs" = "yes" ; then > - feature_not_found "libnfs" > + feature_not_found "libnfs" "Install libnfs-devel >= 1.9.3" I notice that other occasions of feature_not_found doesn't add "-" between package and devel. Fam
Re: [Qemu-devel] [PATCH v2] configure: make libnfs not_found message user friendly
On Sat, Jul 12, 2014 at 11:17:40AM +0800, Liu Yuan wrote: > Cc: Kevin Wolf > Signed-off-by: Liu Yuan > --- > configure | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure b/configure > index 7dd43fd..78e7baf 100755 > --- a/configure > +++ b/configure > @@ -3996,7 +3996,7 @@ if test "$libnfs" != "no" ; then > LIBS="$LIBS $libnfs_libs" >else > if test "$libnfs" = "yes" ; then > - feature_not_found "libnfs" > + feature_not_found "libnfs" "Install libnfs-devel >= 1.9.3" > fi > libnfs="no" >fi > -- > 1.9.1 > I already had a patch that fixed all similar cases: http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg06411.html. Regards, Hu
Re: [Qemu-devel] [PATCH] qom: Make object_child_foreach safe for objects removal
On Mon, Jul 14, 2014 at 12:41:08AM +1000, Alexey Kardashevskiy wrote:
> Current object_child_foreach() uses QTAILQ_FOREACH() to walk
> through children and that makes children removal from the callback
> impossible.
>
> This makes object_child_foreach() use QTAILQ_FOREACH_SAFE().
>
> Signed-off-by: Alexey Kardashevskiy
> ---
>
> The problem I am trying to solve is:
> there is a PHB with multiple DMA windows a.k.a. sPAPRTCETable's which are
> QOM children of PHB. One of RTAS functions is "reset" which is supposed to
> remove all windows (now just one) except the default one.
>
> I could call QTAILQ_FOREACH_SAFE in sPAPR PHB code but
> object_property_is_child()
> is static and we probably do not want to make it public.
Reviewed-by: Hu Tao
But people tend to accept changes like this one together with the
patch(es) that need it.
Regards,
Hu
>
>
> ---
> qom/object.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qom/object.c b/qom/object.c
> index 0e8267b..4a814dc 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -678,10 +678,10 @@ void object_class_foreach(void (*fn)(ObjectClass
> *klass, void *opaque),
> int object_child_foreach(Object *obj, int (*fn)(Object *child, void *opaque),
> void *opaque)
> {
> -ObjectProperty *prop;
> +ObjectProperty *prop, *next;
> int ret = 0;
>
> -QTAILQ_FOREACH(prop, &obj->properties, node) {
> +QTAILQ_FOREACH_SAFE(prop, &obj->properties, node, next) {
> if (object_property_is_child(prop)) {
> ret = fn(prop->opaque, opaque);
> if (ret != 0) {
> --
> 2.0.0
>
Re: [Qemu-devel] [PATCH v7 3/4] s390x: Migrate to new NMI interface
On 07/03/2014 05:11 PM, Markus Armbruster wrote: > Alexey Kardashevskiy writes: > >> On 06/23/2014 11:32 PM, Alexey Kardashevskiy wrote: >>> On 06/16/2014 06:37 PM, Alexander Graf wrote: On 16.06.14 10:33, Alexey Kardashevskiy wrote: > On 06/16/2014 05:16 PM, Cornelia Huck wrote: >> On Sat, 14 Jun 2014 12:41:50 +1000 >> Alexey Kardashevskiy wrote: >> >>> On 06/13/2014 04:00 PM, Cornelia Huck wrote: On Fri, 13 Jun 2014 13:36:58 +1000 Alexey Kardashevskiy wrote: > This implements an NMI interface for s390 and s390-ccw machines. > > This removes #ifdef s390 branch in qmp_inject_nmi so new s390's > nmi_monitor_handler() callback is going to be used for NMI. > > Since nmi_monitor_handler()-calling code is platform independent, > CPUState::cpu_index is used instead of S390CPU::env.cpu_num. > There should not be any change in behaviour as both @cpu_index and > @cpu_num are global CPU numbers. > > Also, s390_cpu_restart() takes care of preforming operations in > the specific CPU thread so no extra measure is required here either. I find this paragraph a bit confusing; I'd just remove it. >>> Besides bad english (please feel free to adjust it), what else is >>> confusing >>> here? I put it there because the spapr patch makes use of >>> async_run_on_cpu() and maintainers may ask why I do not do the same for >>> other platforms. This way I hoped I could reduce number of versions to >>> post :) >> What about >> >> "Note that s390_cpu_restart() already takes care of the specified cpu, >> so we don't need to schedule via async_run_on_cpu()." > I fail to see how exactly this is better or different but ok :) > > > Alex, should I repost it with Cornelia's suggestion? What should happen > next to this patchset? Who is supposed to pick it up? Thanks. Just post v8 of that single patch with the right message-id as reference. I can pick up the patches, but I'd like at least an ack from Paolo on the whole set. >>> >>> >>> Anybody, ping? Or we are waiting till x86 machines got QOM'ed and then I'll >>> repost it with x86 NMI handler? Thanks! >> >> >> Paolo promised to ack (in irc) and obviously forgot :) Should I give up and >> stop bothering noble people? :) > > No, you should politely bother them again. That does not seem helping though :-/ -- Alexey
Re: [Qemu-devel] [PATCH 3/5] PPC: mac_nvram: Allow 2 and 4 byte accesses
Il 13/07/2014 18:17, Alexander Graf ha scritto:
The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
just as well as 1byte accesses. In fact, Mac OS X uses those.
Add support for higher register size granularities.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 43 ---
1 file changed, 32 insertions(+), 11 deletions(-)
diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index bcff074..0a6df44 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -40,32 +40,53 @@
#define DEF_SYSTEM_SIZE 0xc10
/* macio style NVRAM device */
-static void macio_nvram_writeb(void *opaque, hwaddr addr,
- uint64_t value, unsigned size)
+static void macio_nvram_write(void *opaque, hwaddr addr,
+ uint64_t value, unsigned size)
{
MacIONVRAMState *s = opaque;
addr = (addr >> s->it_shift) & (s->size - 1);
-s->data[addr] = value;
-NVR_DPRINTF("writeb addr %04" PHYS_PRIx " val %" PRIx64 "\n", addr, value);
+switch (size) {
+case 1:
+s->data[addr] = value;
+break;
+case 2:
+stw_be_p(&s->data[addr], value);
+break;
+case 4:
+stl_be_p(&s->data[addr], value);
+break;
+}
+NVR_DPRINTF("write%d addr %04" PRIx64 " val %" PRIx64 "\n", size, addr,
+value);
}
-static uint64_t macio_nvram_readb(void *opaque, hwaddr addr,
- unsigned size)
+static uint64_t macio_nvram_read(void *opaque, hwaddr addr,
+ unsigned size)
{
MacIONVRAMState *s = opaque;
-uint32_t value;
+uint32_t value = 0;
addr = (addr >> s->it_shift) & (s->size - 1);
-value = s->data[addr];
-NVR_DPRINTF("readb addr %04x val %x\n", (int)addr, value);
+switch (size) {
+case 1:
+value = s->data[addr];
+break;
+case 2:
+value = lduw_be_p(&s->data[addr]);
+break;
+case 4:
+value = ldl_be_p(&s->data[addr]);
+break;
+}
+NVR_DPRINTF("read%d addr %04x val %x\n", size, (int)addr, value);
return value;
}
static const MemoryRegionOps macio_nvram_ops = {
-.read = macio_nvram_readb,
-.write = macio_nvram_writeb,
+.read = macio_nvram_read,
+.write = macio_nvram_write,
.endianness = DEVICE_BIG_ENDIAN,
};
I think this ought to be enough:
static const MemoryRegionOps test_ioport_byte_ops = {
.read = macio_nvram_readb,
.write = macio_nvram_writeb,
+.valid.min_access_size = 1,
+.valid.max_access_size = 4,
+.impl.min_access_size = 1,
+.impl.max_access_size = 1,
.endianness = DEVICE_BIG_ENDIAN,
};
Paolo
Re: [Qemu-devel] [PATCH] scsi: Report error when lun number is in use
Il 14/07/2014 04:42, Fam Zheng ha scritto: On Tue, 06/10 14:55, Fam Zheng wrote: > In the case that the lun number is taken by another scsi device, don't > release the existing device siliently, but report an error to user. > > Signed-off-by: Fam Zheng Do we want this in 2.1? Fam Yes, thanks! Paolo
[Qemu-devel] latest rc: virtio-blk hangs forever after migration
Hello, the issue is not specific to the iothread code because generic virtio-blk also hangs up: Given code set like in the http://www.mail-archive.com/qemu-devel@nongnu.org/msg246164.html, launch a VM with virtio-blk disk and writeback rbd backend, fire up fio, migrate once with libvirt: time virsh migrate vm27842 qemu+tcp://10.6.0.10/system --live --persistent --undefinesource --timeout 60 real1m2.969s user0m0.016s sys 0m0.008s For ones who are unfamiliar with libvirt syntax this means that the live migration was failed to complete over sixty seconds, VM was frozen, moved and re-launched at the destination. After this, I/O gets stuck forever. Any diagnostic information is available upon request if there will be difficulties repeating the issue.
Re: [Qemu-devel] [RFC PATCH 0/8] Add Generic PCI host device update
On Fri, Jul 11, 2014 at 4:28 AM, Alvise Rigo wrote: > The kernel version is a very recent one: v3.16.0-rc1. > Maybe you are right. I will test some older version to see if I'm able > to reproduce the issue. BTW, the lsi driver has compile time option to use i/o or memory accesses. I usually test both modes when doing PCI related changes. Unfortunately, I don't recall whether the problem I saw was only for one or both. Rob > > Thank you, > alvise > > > Il 11/07/2014 11:09, Peter Maydell ha scritto: >> On 11 July 2014 08:21, Alvise Rigo wrote: >>> This work has been tested attaching several PCI devices to the mach-virt >>> platform. The tested devices are: virtio-blk-pci, virtio-net-pci, >>> lsi53c895a and pci-ohci (all attached at the same time). >>> Even if the original work was not changed in its core functionalities, I >>> couldn't reproduce the malfunctioning of the LSI SCSI mentioned in [1]. >>> After attaching several qcow2 images, formatting and filling them, I >>> didn't notice anything wrong. Am I missing something? >> >> Interesting. Perhaps the bug was on the kernel side; which >> guest kernel version are you using to test with? >> >> thanks >> -- PMM >>
[Qemu-devel] [PATCH] qom: Make object_child_foreach safe for objects removal
Current object_child_foreach() uses QTAILQ_FOREACH() to walk
through children and that makes children removal from the callback
impossible.
This makes object_child_foreach() use QTAILQ_FOREACH_SAFE().
Signed-off-by: Alexey Kardashevskiy
---
The problem I am trying to solve is:
there is a PHB with multiple DMA windows a.k.a. sPAPRTCETable's which are
QOM children of PHB. One of RTAS functions is "reset" which is supposed to
remove all windows (now just one) except the default one.
I could call QTAILQ_FOREACH_SAFE in sPAPR PHB code but
object_property_is_child()
is static and we probably do not want to make it public.
---
qom/object.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index 0e8267b..4a814dc 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -678,10 +678,10 @@ void object_class_foreach(void (*fn)(ObjectClass *klass,
void *opaque),
int object_child_foreach(Object *obj, int (*fn)(Object *child, void *opaque),
void *opaque)
{
-ObjectProperty *prop;
+ObjectProperty *prop, *next;
int ret = 0;
-QTAILQ_FOREACH(prop, &obj->properties, node) {
+QTAILQ_FOREACH_SAFE(prop, &obj->properties, node, next) {
if (object_property_is_child(prop)) {
ret = fn(prop->opaque, opaque);
if (ret != 0) {
--
2.0.0
Re: [Qemu-devel] latest rc: virtio-blk hangs forever after migration
On Sun, Jul 13, 2014 at 4:28 PM, Andrey Korolyov wrote: > Hello, > > the issue is not specific to the iothread code because generic > virtio-blk also hangs up: > > Given code set like in the > http://www.mail-archive.com/qemu-devel@nongnu.org/msg246164.html, > launch a VM with virtio-blk disk and writeback rbd backend, fire up > fio, migrate once with libvirt: > > time virsh migrate vm27842 qemu+tcp://10.6.0.10/system --live > --persistent --undefinesource --timeout 60 > > > real1m2.969s > user0m0.016s > sys 0m0.008s > > For ones who are unfamiliar with libvirt syntax this means that the > live migration was failed to complete over sixty seconds, VM was > frozen, moved and re-launched at the destination. After this, I/O gets > stuck forever. Any diagnostic information is available upon request if > there will be difficulties repeating the issue. Small follow-up: issue have probabilistic nature, as it looks - by limited number of runs, it is reproducible within three cases: 1) live migration went well, I/O locked up, 2) live migration failed by timeout, I/O locked up, 3) live migration went well and disk was not locked, but on backward migration we are always hitting 2).
[Qemu-devel] [PATCH 2/5] PPC: mac_nvram: Remove unused functions
The macio_nvram_read and macio_nvram_write functions are never called,
just remove them.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 23 ---
hw/ppc/mac.h | 2 --
2 files changed, 25 deletions(-)
diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index 170b10b..bcff074 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -39,29 +39,6 @@
#define DEF_SYSTEM_SIZE 0xc10
-/* Direct access to NVRAM */
-uint8_t macio_nvram_read(MacIONVRAMState *s, uint32_t addr)
-{
-uint32_t ret;
-
-if (addr < s->size) {
-ret = s->data[addr];
-} else {
-ret = -1;
-}
-NVR_DPRINTF("read addr %04" PRIx32 " val %" PRIx8 "\n", addr, ret);
-
-return ret;
-}
-
-void macio_nvram_write(MacIONVRAMState *s, uint32_t addr, uint8_t val)
-{
-NVR_DPRINTF("write addr %04" PRIx32 " val %" PRIx8 "\n", addr, val);
-if (addr < s->size) {
-s->data[addr] = val;
-}
-}
-
/* macio style NVRAM device */
static void macio_nvram_writeb(void *opaque, hwaddr addr,
uint64_t value, unsigned size)
diff --git a/hw/ppc/mac.h b/hw/ppc/mac.h
index c1faf9c..23536f4 100644
--- a/hw/ppc/mac.h
+++ b/hw/ppc/mac.h
@@ -178,6 +178,4 @@ typedef struct MacIONVRAMState {
} MacIONVRAMState;
void pmac_format_nvram_partition (MacIONVRAMState *nvr, int len);
-uint8_t macio_nvram_read(MacIONVRAMState *s, uint32_t addr);
-void macio_nvram_write(MacIONVRAMState *s, uint32_t addr, uint8_t val);
#endif /* !defined(__PPC_MAC_H__) */
--
1.8.1.4
[Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes
While trying to get Mac OS X booting with our -M mac99 emulation I stumbled over a few issues that prevented it from doing so. With these patches applied I still can't properly boot Mac OS X with -M mac99, but I get a lot further than before. The biggest issue that's left now is to properly fake Mac OS X into believing our timebase frequency. If I hack up the cuda timer I can successfully boot Mac OS X on mac99: === diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c index ff6051d..3d40534 100644 --- a/hw/misc/macio/cuda.c +++ b/hw/misc/macio/cuda.c @@ -102,7 +102,7 @@ #define CUDA_TIMER_TICKLE 0x24 #define CUDA_COMBINED_FORMAT_IIC 0x25 -#define CUDA_TIMER_FREQ (470 / 6) +#define CUDA_TIMER_FREQ ((470 / 6) / 64) #define CUDA_ADB_POLL_FREQ 50 /* CUDA returns time_t's offset from Jan 1, 1904, not 1970 */ === Please bear in mind that this patch set depends on an OpenBIOS update. Alexander Graf (5): PPC: mac99: Fix core99 timer frequency PPC: mac_nvram: Remove unused functions PPC: mac_nvram: Allow 2 and 4 byte accesses PPC: mac_nvram: Split NVRAM into OF and OSX parts PPC: mac99: Expose NVRAM linearly hw/misc/macio/macio.c | 9 - hw/nvram/mac_nvram.c | 109 +- hw/ppc/mac.h | 2 - hw/ppc/mac_newworld.c | 7 ++-- include/hw/ppc/ppc.h | 1 + 5 files changed, 84 insertions(+), 44 deletions(-) -- 1.8.1.4
[Qemu-devel] [PATCH 3/5] PPC: mac_nvram: Allow 2 and 4 byte accesses
The NVRAM in our Core99 machine really supports 2byte and 4byte accesses
just as well as 1byte accesses. In fact, Mac OS X uses those.
Add support for higher register size granularities.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 43 ---
1 file changed, 32 insertions(+), 11 deletions(-)
diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index bcff074..0a6df44 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -40,32 +40,53 @@
#define DEF_SYSTEM_SIZE 0xc10
/* macio style NVRAM device */
-static void macio_nvram_writeb(void *opaque, hwaddr addr,
- uint64_t value, unsigned size)
+static void macio_nvram_write(void *opaque, hwaddr addr,
+ uint64_t value, unsigned size)
{
MacIONVRAMState *s = opaque;
addr = (addr >> s->it_shift) & (s->size - 1);
-s->data[addr] = value;
-NVR_DPRINTF("writeb addr %04" PHYS_PRIx " val %" PRIx64 "\n", addr, value);
+switch (size) {
+case 1:
+s->data[addr] = value;
+break;
+case 2:
+stw_be_p(&s->data[addr], value);
+break;
+case 4:
+stl_be_p(&s->data[addr], value);
+break;
+}
+NVR_DPRINTF("write%d addr %04" PRIx64 " val %" PRIx64 "\n", size, addr,
+value);
}
-static uint64_t macio_nvram_readb(void *opaque, hwaddr addr,
- unsigned size)
+static uint64_t macio_nvram_read(void *opaque, hwaddr addr,
+ unsigned size)
{
MacIONVRAMState *s = opaque;
-uint32_t value;
+uint32_t value = 0;
addr = (addr >> s->it_shift) & (s->size - 1);
-value = s->data[addr];
-NVR_DPRINTF("readb addr %04x val %x\n", (int)addr, value);
+switch (size) {
+case 1:
+value = s->data[addr];
+break;
+case 2:
+value = lduw_be_p(&s->data[addr]);
+break;
+case 4:
+value = ldl_be_p(&s->data[addr]);
+break;
+}
+NVR_DPRINTF("read%d addr %04x val %x\n", size, (int)addr, value);
return value;
}
static const MemoryRegionOps macio_nvram_ops = {
-.read = macio_nvram_readb,
-.write = macio_nvram_writeb,
+.read = macio_nvram_read,
+.write = macio_nvram_write,
.endianness = DEVICE_BIG_ENDIAN,
};
--
1.8.1.4
[Qemu-devel] [PATCH 1/5] PPC: mac99: Fix core99 timer frequency
There is a special timer in the mac99 machine that we recently started
to emulate. Unfortunately we emulated it in the wrong frequency.
This patch adapts the frequency Mac OS X uses to evaluate results from
this timer, making calculations it bases off of it work.
Signed-off-by: Alexander Graf
---
hw/misc/macio/macio.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 47f45f5..35eaa00 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -243,13 +243,18 @@ static void timer_write(void *opaque, hwaddr addr,
uint64_t value,
static uint64_t timer_read(void *opaque, hwaddr addr, unsigned size)
{
uint32_t value = 0;
+uint64_t systime = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+uint64_t kltime;
+
+kltime = muldiv64(systime, 4194300, get_ticks_per_sec() * 4);
+kltime = muldiv64(kltime, 18432000, 1048575);
switch (addr) {
case 0x38:
-value = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+value = kltime;
break;
case 0x3c:
-value = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) >> 32;
+value = kltime >> 32;
break;
}
--
1.8.1.4
[Qemu-devel] [PATCH 5/5] PPC: mac99: Expose NVRAM linearly
The mac99 machine really doesn't have any shifts in NVRAM usage. It simply has
a 1:1 MMIO mapped space where a guest can access the NVRAM data.
This patch fixes up the incorrect format we use for NVRAM today, making Mac OS
X happy and able to read NVRAM.
This patch also requires a new OpenBIOS version. To ensure bisectaibility,
we provide a fw_cfg hint to tell OpenBIOS that NVRAM is now flat.
Signed-off-by: Alexander Graf
---
WARNING! This patch breaks compatibility with older OpenBIOS which can
no longer read data from NVRAM after this patch is applied to populate
its prom variables.
---
hw/ppc/mac_newworld.c | 7 ---
include/hw/ppc/ppc.h | 1 +
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index e96b635..32ee2f2 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -435,12 +435,12 @@ static void ppc_core99_init(MachineState *machine)
}
#endif
dev = qdev_create(NULL, TYPE_MACIO_NVRAM);
-qdev_prop_set_uint32(dev, "size", 0x2000);
-qdev_prop_set_uint32(dev, "it_shift", 1);
+qdev_prop_set_uint32(dev, "size", 0x4000);
+qdev_prop_set_uint32(dev, "it_shift", 0);
qdev_init_nofail(dev);
sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, nvram_addr);
nvr = MACIO_NVRAM(dev);
-pmac_format_nvram_partition(nvr, 0x2000);
+pmac_format_nvram_partition(nvr, 0x4000);
/* No PCI init: the BIOS will do it */
fw_cfg = fw_cfg_init(0, 0, CFG_ADDR, CFG_ADDR + 2);
@@ -482,6 +482,7 @@ static void ppc_core99_init(MachineState *machine)
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
+fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_FLAT, 1);
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
diff --git a/include/hw/ppc/ppc.h b/include/hw/ppc/ppc.h
index 14efd0c..7b13cee 100644
--- a/include/hw/ppc/ppc.h
+++ b/include/hw/ppc/ppc.h
@@ -94,6 +94,7 @@ enum {
#define FW_CFG_PPC_KVM_PID (FW_CFG_ARCH_LOCAL + 0x07)
#define FW_CFG_PPC_NVRAM_ADDR (FW_CFG_ARCH_LOCAL + 0x08)
#define FW_CFG_PPC_BUSFREQ (FW_CFG_ARCH_LOCAL + 0x09)
+#define FW_CFG_PPC_NVRAM_FLAT (FW_CFG_ARCH_LOCAL + 0x0a)
#define PPC_SERIAL_MM_BAUDBASE 399193
--
1.8.1.4
[Qemu-devel] [PATCH 4/5] PPC: mac_nvram: Split NVRAM into OF and OSX parts
Mac OS X (at least with -M mac99) searches for a valid NVRAM partition
of a special Apple type. If it can't find that partition in the first
half of NVRAM, it will look at the second half.
There are a few implications from this. The first is that we need to
split NVRAM into 2 halves - one for Open Firmware use, the other one for
Mac OS X. Without this split Mac OS X will just loop endlessly over the
second half trying to find a partition.
The other implication is that we should provide a specially crafted Mac
OS X compatible NVRAM partition on the second half that Mac OS X can
happily use as it sees fit.
Signed-off-by: Alexander Graf
---
hw/nvram/mac_nvram.c | 43 ---
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/hw/nvram/mac_nvram.c b/hw/nvram/mac_nvram.c
index 0a6df44..52eb9bd 100644
--- a/hw/nvram/mac_nvram.c
+++ b/hw/nvram/mac_nvram.c
@@ -26,6 +26,7 @@
#include "hw/nvram/openbios_firmware_abi.h"
#include "sysemu/sysemu.h"
#include "hw/ppc/mac.h"
+#include
/* debug NVR */
//#define DEBUG_NVR
@@ -154,15 +155,16 @@ static void macio_nvram_register_types(void)
}
/* Set up a system OpenBIOS NVRAM partition */
-void pmac_format_nvram_partition (MacIONVRAMState *nvr, int len)
+static void pmac_format_nvram_partition_of(MacIONVRAMState *nvr, int off,
+ int len)
{
unsigned int i;
-uint32_t start = 0, end;
+uint32_t start = off, end;
struct OpenBIOS_nvpart_v1 *part_header;
// OpenBIOS nvram variables
// Variable partition
-part_header = (struct OpenBIOS_nvpart_v1 *)nvr->data;
+part_header = (struct OpenBIOS_nvpart_v1 *)&nvr->data[start];
part_header->signature = OPENBIOS_PART_SYSTEM;
pstrcpy(part_header->name, sizeof(part_header->name), "system");
@@ -190,4 +192,39 @@ void pmac_format_nvram_partition (MacIONVRAMState *nvr,
int len)
OpenBIOS_finish_partition(part_header, end - start);
}
+#define OSX_NVRAM_SIGNATURE (0x5A)
+
+/* Set up a Mac OS X NVRAM partition */
+static void pmac_format_nvram_partition_osx(MacIONVRAMState *nvr, int off,
+int len)
+{
+uint32_t start = off;
+struct OpenBIOS_nvpart_v1 *part_header;
+unsigned char *data = &nvr->data[start];
+
+/* empty partition */
+part_header = (struct OpenBIOS_nvpart_v1 *)data;
+part_header->signature = OSX_NVRAM_SIGNATURE;
+pstrcpy(part_header->name, sizeof(part_header->name), "");
+
+OpenBIOS_finish_partition(part_header, len);
+
+/* Generation */
+stl_be_p(&data[20], 2);
+
+/* Adler32 checksum */
+stl_be_p(&data[16], adler32(0, &data[20], len - 20));
+}
+
+/* Set up NVRAM with OF and OSX partitions */
+void pmac_format_nvram_partition(MacIONVRAMState *nvr, int len)
+{
+/*
+ * Mac OS X expects side "B" of the flash at the second half of NVRAM,
+ * so we use half of the chip for OF and the other half for a free OSX
+ * partition.
+ */
+pmac_format_nvram_partition_of(nvr, 0, len / 2);
+pmac_format_nvram_partition_osx(nvr, len / 2, len / 2);
+}
type_init(macio_nvram_register_types)
--
1.8.1.4
Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes
On Jul 13, 2014, at 12:17 PM, Alexander Graf wrote: > While trying to get Mac OS X booting with our -M mac99 emulation I stumbled > over a few issues that prevented it from doing so. > > With these patches applied I still can't properly boot Mac OS X with -M mac99, > but I get a lot further than before. The biggest issue that's left now is to > properly fake Mac OS X into believing our timebase frequency. If I hack up the > cuda timer I can successfully boot Mac OS X on mac99: > Which version of Mac OS X are you testing out with this patch?
Re: [Qemu-devel] [PATCH 0/5] PPC: Mac99 emulation fixes
> Am 13.07.2014 um 19:51 schrieb Programmingkid : > > >> On Jul 13, 2014, at 12:17 PM, Alexander Graf wrote: >> >> While trying to get Mac OS X booting with our -M mac99 emulation I stumbled >> over a few issues that prevented it from doing so. >> >> With these patches applied I still can't properly boot Mac OS X with -M >> mac99, >> but I get a lot further than before. The biggest issue that's left now is to >> properly fake Mac OS X into believing our timebase frequency. If I hack up >> the >> cuda timer I can successfully boot Mac OS X on mac99: > > Which version of Mac OS X are you testing out with this patch? 10.2.something and 10.4.11. Alex
[Qemu-devel] hw/arm: add Lego NXT board
Hi, I developed a software in the loop simulator for the Lego Mindstorms NXT brick. It uses the Qemu ARM emulator to run the Robot's Firmware. I plan to release the simulator as an open source project. Now, I wonder if it makes sense to integrate the Qemu board implementation back into Qemu mainline or simply maintain it as an external set of patches. The problem is that the qemu board I designed is not self-contained. It allows the firmware to read/write IO memory in order to read back sensor values from the simulated environment and to control actuators. The environment simulator is an external program which is connected to several qemu instances via posix named pipes using a simple communication protocol. Without pipe interaction the emulator can still be used to debug NXT firmware images without sensor/actuator interaction. I'm happy to prepare a patch, but do you think it is of any value to integrate code that is not 100% self contained? Best Regards Alexander
[Qemu-devel] [PATCH 2/2] PPC: Cuda: Use cuda timer to expose tbfreq to guest
Mac OS X calibrates a number of frequencies on bootup based on reading
tb values on bootup and comparing them to via cuda timer values.
The only variable we can really steer well (thanks to KVM) is the cuda
frequency. So let's use that one to fake Mac OS X into believing the
bus frequency is tbfreq * 4. That way Mac OS X will automatically
calculate the correct timebase frequency.
With this patch and the patch set I posted earlier I can successfully
run Mac OS X 10.2, 10.3 and 10.4 guests with -M mac99 on TCG and KVM.
Suggested-by: Benjamin Herrenschmidt
Signed-off-by: Alexander Graf
---
hw/misc/macio/cuda.c | 28 ++--
hw/misc/macio/macio.c | 10 ++
hw/ppc/mac.h | 2 ++
hw/ppc/mac_newworld.c | 1 +
hw/ppc/mac_oldworld.c | 1 +
5 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index ff6051d..81e54b8 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -102,7 +102,6 @@
#define CUDA_TIMER_TICKLE 0x24
#define CUDA_COMBINED_FORMAT_IIC 0x25
-#define CUDA_TIMER_FREQ (470 / 6)
#define CUDA_ADB_POLL_FREQ 50
/* CUDA returns time_t's offset from Jan 1, 1904, not 1970 */
@@ -123,13 +122,22 @@ static void cuda_update_irq(CUDAState *s)
}
}
+static uint64_t get_tb(uint64_t freq)
+{
+return muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
+freq, get_ticks_per_sec());
+}
+
static unsigned int get_counter(CUDATimer *s)
{
int64_t d;
unsigned int counter;
+uint64_t tb_diff;
+
+/* Reverse of the tb calculation algorithm that Mac OS X uses on bootup. */
+tb_diff = get_tb(s->frequency) - s->load_time;
+d = (tb_diff * 0xBF401675E5DULL) / (s->frequency << 24);
-d = muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) - s->load_time,
- CUDA_TIMER_FREQ, get_ticks_per_sec());
if (s->index == 0) {
/* the timer goes down from latch to -1 (period of latch + 2) */
if (d <= (s->counter_value + 1)) {
@@ -147,7 +155,7 @@ static unsigned int get_counter(CUDATimer *s)
static void set_counter(CUDAState *s, CUDATimer *ti, unsigned int val)
{
CUDA_DPRINTF("T%d.counter=%d\n", 1 + (ti->timer == NULL), val);
-ti->load_time = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+ti->load_time = get_tb(s->frequency);
ti->counter_value = val;
cuda_timer_update(s, ti, ti->load_time);
}
@@ -159,7 +167,7 @@ static int64_t get_next_irq_time(CUDATimer *s, int64_t
current_time)
/* current counter value */
d = muldiv64(current_time - s->load_time,
- CUDA_TIMER_FREQ, get_ticks_per_sec());
+ s->frequency, get_ticks_per_sec());
/* the timer goes down from latch to -1 (period of latch + 2) */
if (d <= (s->counter_value + 1)) {
counter = (s->counter_value - d) & 0x;
@@ -178,7 +186,7 @@ static int64_t get_next_irq_time(CUDATimer *s, int64_t
current_time)
}
CUDA_DPRINTF("latch=%d counter=%" PRId64 " delta_next=%" PRId64 "\n",
s->latch, d, next_time - d);
-next_time = muldiv64(next_time, get_ticks_per_sec(), CUDA_TIMER_FREQ) +
+next_time = muldiv64(next_time, get_ticks_per_sec(), s->frequency) +
s->load_time;
if (next_time <= current_time)
next_time = current_time + 1;
@@ -688,6 +696,8 @@ static void cuda_realizefn(DeviceState *dev, Error **errp)
struct tm tm;
s->timers[0].timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, cuda_timer1, s);
+s->timers[0].frequency = s->frequency;
+s->timers[1].frequency = s->frequency;
qemu_get_timedate(&tm, 0);
s->tick_offset = (uint32_t)mktimegm(&tm) + RTC_OFFSET;
@@ -713,6 +723,11 @@ static void cuda_initfn(Object *obj)
DEVICE(obj), "adb.0");
}
+static Property cuda_properties[] = {
+DEFINE_PROP_UINT64("frequency", CUDAState, frequency, 0),
+DEFINE_PROP_END_OF_LIST()
+};
+
static void cuda_class_init(ObjectClass *oc, void *data)
{
DeviceClass *dc = DEVICE_CLASS(oc);
@@ -720,6 +735,7 @@ static void cuda_class_init(ObjectClass *oc, void *data)
dc->realize = cuda_realizefn;
dc->reset = cuda_reset;
dc->vmsd = &vmstate_cuda;
+dc->props = cuda_properties;
}
static const TypeInfo cuda_type_info = {
diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 35eaa00..e0f1e88 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -42,6 +42,7 @@ typedef struct MacIOState
void *dbdma;
MemoryRegion *pic_mem;
MemoryRegion *escc_mem;
+uint64_t frequency;
} MacIOState;
#define OLDWORLD_MACIO(obj) \
@@ -351,12 +352,19 @@ static void macio_newworld_class_init(ObjectClass *oc,
void *data)
pdc->device_id = PCI_DEVICE_ID_APPLE_UNI_N_KEYL;
}
+static Property macio_properties[] = {
+DEFINE_PROP_UINT64("frequency", MacIOState, frequency, 0),
+DEFINE_PROP_END_OF_LIST()
+};
+
static void macio_class_init(ObjectClass *klass, void *d
[Qemu-devel] [PATCH 1/2] PPC: Mac: Move tbfreq into local variable
We already expose the real CPU's tb frequency to the guest via fw_cfg. Soon
we will need to also expose it to the MacIO, so let's move it to a variable
that we can leverage every time we need the frequency.
Signed-off-by: Alexander Graf
---
hw/ppc/mac_newworld.c | 13 ++---
hw/ppc/mac_oldworld.c | 12 +---
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 32ee2f2..419d2b4 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -177,6 +177,7 @@ static void ppc_core99_init(MachineState *machine)
DeviceState *dev;
int *token = g_new(int, 1);
hwaddr nvram_addr = 0xFFF04000;
+uint64_t tbfreq;
linux_boot = (kernel_filename != NULL);
@@ -373,6 +374,14 @@ static void ppc_core99_init(MachineState *machine)
pci_bus = pci_pmac_init(pic, get_system_memory(), get_system_io());
machine_arch = ARCH_MAC99;
}
+
+/* Timebase Frequency */
+if (kvm_enabled()) {
+tbfreq = kvmppc_get_tbfreq();
+} else {
+tbfreq = TBFREQ;
+}
+
/* init basic PC hardware */
escc_mem = escc_init(0, pic[0x25], pic[0x24],
serial_hds[0], serial_hds[1], ESCC_CLOCK, 4);
@@ -469,15 +478,13 @@ static void ppc_core99_init(MachineState *machine)
#ifdef CONFIG_KVM
uint8_t *hypercall;
-fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_TBFREQ, kvmppc_get_tbfreq());
hypercall = g_malloc(16);
kvmppc_get_hypercall(env, hypercall, 16);
fw_cfg_add_bytes(fw_cfg, FW_CFG_PPC_KVM_HC, hypercall, 16);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_KVM_PID, getpid());
#endif
-} else {
-fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_TBFREQ, TBFREQ);
}
+fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_TBFREQ, tbfreq);
/* Mac OS X requires a "known good" clock-frequency value; pass it one. */
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 4b5e905..8a6cec9 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -103,6 +103,7 @@ static void ppc_heathrow_init(MachineState *machine)
uint16_t ppc_boot_device;
DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
void *fw_cfg;
+uint64_t tbfreq;
linux_boot = (kernel_filename != NULL);
@@ -249,6 +250,13 @@ static void ppc_heathrow_init(MachineState *machine)
}
}
+/* Timebase Frequency */
+if (kvm_enabled()) {
+tbfreq = kvmppc_get_tbfreq();
+} else {
+tbfreq = TBFREQ;
+}
+
/* init basic PC hardware */
if (PPC_INPUT(env) != PPC_FLAGS_INPUT_6xx) {
hw_error("Only 6xx bus is supported on heathrow machine\n");
@@ -329,15 +337,13 @@ static void ppc_heathrow_init(MachineState *machine)
#ifdef CONFIG_KVM
uint8_t *hypercall;
-fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_TBFREQ, kvmppc_get_tbfreq());
hypercall = g_malloc(16);
kvmppc_get_hypercall(env, hypercall, 16);
fw_cfg_add_bytes(fw_cfg, FW_CFG_PPC_KVM_HC, hypercall, 16);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_KVM_PID, getpid());
#endif
-} else {
-fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_TBFREQ, TBFREQ);
}
+fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_TBFREQ, tbfreq);
/* Mac OS X requires a "known good" clock-frequency value; pass it one. */
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
--
1.8.1.4
Re: [Qemu-devel] [PATCH] qtest: fix vhost-user-test compilation with old GLib
On Wed, Jul 09, 2014 at 06:06:32PM +0300, Nikolay Nikolaev wrote: > Mising G_TIME_SPAN_SECOND definition breaks the RHEL6 compilation as GLib > version before 2.26 does not have it. In such case just define it. > > Reported-by: Kevin Wolf > Signed-off-by: Nikolay Nikolaev Applied, thanks! > --- > tests/vhost-user-test.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/tests/vhost-user-test.c b/tests/vhost-user-test.c > index b9dcec1..75fedf0 100644 > --- a/tests/vhost-user-test.c > +++ b/tests/vhost-user-test.c > @@ -22,6 +22,10 @@ > #include > > /* GLIB version compatibility flags */ > +#if !GLIB_CHECK_VERSION(2, 26, 0) > +#define G_TIME_SPAN_SECOND (G_GINT64_CONSTANT(100)) > +#endif > + > #if GLIB_CHECK_VERSION(2, 28, 0) > #define HAVE_MONOTONIC_TIME > #endif
