Re: [Qemu-devel] [V5 PATCH 0/4] Send gratuitous packets by guest

[Michael S. Tsirkin]

On Mon, Mar 26, 2012 at 05:10:15PM -0500, Anthony Liguori wrote:
> On 03/16/2012 03:54 AM, Jason Wang wrote:
> >This an update of series that let guest and qemu to be co-operated to
> >send gratuitous packets when needed such as after migration, loadvm
> >and continuing.
> >
> >As it's hard for qemu to track the network configuration in guest such
> >as bondings, vlans or ipv6. So current gratuitous may not work under
> >those situations.
> 
> Can you be more specific about the failure scenarios?
> 
> Does this mean that migration cannot work today with guests using
> ipv6?  I don't think just pushing this to the guest is an acceptable
> solution in the short term.
> 
> Are there scenarios we cannot handle no matter what in the host?

Consider a nested virt scenario. It seems clear that you either
must notify the guest about migration, or learn nested
guest macs.

> Does this mean that for emulated drivers, we're completely out of
> luck?
> 
> Regards,
> 
> Anthony Liguori

For these, I think we can cause announcements by sending link up event
to the guest.

-- 
MST

[Qemu-devel] [PATCH 2/2] block: disable I/O throttling on sync api

[zwu . kernel]

From: Zhi Yong Wu 

Signed-off-by: Stefan Hajnoczi 
Signed-off-by: Zhi Yong Wu 
---
 block.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 1fbf4dd..5baf340 100644
--- a/block.c
+++ b/block.c
@@ -1477,6 +1477,12 @@ static int bdrv_rw_co(BlockDriverState *bs, int64_t 
sector_num, uint8_t *buf,
 
 qemu_iovec_init_external(&qiov, &iov, 1);
 
+if (bs->io_limits_enabled) {
+fprintf(stderr, "Disabling I/O throttling on '%s' due "
+"to synchronous I/O.\n", bdrv_get_device_name(bs));
+bdrv_io_limits_disable(bs);
+}
+
 if (qemu_in_coroutine()) {
 /* Fast-path if already in coroutine context */
 bdrv_rw_co_entry(&rwco);
-- 
1.7.6

[Qemu-devel] [PATCH 1/2] block: add the support to drain throttled requests

[zwu . kernel]

From: Zhi Yong Wu 

Signed-off-by: Paolo Bonzini 
Signed-off-by: Zhi Yong Wu 
---
 block.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/block.c b/block.c
index b88ee90..1fbf4dd 100644
--- a/block.c
+++ b/block.c
@@ -862,8 +862,22 @@ void bdrv_close_all(void)
 void bdrv_drain_all(void)
 {
 BlockDriverState *bs;
+bool busy;
 
-qemu_aio_flush();
+do {
+busy = false;
+qemu_aio_flush();
+
+/* FIXME: We do not have timer support here, so this is effectively
+ * a busy wait.
+ */
+QTAILQ_FOREACH(bs, &bdrv_states, list) {
+if (!qemu_co_queue_empty(&bs->throttled_reqs)) {
+qemu_co_queue_restart_all(&bs->throttled_reqs);
+busy = true;
+}
+}
+} while (busy);
 
 /* If requests are still pending there is a bug somewhere */
 QTAILQ_FOREACH(bs, &bdrv_states, list) {
-- 
1.7.6

[Qemu-devel] [PATCH v4] w32: Support tests (make check)

[Stefan Weil]

Adding $(EXESUF) is needed to make those tests work on w32 hosts, too.

v2:
Rebased, added new tests, tests sorted alphabetically.

v3:
Rebased, $(EXESUF) for qemu-img, qemu-io which were recently added.

v4:
Rebased, new test test-qmp-commands which was recently added.

Cc: Anthony Liguori 
Cc: Kevin Wolf 
Cc: Andreas Färber 
Reviewed-by: Andreas Färber 
Signed-off-by: Stefan Weil 
---

This is the 4rd version of my patch. The 1st was sent in February,
and again some other newer (!) patches were committed,
so I had to rebase my patch a third time now.

Anthony, please commit.

Cheers,
Stefan Weil

 tests/Makefile |   42 +-
 1 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/tests/Makefile b/tests/Makefile
index 94ea342..ca03b3a 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -1,20 +1,28 @@
 export SRC_PATH
 
-CHECKS = check-qdict check-qfloat check-qint check-qstring check-qlist
-CHECKS += check-qjson test-qmp-output-visitor test-qmp-input-visitor
-CHECKS += test-string-input-visitor test-string-output-visitor test-coroutine
-CHECKS += test-qmp-commands
+CHECKS = check-qdict$(EXESUF)
+CHECKS += check-qfloat$(EXESUF)
+CHECKS += check-qint$(EXESUF)
+CHECKS += check-qjson$(EXESUF)
+CHECKS += check-qlist$(EXESUF)
+CHECKS += check-qstring$(EXESUF)
+CHECKS += test-coroutine$(EXESUF)
+CHECKS += test-qmp-commands$(EXESUF)
+CHECKS += test-qmp-input-visitor$(EXESUF)
+CHECKS += test-qmp-output-visitor$(EXESUF)
+CHECKS += test-string-input-visitor$(EXESUF)
+CHECKS += test-string-output-visitor$(EXESUF)
 CHECKS += $(SRC_PATH)/tests/qemu-iotests-quick.sh
 
 check-qint.o check-qstring.o check-qdict.o check-qlist.o check-qfloat.o 
check-qjson.o test-coroutine.o: $(GENERATED_HEADERS)
 
-check-qint: check-qint.o qint.o $(tools-obj-y)
-check-qstring: check-qstring.o qstring.o $(tools-obj-y)
-check-qdict: check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o qlist.o 
$(tools-obj-y)
-check-qlist: check-qlist.o qlist.o qint.o $(tools-obj-y)
-check-qfloat: check-qfloat.o qfloat.o $(tools-obj-y)
-check-qjson: check-qjson.o $(qobject-obj-y) $(tools-obj-y)
-test-coroutine: test-coroutine.o qemu-timer-common.o async.o 
$(coroutine-obj-y) $(tools-obj-y)
+check-qint$(EXESUF): check-qint.o qint.o $(tools-obj-y)
+check-qstring$(EXESUF): check-qstring.o qstring.o $(tools-obj-y)
+check-qdict$(EXESUF): check-qdict.o qdict.o qfloat.o qint.o qstring.o qbool.o 
qlist.o $(tools-obj-y)
+check-qlist$(EXESUF): check-qlist.o qlist.o qint.o $(tools-obj-y)
+check-qfloat$(EXESUF): check-qfloat.o qfloat.o $(tools-obj-y)
+check-qjson$(EXESUF): check-qjson.o $(qobject-obj-y) $(tools-obj-y)
+test-coroutine$(EXESUF): test-coroutine.o qemu-timer-common.o async.o 
$(coroutine-obj-y) $(tools-obj-y)
 
 test-qmp-input-visitor.o test-qmp-output-visitor.o \
 test-string-input-visitor.o test-string-output-visitor.o \
@@ -32,21 +40,21 @@ $(SRC_PATH)/qapi-schema-test.json 
$(SRC_PATH)/scripts/qapi-commands.py
 
 
 test-string-output-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c 
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h) $(qapi-obj-y)
-test-string-output-visitor: test-string-output-visitor.o $(qobject-obj-y) 
$(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
+test-string-output-visitor$(EXESUF): test-string-output-visitor.o 
$(qobject-obj-y) $(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
 
 test-string-input-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c 
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h) $(qapi-obj-y)
-test-string-input-visitor: test-string-input-visitor.o $(qobject-obj-y) 
$(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
+test-string-input-visitor$(EXESUF): test-string-input-visitor.o 
$(qobject-obj-y) $(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
 
 test-qmp-output-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c 
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h) $(qapi-obj-y)
-test-qmp-output-visitor: test-qmp-output-visitor.o $(qobject-obj-y) 
$(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
+test-qmp-output-visitor$(EXESUF): test-qmp-output-visitor.o $(qobject-obj-y) 
$(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
 
 test-qmp-input-visitor.o: $(addprefix $(qapi-dir)/, test-qapi-types.c 
test-qapi-types.h test-qapi-visit.c test-qapi-visit.h) $(qapi-obj-y)
-test-qmp-input-visitor: test-qmp-input-visitor.o $(qobject-obj-y) 
$(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
+test-qmp-input-visitor$(EXESUF): test-qmp-input-visitor.o $(qobject-obj-y) 
$(qapi-obj-y) $(tools-obj-y) $(qapi-dir)/test-qapi-visit.o 
$(qapi-dir)/test-qapi-types.o
 
 test-qmp-commands.o: $(addprefix $(qapi-dir)/, test-qapi-types.c 
test-qapi-types.h test-qapi-visit.c test-qapi-visit.

Re: [Qemu-devel] [PATCH 1/2] Isolation groups

[David Gibson]

On Wed, Mar 21, 2012 at 03:12:58PM -0600, Alex Williamson wrote:
> On Sat, 2012-03-17 at 15:57 +1100, David Gibson wrote:
> > On Fri, Mar 16, 2012 at 01:31:18PM -0600, Alex Williamson wrote:
> > > On Fri, 2012-03-16 at 14:45 +1100, David Gibson wrote:
> > > > On Thu, Mar 15, 2012 at 02:15:01PM -0600, Alex Williamson wrote:
> > > > > On Wed, 2012-03-14 at 20:58 +1100, David Gibson wrote:
> > > > > > On Tue, Mar 13, 2012 at 10:49:47AM -0600, Alex Williamson wrote:
> > > > > > > On Wed, 2012-03-14 at 01:33 +1100, David Gibson wrote:
> > > > > > > > On Mon, Mar 12, 2012 at 04:32:54PM -0600, Alex Williamson wrote:
> > > > > > > > > +/*
> > > > > > > > > + * Add a device to an isolation group.  Isolation groups 
> > > > > > > > > start empty and
> > > > > > > > > + * must be told about the devices they contain.  Expect this 
> > > > > > > > > to be called
> > > > > > > > > + * from isolation group providers via notifier.
> > > > > > > > > + */
> > > > > > > > 
> > > > > > > > Doesn't necessarily have to be from a notifier, particularly if 
> > > > > > > > the
> > > > > > > > provider is integrated into host bridge code.
> > > > > > > 
> > > > > > > Sure, a provider could do this on it's own if it wants.  This just
> > > > > > > provides some infrastructure for a common path.  Also note that 
> > > > > > > this
> > > > > > > helps to eliminate all the #ifdef CONFIG_ISOLATION in the 
> > > > > > > provider.  Yet
> > > > > > > to be seen whether that can reasonably be the case once isolation 
> > > > > > > groups
> > > > > > > are added to streaming DMA paths.
> > > > > > 
> > > > > > Right, but other than the #ifdef safety, which could be achieved 
> > > > > > more
> > > > > > simply, I'm not seeing what benefit the infrastructure provides over
> > > > > > directly calling the bus notifier function.  The infrastructure 
> > > > > > groups
> > > > > > the notifiers by bus type internally, but AFAICT exactly one bus
> > > > > > notifier call would become exactly one isolation notifier call, and
> > > > > > the notifier callback itself would be almost identical.
> > > > > 
> > > > > I guess I don't see this as a fundamental design point of the 
> > > > > proposal,
> > > > > it's just a convenient way to initialize groups as a side-band 
> > > > > addition
> > > > > until isolation groups become a more fundamental part of the iommu
> > > > > infrastructure.  If you want to do that level of integration in your
> > > > > provider, do it and make the callbacks w/o the notifier.  If nobody 
> > > > > ends
> > > > > up using them, we'll remove them.  Maybe it will just end up being a
> > > > > bootstrap.  In the typical case, yes, one bus notifier is one 
> > > > > isolation
> > > > > notifier.  It does however also allow one bus notifier to become
> > > > > multiple isolation notifiers, and includes some filtering that would
> > > > > just be duplicated if every provider decided to implement their own 
> > > > > bus
> > > > > notifier.
> > > > 
> > > > Uh.. I didn't notice any filtering?  That's why I'm asking.
> > > 
> > > Not much, but a little:
> > > 
> > > +   switch (action) {
> > > +   case BUS_NOTIFY_ADD_DEVICE:
> > > +   if (!dev->isolation_group)
> > > +   blocking_notifier_call_chain(¬ifier->notifier,
> > > +   ISOLATION_NOTIFY_ADD_DEVICE, dev);
> > > +   break;
> > > +   case BUS_NOTIFY_DEL_DEVICE:
> > > +   if (dev->isolation_group)
> > > +   blocking_notifier_call_chain(¬ifier->notifier,
> > > +   ISOLATION_NOTIFY_DEL_DEVICE, dev);
> > > +   break;
> > > +   }
T> > 
> > 
> > Ah, I see, fair enough.
> > 
> > A couple of tangential observations.  First, I suspect using
> > BUS_NOTIFY_DEL_DEVICE is a very roundabout way of handling hot-unplug,
> > it might be better to have an unplug callback in the group instead.
> 
> There's really one already.  Assuming the device is attached to a group
> driver, the .remove entry point on the driver will get called first.  It
> doesn't get to return error, but it can block.

Hrm.  Assuming the isolation provider has installed a driver for the
relevant bus type.  And as we're discussing elsewhere, I think we have
situations where the groups will get members on (subordinate) busses
which the isolation provider doesn't have explicit knowledge of.

> The DEL_DEVICE will only
> happen after the group driver has relinquished the device, or at least
> returned from remove().  For a device with no driver, the group would
> only learn about it through the notifier, but it probably doesn't need
> anything more direct.

DEL_DEVICE is certainly sufficient, it just seems a bit unnecessarily
awkward.

> > Second, I don't think aborting the call chain early for hot-plug is
> > actually a good idea.  I can't see a clear guarantee on the order, so
> > individual providers couldn't rely on that short-cut behaviour.  Whi

[Qemu-devel] [PATCH 2/2] block: disable I/O throttling on sync api

[zwu . kernel]

From: Zhi Yong Wu 

Signed-off-by: Zhi Yong Wu 
---
 block.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/block.c b/block.c
index 1fbf4dd..5baf340 100644
--- a/block.c
+++ b/block.c
@@ -1477,6 +1477,12 @@ static int bdrv_rw_co(BlockDriverState *bs, int64_t 
sector_num, uint8_t *buf,
 
 qemu_iovec_init_external(&qiov, &iov, 1);
 
+if (bs->io_limits_enabled) {
+fprintf(stderr, "Disabling I/O throttling on '%s' due "
+"to synchronous I/O.\n", bdrv_get_device_name(bs));
+bdrv_io_limits_disable(bs);
+}
+
 if (qemu_in_coroutine()) {
 /* Fast-path if already in coroutine context */
 bdrv_rw_co_entry(&rwco);
-- 
1.7.6

[Qemu-devel] [PATCH 1/2] block: add the support to drain throttled requests

[zwu . kernel]

From: Zhi Yong Wu 

Signed-off-by: Zhi Yong Wu 
---
 block.c |   16 +++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/block.c b/block.c
index b88ee90..1fbf4dd 100644
--- a/block.c
+++ b/block.c
@@ -862,8 +862,22 @@ void bdrv_close_all(void)
 void bdrv_drain_all(void)
 {
 BlockDriverState *bs;
+bool busy;
 
-qemu_aio_flush();
+do {
+busy = false;
+qemu_aio_flush();
+
+/* FIXME: We do not have timer support here, so this is effectively
+ * a busy wait.
+ */
+QTAILQ_FOREACH(bs, &bdrv_states, list) {
+if (!qemu_co_queue_empty(&bs->throttled_reqs)) {
+qemu_co_queue_restart_all(&bs->throttled_reqs);
+busy = true;
+}
+}
+} while (busy);
 
 /* If requests are still pending there is a bug somewhere */
 QTAILQ_FOREACH(bs, &bdrv_states, list) {
-- 
1.7.6

Re: [Qemu-devel] [PATCH] block: add the support to drain throttled requests

[Zhi Yong Wu]

On Mon, Mar 26, 2012 at 10:21 PM, Stefan Hajnoczi  wrote:
> On Tue, Mar 20, 2012 at 11:44 AM, Stefan Hajnoczi
>  wrote:
>> On Tue, Mar 20, 2012 at 10:58:10AM +0100, Kevin Wolf wrote:
>>> Am 20.03.2012 10:47, schrieb Paolo Bonzini:
>>> > Il 20/03/2012 10:40, Zhi Yong Wu ha scritto:
>>> >> HI, Kevin,
>>> >>
>>> >> We hope that I/O throttling can be shipped without known issue in QEMU
>>> >> 1.1, so if you are available, can you give this patch some love?
>>> >
>>> > I'm sorry to say this, but I think I/O throttling is impossible to save.
>>> >  As it is implemented now, it just cannot work in the presence of
>>> > synchronous I/O, except at the cost of busy waiting with the global
>>> > mutex taken.  See the message from Stefan yesterday.
>>>
>>> qemu_aio_flush() is busy waiting with the global mutex taken anyway, so
>>> it doesn't change that much.
>>
>> Yesterday I only posted an analysis of the bug but here are some
>> thoughts on how to move forward.  Throttling itself is not the problem.
>> We've known that synchronous operations in the vcpu thread are a problem
>> long before throttling.  This is just another reason to convert device
>> emulation to use asynchronous interfaces.
>>
>> Here is the list of device models that perform synchronous block I/O:
>> hw/fdc.c
>> hw/ide/atapi.c
>> hw/ide/core.c
>> hw/nand.c
>> hw/onenand.c
>> hw/pflash_cfi01.c
>> hw/pflash_cfi02.c
>> hw/sd.c
>>
>> Zhi Hui Li is working on hw/fdc.c and recently sent a patch.
>>
>> I think it's too close to QEMU 1.1 to convert all the remaining devices
>> and test them properly before the soft-freeze.  But it's probably
>> possible to convert IDE before the soft-freeze.
>>
>> In the meantime we could add this to bdrv_rw_co():
>>
>> if (bs->io_limits_enabled) {
>>    fprintf(stderr, "Disabling I/O throttling on '%s' due "
>>            "to synchronous I/O\n", bdrv_get_device_name(bs));
>>    bdrv_io_limits_disable(bs);
>> }
>>
>> It's not pretty but tells the user there is an issue and avoids
>> deadlocking.
>
> No one has commented on this suggestion.  I think leaving a known hang
> in QEMU 1.1 is undesirable.  Better to have this warning and disable
> throttling in the case we cannot support right now.
IDE is using both sync API and async API when guest boot.
>
> Kevin: Would you accept a patch like this?  Or do you have another
> solution in mind?
>
> Stefan



-- 
Regards,

Zhi Yong Wu

[Qemu-devel] [PATCH]booke:Use MMU API for creating initial mapping for secondary cpus

[Bharat Bhushan]

Initial Mapping creation for secondary CPU in SMP was missing new MMU API.

Signed-off-by: Bharat Bhushan 
---
 hw/ppce500_spin.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/ppce500_spin.c b/hw/ppce500_spin.c
index 6b8a189..e8cf154 100644
--- a/hw/ppce500_spin.c
+++ b/hw/ppce500_spin.c
@@ -86,6 +86,7 @@ static void mmubooke_create_initial_mapping(CPUState *env,
 tlb->mas2 = (va & TARGET_PAGE_MASK) | MAS2_M;
 tlb->mas7_3 = pa & TARGET_PAGE_MASK;
 tlb->mas7_3 |= MAS3_UR | MAS3_UW | MAS3_UX | MAS3_SR | MAS3_SW | MAS3_SX;
+env->tlb_dirty = true;
 }
 
 static void spin_kick(void *data)
-- 
1.7.0.4

Re: [Qemu-devel] [V5 PATCH 0/4] Send gratuitous packets by guest

[Jason Wang]

On 03/27/2012 06:10 AM, Anthony Liguori wrote:

On 03/16/2012 03:54 AM, Jason Wang wrote:

This an update of series that let guest and qemu to be co-operated to
send gratuitous packets when needed such as after migration, loadvm
and continuing.

As it's hard for qemu to track the network configuration in guest such
as bondings, vlans or ipv6. So current gratuitous may not work under
those situations.


Can you be more specific about the failure scenarios?


The failure can happen when:

- Guest does not use primary mac address. Current qemu only send rarp 
packets for primary mac address. This looks could be solved by iterating 
nic with mac address table, but their size are limited and guest could 
use all-uni/promisc mode to use more mac addresses. So it's almost 
impossible to track all addresses in qemu side.


- Guest have some network configuration such as 802.1Q vlan, in this 
case, we need to send tagged gratuitous packet which qemu can't handle.


The point is qemu does not know the network configuration in guest or 
how mac addresses are used, so it's better for us to let guest choose 
the correct way to do this if they can. If guest could not do the 
announcement, the rarp packets would be sent as in the past.


Does this mean that migration cannot work today with guests using 
ipv6?  I don't think just pushing this to the guest is an acceptable 
solution in the short term.




I haven't check, but w/o this patch a ipv4 rarp would be sent even guest 
are using ipv6; w/ this patch, a ipv6 neighbor advertisement would be 
sent by guest which looks pretty reasonable.


Did you see any drawbacks of this method? Xen and hyper-v also let guest 
to send gratuitous packet for their para-virtualized network card.
Are there scenarios we cannot handle no matter what in the host?  Does 
this mean that for emulated drivers, we're completely out of luck?




A possible improvement but not a final solution is to send garp for all 
address in the mac table I think.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 10/12 v11] make gdb_id() generally avialable and rename it to cpu_index()

[HATAYAMA Daisuke]

From: Wen Congyang 
Subject: [PATCH 10/12 v11] make gdb_id() generally avialable and rename it to 
cpu_index()
Date: Mon, 26 Mar 2012 18:05:39 +0800



>  
> -static inline int gdb_id(CPUArchState *env)
> -{
> -#if defined(CONFIG_USER_ONLY) && defined(CONFIG_USE_NPTL)
> -return env->host_tid;
> -#else
> -return env->cpu_index + 1;
> -#endif
> -}
> -




I meant in gdbstub.c:

static inline int gdb_id(CPUArchState *env)
{
return cpu_index(env);
}

Thanks.
HATAYAMA, Daisuke

[Qemu-devel] [PATCH] Use DMADirection type for dma_bdrv_io

[David Gibson]

Currently dma_bdrv_io() takes a 'to_dev' boolean parameter to
determine the direction of DMA it is emulating.  We already have a
DMADirection enum designed specifically to encode DMA directions.
This patch uses it for dma_bdrv_io() as well.  This involves removing
the DMADirection definition from the #ifdef it was inside, but since that
only existed to protect the definition of dma_addr_t from places where
config.h is not included, there wasn't any reason for it to be there in
the first place.

Cc: Kevin Wolf 

Signed-off-by: David Gibson 
---
 dma-helpers.c  |   20 
 dma.h  |   12 ++--
 hw/ide/core.c  |3 ++-
 hw/ide/macio.c |3 ++-
 4 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/dma-helpers.c b/dma-helpers.c
index c29ea6d..5f19a85 100644
--- a/dma-helpers.c
+++ b/dma-helpers.c
@@ -42,7 +42,7 @@ typedef struct {
 BlockDriverAIOCB *acb;
 QEMUSGList *sg;
 uint64_t sector_num;
-bool to_dev;
+DMADirection dir;
 bool in_cancel;
 int sg_cur_index;
 dma_addr_t sg_cur_byte;
@@ -76,7 +76,8 @@ static void dma_bdrv_unmap(DMAAIOCB *dbs)
 
 for (i = 0; i < dbs->iov.niov; ++i) {
 cpu_physical_memory_unmap(dbs->iov.iov[i].iov_base,
-  dbs->iov.iov[i].iov_len, !dbs->to_dev,
+  dbs->iov.iov[i].iov_len,
+  dbs->dir != DMA_DIRECTION_TO_DEVICE,
   dbs->iov.iov[i].iov_len);
 }
 qemu_iovec_reset(&dbs->iov);
@@ -123,7 +124,8 @@ static void dma_bdrv_cb(void *opaque, int ret)
 while (dbs->sg_cur_index < dbs->sg->nsg) {
 cur_addr = dbs->sg->sg[dbs->sg_cur_index].base + dbs->sg_cur_byte;
 cur_len = dbs->sg->sg[dbs->sg_cur_index].len - dbs->sg_cur_byte;
-mem = cpu_physical_memory_map(cur_addr, &cur_len, !dbs->to_dev);
+mem = cpu_physical_memory_map(cur_addr, &cur_len,
+  dbs->dir != DMA_DIRECTION_TO_DEVICE);
 if (!mem)
 break;
 qemu_iovec_add(&dbs->iov, mem, cur_len);
@@ -170,11 +172,11 @@ static AIOPool dma_aio_pool = {
 BlockDriverAIOCB *dma_bdrv_io(
 BlockDriverState *bs, QEMUSGList *sg, uint64_t sector_num,
 DMAIOFunc *io_func, BlockDriverCompletionFunc *cb,
-void *opaque, bool to_dev)
+void *opaque, DMADirection dir)
 {
 DMAAIOCB *dbs = qemu_aio_get(&dma_aio_pool, bs, cb, opaque);
 
-trace_dma_bdrv_io(dbs, bs, sector_num, to_dev);
+trace_dma_bdrv_io(dbs, bs, sector_num, (dir == DMA_DIRECTION_TO_DEVICE));
 
 dbs->acb = NULL;
 dbs->bs = bs;
@@ -182,7 +184,7 @@ BlockDriverAIOCB *dma_bdrv_io(
 dbs->sector_num = sector_num;
 dbs->sg_cur_index = 0;
 dbs->sg_cur_byte = 0;
-dbs->to_dev = to_dev;
+dbs->dir = dir;
 dbs->io_func = io_func;
 dbs->bh = NULL;
 qemu_iovec_init(&dbs->iov, sg->nsg);
@@ -195,14 +197,16 @@ BlockDriverAIOCB *dma_bdrv_read(BlockDriverState *bs,
 QEMUSGList *sg, uint64_t sector,
 void (*cb)(void *opaque, int ret), void 
*opaque)
 {
-return dma_bdrv_io(bs, sg, sector, bdrv_aio_readv, cb, opaque, false);
+return dma_bdrv_io(bs, sg, sector, bdrv_aio_readv, cb, opaque,
+   DMA_DIRECTION_FROM_DEVICE);
 }
 
 BlockDriverAIOCB *dma_bdrv_write(BlockDriverState *bs,
  QEMUSGList *sg, uint64_t sector,
  void (*cb)(void *opaque, int ret), void 
*opaque)
 {
-return dma_bdrv_io(bs, sg, sector, bdrv_aio_writev, cb, opaque, true);
+return dma_bdrv_io(bs, sg, sector, bdrv_aio_writev, cb, opaque,
+   DMA_DIRECTION_TO_DEVICE);
 }
 
 
diff --git a/dma.h b/dma.h
index 20e86d2..05ac325 100644
--- a/dma.h
+++ b/dma.h
@@ -17,6 +17,11 @@
 
 typedef struct ScatterGatherEntry ScatterGatherEntry;
 
+typedef enum {
+DMA_DIRECTION_TO_DEVICE = 0,
+DMA_DIRECTION_FROM_DEVICE = 1,
+} DMADirection;
+
 struct QEMUSGList {
 ScatterGatherEntry *sg;
 int nsg;
@@ -29,11 +34,6 @@ typedef target_phys_addr_t dma_addr_t;
 
 #define DMA_ADDR_FMT TARGET_FMT_plx
 
-typedef enum {
-DMA_DIRECTION_TO_DEVICE = 0,
-DMA_DIRECTION_FROM_DEVICE = 1,
-} DMADirection;
-
 struct ScatterGatherEntry {
 dma_addr_t base;
 dma_addr_t len;
@@ -51,7 +51,7 @@ typedef BlockDriverAIOCB *DMAIOFunc(BlockDriverState *bs, 
int64_t sector_num,
 BlockDriverAIOCB *dma_bdrv_io(BlockDriverState *bs,
   QEMUSGList *sg, uint64_t sector_num,
   DMAIOFunc *io_func, BlockDriverCompletionFunc 
*cb,
-  void *opaque, bool to_dev);
+  void *opaque, DMADirection dir);
 BlockDriverAIOCB *dma_bdrv_read(BlockDriverState *bs,
 QEMUSGList *sg, uint64_t sector,
 BlockDriverCompletionFunc *cb, void *opaque);
diff --git a/hw/

[Qemu-devel] [PATCH] Better support for dma_addr_t variables

[David Gibson]

A while back, we introduced the dma_addr_t type, which is supposed to
be used for bus visible memory addresses.  At present, this is an
alias for target_phys_addr_t, but this will change when we eventually
add support for guest visible IOMMUs.

There are some instances of target_phys_addr_t in the code now which
should really be dma_addr_t, but can't be trivially converted due to
missing features which this patch corrects.

 * We add DMA_ADDR_BITS analagous to TARGET_PHYS_ADDR_BITS.  This is
   important where we need to make a compile-time (#if) based on the
   size of dma_addr_t.

 * We add a new helper macro to create device properties which take a
   dma_addr_t, currently an alias to DEFINE_PROP_TADDR().

Signed-off-by: David Gibson 
---
 dma.h |1 +
 hw/qdev-dma.h |4 
 2 files changed, 5 insertions(+), 0 deletions(-)
 create mode 100644 hw/qdev-dma.h

diff --git a/dma.h b/dma.h
index 05ac325..463095c 100644
--- a/dma.h
+++ b/dma.h
@@ -32,6 +32,7 @@ struct QEMUSGList {
 #if defined(TARGET_PHYS_ADDR_BITS)
 typedef target_phys_addr_t dma_addr_t;
 
+#define DMA_ADDR_BITS TARGET_PHYS_ADDR_BITS
 #define DMA_ADDR_FMT TARGET_FMT_plx
 
 struct ScatterGatherEntry {
diff --git a/hw/qdev-dma.h b/hw/qdev-dma.h
new file mode 100644
index 000..e407771
--- /dev/null
+++ b/hw/qdev-dma.h
@@ -0,0 +1,4 @@
+#include "qdev-addr.h"
+
+#define DEFINE_PROP_DMAADDR(_n, _s, _f, _d)   \
+DEFINE_PROP_TADDR(_n, _s, _f, _d)
-- 
1.7.9.1

[Qemu-devel] [PATCH 05/12 v11] Add API to get memory mapping

[Wen Congyang]

Add API to get all virtual address and physical address mapping.
If the guest doesn't use paging, the virtual address is equal to the phyical
address. The virtual address and physical address mapping is for gdb's user, and
it does not include the memory that is not referenced by the page table. So if
you want to use crash to anaylze the vmcore, please do not specify -p option.
the reason why the -p option is not default explicitly: guest machine in a
catastrophic state can have corrupted memory, which we cannot trust.

Signed-off-by: Wen Congyang 
---
address hatayama's comment

 memory_mapping.c |   47 +++
 memory_mapping.h |   15 +++
 2 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/memory_mapping.c b/memory_mapping.c
index 718f271..627397a 100644
--- a/memory_mapping.c
+++ b/memory_mapping.c
@@ -164,3 +164,50 @@ void memory_mapping_list_init(MemoryMappingList *list)
 list->last_mapping = NULL;
 QTAILQ_INIT(&list->head);
 }
+
+#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
+
+static CPUArchState *find_paging_enabled_cpu(CPUArchState *start_cpu)
+{
+CPUArchState *env;
+
+for (env = start_cpu; env != NULL; env = env->next_cpu) {
+if (cpu_paging_enabled(env)) {
+return env;
+}
+}
+
+return NULL;
+}
+
+int qemu_get_guest_memory_mapping(MemoryMappingList *list)
+{
+CPUArchState *env, *first_paging_enabled_cpu;
+RAMBlock *block;
+ram_addr_t offset, length;
+int ret;
+
+first_paging_enabled_cpu = find_paging_enabled_cpu(first_cpu);
+if (first_paging_enabled_cpu) {
+for (env = first_paging_enabled_cpu; env != NULL; env = env->next_cpu) 
{
+ret = cpu_get_memory_mapping(list, env);
+if (ret < 0) {
+return -1;
+}
+}
+return 0;
+}
+
+/*
+ * If the guest doesn't use paging, the virtual address is equal to 
physical
+ * address.
+ */
+QLIST_FOREACH(block, &ram_list.blocks, next) {
+offset = block->offset;
+length = block->length;
+create_new_memory_mapping(list, offset, offset, length);
+}
+
+return 0;
+}
+#endif
diff --git a/memory_mapping.h b/memory_mapping.h
index 836b047..4d44641 100644
--- a/memory_mapping.h
+++ b/memory_mapping.h
@@ -44,4 +44,19 @@ void memory_mapping_list_free(MemoryMappingList *list);
 
 void memory_mapping_list_init(MemoryMappingList *list);
 
+/*
+ * Return value:
+ *0: success
+ *   -1: failed
+ *   -2: unsupported
+ */
+#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
+int qemu_get_guest_memory_mapping(MemoryMappingList *list);
+#else
+static inline int qemu_get_guest_memory_mapping(MemoryMappingList *list)
+{
+return -2;
+}
+#endif
+
 #endif
-- 
1.7.1

Re: [Qemu-devel] [PATCH 1/1] If user doesn't specify a uuid, generate a random one

[Serge E. Hallyn]

Quoting Anthony Liguori (anth...@codemonkey.ws):
> On 03/26/2012 10:13 AM, Serge E. Hallyn wrote:
> >Currently, if the user doesn't pass a uuid, the system uuid is set to
> >all zeros.  This patch generates a random one instead.
> >
> >Is there a reason to prefer all zeros?  If not, can a patch like this
> >one be applied?
> >
> >Signed-off-by: Serge Hallyn
> 
> The other hypervisors don't have a concept of a transient guest like QEMU 
> does.

True, and I generally don't like arguments of the form "but (some other)
does it like this," but...

> There is no state preserved between invocations of QEMU.

Right, and I really don't know how many users (besides me) run kvm
by hand, as opposed to using libvirt or testdrive.  Perhaps testdrive
should be extended.

> Setting a random UUID doesn't seem like the right answer to me as it
> would potentially break Windows VMs.
> 
> Perhaps if the DMI UUID isn't set, you could look at the root filesystem's 
> UUID?

Interesting idea.  I don't know enough to know at which point in the code
qemu would know that, but I can take a look.

> Not all platforms have a notion of platform UUID so as Ubuntu
> supports more architectures, this problem would have to be dealt
> with eventually.

So it sounds like in this form certainly it's nacked :)

thanks,
-serge

Re: [Qemu-devel] [PATCH 05/11 v10] Add API to get memory mapping

[Wen Congyang]

At 03/27/2012 09:01 AM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang 
> Subject: Re: [PATCH 05/11 v10] Add API to get memory mapping
> Date: Mon, 26 Mar 2012 10:44:40 +0800
> 
>> At 03/26/2012 10:31 AM, HATAYAMA Daisuke Wrote:
>>> From: Wen Congyang 
>>> Subject: Re: [PATCH 05/11 v10] Add API to get memory mapping
>>> Date: Mon, 26 Mar 2012 09:10:52 +0800
>>>
 At 03/23/2012 08:02 PM, HATAYAMA Daisuke Wrote:
> From: Wen Congyang 
> Subject: [PATCH 05/11 v10] Add API to get memory mapping
> Date: Tue, 20 Mar 2012 11:51:18 +0800
>
>> Add API to get all virtual address and physical address mapping.
>> If the guest doesn't use paging, the virtual address is equal to the 
>> phyical
>> address. The virtual address and physical address mapping is for gdb's 
>> user, and
>> it does not include the memory that is not referenced by the page table. 
>> So if
>> you want to use crash to anaylze the vmcore, please do not specify -p 
>> option.
>> the reason why the -p option is not default explicitly: guest machine in 
>> a
>> catastrophic state can have corrupted memory, which we cannot trust.
>>
>> Signed-off-by: Wen Congyang 
>> ---
>>  memory_mapping.c |   34 ++
>>  memory_mapping.h |   15 +++
>>  2 files changed, 49 insertions(+), 0 deletions(-)
>>
>> diff --git a/memory_mapping.c b/memory_mapping.c
>> index 718f271..b92e2f6 100644
>> --- a/memory_mapping.c
>> +++ b/memory_mapping.c
>> @@ -164,3 +164,37 @@ void memory_mapping_list_init(MemoryMappingList 
>> *list)
>>  list->last_mapping = NULL;
>>  QTAILQ_INIT(&list->head);
>>  }
>> +
>> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
>> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
>> +{
>> +CPUArchState *env;
>> +RAMBlock *block;
>> +ram_addr_t offset, length;
>> +int ret;
>> +bool paging_mode;
>> +
>> +paging_mode = cpu_paging_enabled(first_cpu);
>> +if (paging_mode) {
>
> On SMP with (n)-CPUs, we can do this check at most (n)-times.
>
> On Linux, user-mode tasks have differnet page tables. If refering to
> one page table, we can get one user-mode task memory only. Considering
> as much memory as possible, it's best to reference all CPUs with
> paging enabled and walk all the page tables.
>
> A problem is that linear addresses for user-mode tasks can inherently
> conflicts. Different user-mode tasks can have the same linear
> address. So, tools need to distinguish each PT_LOAD entry based on a
> pair of linear address and physical address, not linear address
> only. I don't know whether gdb does this.

 gdb only can process kernel space. Jan's gdb-python script may can process
 user-mode tasks, but we should get user-mode task's register from the 
 kernel
 or note, and convest virtual address/linear address to physicall address.

>>>
>>> After I send this, I came up with the problem of page tabel coherency:
>>> some page table has not updated yet so we see older ones. So if we use
>>
>> Tha page table is older? Do you mean the newest page table is in TLB and
>> is not flushed to memory?
>>
> 
> I say vmalloc() in most part. (to be honest I don't know other
> possibility now) In stable state of kernel, page tables are allocated
> when user processes are created (around dup_mm()?, IIRC), where part
> for kernel space is copied from init_mm.pgd. They are updated at
> runtime coherently from init_mm.pgd when page fault happens. I
> expressed the page table that has not updated yet as old. For this
> reason, paging can lead to different result for differnet CPU.

Yes, paging can lead to different result for differnet CPU.
But the paging purpose is: allow the user debug kernel by
using gdb to process the core file. If the user want to debug
the user process in the core file, he can get the user process's
core from vmcore by using crash's extend gcore module.

> 
>>> all the page tables referenced by all CPUs, we face inconsistency of
>>> some of the page tables. Essentially, we cannot avoid the issue that
>>> we see the page table older than the actual even if we use only one
>>> page table, but if restricting the use of page table to just one, we
>>> can at least avoid the inconsistency of multiple page tables. In other
>>> words, we can do paging processing normally though the table might be
>>> old.
>>>
>>> So, I think
>>> - using page tables for all the CPUs at the same time is problematic.
>>> - using only one page table of the exsiting CPUs is still safe.
>>>
>>> How about the code like this?
>>>
>>>   cpu = find_cpu_paging_enabled(env);
>>
>> If there are more than two cpu's paging is enabled, which cpu should be 
>> choosed?
>> We cannot say which one is better than another one.
>>
> 
> I think so too. But now it sees 

[Qemu-devel] [PATCH] Make live saving stages public and use their #defines

[Stefan Berger]

Make the different stages for live saving of state public and use
the #defines rather than numbers.

Signed-off-by: Stefan Berger 

---
 arch_init.c   |7 ---
 block-migration.c |8 
 savevm.c  |7 ---
 vmstate.h |8 
 4 files changed, 16 insertions(+), 14 deletions(-)

Index: qemu/savevm.c
===
--- qemu.orig/savevm.c
+++ qemu/savevm.c
@@ -1541,13 +1541,6 @@ static void vmstate_save(QEMUFile *f, Sa
 #define QEMU_VM_FILE_VERSION_COMPAT  0x0002
 #define QEMU_VM_FILE_VERSION 0x0003
 
-#define QEMU_VM_EOF  0x00
-#define QEMU_VM_SECTION_START0x01
-#define QEMU_VM_SECTION_PART 0x02
-#define QEMU_VM_SECTION_END  0x03
-#define QEMU_VM_SECTION_FULL 0x04
-#define QEMU_VM_SUBSECTION   0x05
-
 bool qemu_savevm_state_blocked(Error **errp)
 {
 SaveStateEntry *se;
Index: qemu/vmstate.h
===
--- qemu.orig/vmstate.h
+++ qemu/vmstate.h
@@ -31,6 +31,14 @@ typedef void SaveStateHandler(QEMUFile *
 typedef int SaveLiveStateHandler(QEMUFile *f, int stage, void *opaque);
 typedef int LoadStateHandler(QEMUFile *f, void *opaque, int version_id);
 
+/* stages of the live state handler */
+#define QEMU_VM_EOF  0x00
+#define QEMU_VM_SECTION_START0x01
+#define QEMU_VM_SECTION_PART 0x02
+#define QEMU_VM_SECTION_END  0x03
+#define QEMU_VM_SECTION_FULL 0x04
+#define QEMU_VM_SUBSECTION   0x05
+
 int register_savevm(DeviceState *dev,
 const char *idstr,
 int instance_id,
Index: qemu/arch_init.c
===
--- qemu.orig/arch_init.c
+++ qemu/arch_init.c
@@ -275,7 +275,7 @@ int ram_save_live(QEMUFile *f, int stage
 
 memory_global_sync_dirty_bitmap(get_system_memory());
 
-if (stage == 1) {
+if (stage == QEMU_VM_SECTION_START) {
 RAMBlock *block;
 bytes_transferred = 0;
 last_block = NULL;
@@ -330,7 +330,7 @@ int ram_save_live(QEMUFile *f, int stage
 }
 
 /* try transferring iterative blocks of memory */
-if (stage == 3) {
+if (stage == QEMU_VM_SECTION_END) {
 int bytes_sent;
 
 /* flush all remaining blocks regardless of rate limiting */
@@ -344,7 +344,8 @@ int ram_save_live(QEMUFile *f, int stage
 
 expected_time = ram_save_remaining() * TARGET_PAGE_SIZE / bwidth;
 
-return (stage == 2) && (expected_time <= migrate_max_downtime());
+return (stage == QEMU_VM_SECTION_PART) &&
+   (expected_time <= migrate_max_downtime());
 }
 
 static inline void *host_from_stream_offset(QEMUFile *f,
Index: qemu/block-migration.c
===
--- qemu.orig/block-migration.c
+++ qemu/block-migration.c
@@ -554,7 +554,7 @@ static int block_save_live(QEMUFile *f, 
 return 1;
 }
 
-if (stage == 1) {
+if (stage == QEMU_VM_SECTION_START) {
 init_blk_migration(f);
 
 /* start track dirty blocks */
@@ -571,7 +571,7 @@ static int block_save_live(QEMUFile *f, 
 
 blk_mig_reset_dirty_cursor();
 
-if (stage == 2) {
+if (stage == QEMU_VM_SECTION_PART) {
 /* control the rate of transfer */
 while ((block_mig_state.submitted +
 block_mig_state.read_done) * BLOCK_SIZE <
@@ -599,7 +599,7 @@ static int block_save_live(QEMUFile *f, 
 }
 }
 
-if (stage == 3) {
+if (stage == QEMU_VM_SECTION_END) {
 /* we know for sure that save bulk is completed and
all async read completed */
 assert(block_mig_state.submitted == 0);
@@ -620,7 +620,7 @@ static int block_save_live(QEMUFile *f, 
 
 qemu_put_be64(f, BLK_MIG_FLAG_EOS);
 
-return ((stage == 2) && is_stage2_completed());
+return ((stage == QEMU_VM_SECTION_PART) && is_stage2_completed());
 }
 
 static int block_load(QEMUFile *f, void *opaque, int version_id)

Re: [Qemu-devel] [PATCH 05/11 v10] Add API to get memory mapping

[HATAYAMA Daisuke]

From: Wen Congyang 
Subject: Re: [PATCH 05/11 v10] Add API to get memory mapping
Date: Mon, 26 Mar 2012 10:44:40 +0800

> At 03/26/2012 10:31 AM, HATAYAMA Daisuke Wrote:
>> From: Wen Congyang 
>> Subject: Re: [PATCH 05/11 v10] Add API to get memory mapping
>> Date: Mon, 26 Mar 2012 09:10:52 +0800
>> 
>>> At 03/23/2012 08:02 PM, HATAYAMA Daisuke Wrote:
 From: Wen Congyang 
 Subject: [PATCH 05/11 v10] Add API to get memory mapping
 Date: Tue, 20 Mar 2012 11:51:18 +0800

> Add API to get all virtual address and physical address mapping.
> If the guest doesn't use paging, the virtual address is equal to the 
> phyical
> address. The virtual address and physical address mapping is for gdb's 
> user, and
> it does not include the memory that is not referenced by the page table. 
> So if
> you want to use crash to anaylze the vmcore, please do not specify -p 
> option.
> the reason why the -p option is not default explicitly: guest machine in a
> catastrophic state can have corrupted memory, which we cannot trust.
>
> Signed-off-by: Wen Congyang 
> ---
>  memory_mapping.c |   34 ++
>  memory_mapping.h |   15 +++
>  2 files changed, 49 insertions(+), 0 deletions(-)
>
> diff --git a/memory_mapping.c b/memory_mapping.c
> index 718f271..b92e2f6 100644
> --- a/memory_mapping.c
> +++ b/memory_mapping.c
> @@ -164,3 +164,37 @@ void memory_mapping_list_init(MemoryMappingList 
> *list)
>  list->last_mapping = NULL;
>  QTAILQ_INIT(&list->head);
>  }
> +
> +#if defined(CONFIG_HAVE_GET_MEMORY_MAPPING)
> +int qemu_get_guest_memory_mapping(MemoryMappingList *list)
> +{
> +CPUArchState *env;
> +RAMBlock *block;
> +ram_addr_t offset, length;
> +int ret;
> +bool paging_mode;
> +
> +paging_mode = cpu_paging_enabled(first_cpu);
> +if (paging_mode) {

 On SMP with (n)-CPUs, we can do this check at most (n)-times.

 On Linux, user-mode tasks have differnet page tables. If refering to
 one page table, we can get one user-mode task memory only. Considering
 as much memory as possible, it's best to reference all CPUs with
 paging enabled and walk all the page tables.

 A problem is that linear addresses for user-mode tasks can inherently
 conflicts. Different user-mode tasks can have the same linear
 address. So, tools need to distinguish each PT_LOAD entry based on a
 pair of linear address and physical address, not linear address
 only. I don't know whether gdb does this.
>>>
>>> gdb only can process kernel space. Jan's gdb-python script may can process
>>> user-mode tasks, but we should get user-mode task's register from the kernel
>>> or note, and convest virtual address/linear address to physicall address.
>>>
>> 
>> After I send this, I came up with the problem of page tabel coherency:
>> some page table has not updated yet so we see older ones. So if we use
> 
> Tha page table is older? Do you mean the newest page table is in TLB and
> is not flushed to memory?
> 

I say vmalloc() in most part. (to be honest I don't know other
possibility now) In stable state of kernel, page tables are allocated
when user processes are created (around dup_mm()?, IIRC), where part
for kernel space is copied from init_mm.pgd. They are updated at
runtime coherently from init_mm.pgd when page fault happens. I
expressed the page table that has not updated yet as old. For this
reason, paging can lead to different result for differnet CPU.

>> all the page tables referenced by all CPUs, we face inconsistency of
>> some of the page tables. Essentially, we cannot avoid the issue that
>> we see the page table older than the actual even if we use only one
>> page table, but if restricting the use of page table to just one, we
>> can at least avoid the inconsistency of multiple page tables. In other
>> words, we can do paging processing normally though the table might be
>> old.
>> 
>> So, I think
>> - using page tables for all the CPUs at the same time is problematic.
>> - using only one page table of the exsiting CPUs is still safe.
>> 
>> How about the code like this?
>> 
>>   cpu = find_cpu_paging_enabled(env);
> 
> If there are more than two cpu's paging is enabled, which cpu should be 
> choosed?
> We cannot say which one is better than another one.
> 

I think so too. But now it sees only one CPU. Seeing all CPUs in order
can increase possibility to do paging, which must be better if users
want to do paging.

Thanks.
HATAYAMA, Daisuke

[Qemu-devel] [PATCH v2] block stream: close unused files and update ->backing_hd

[Marcelo Tosatti]

Close the now unused images that were part of the previous backing file
chain and adjust ->backing_hd, backing_filename and backing_format
properly.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=801449

Signed-off-by: Marcelo Tosatti 

diff --git a/block/stream.c b/block/stream.c
index d1b3986..5880288 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -76,6 +76,39 @@ static int coroutine_fn stream_populate(BlockDriverState *bs,
 return bdrv_co_copy_on_readv(bs, sector_num, nb_sectors, &qiov);
 }
 
+static void close_unused_images(BlockDriverState *top, BlockDriverState *base,
+const char *base_id)
+{
+BlockDriverState *intermediate;
+intermediate = top->backing_hd;
+
+while (intermediate) {
+BlockDriverState *unused;
+
+/* reached base */
+if (intermediate == base) {
+break;
+}
+
+unused = intermediate;
+intermediate = intermediate->backing_hd;
+unused->backing_hd = NULL;
+bdrv_delete(unused);
+}
+top->backing_hd = base;
+
+pstrcpy(top->backing_file, sizeof(top->backing_file), "");
+pstrcpy(top->backing_format, sizeof(top->backing_format), "");
+if (base_id) {
+pstrcpy(top->backing_file, sizeof(top->backing_file), base_id);
+if (base->drv) {
+pstrcpy(top->backing_format, sizeof(top->backing_format),
+base->drv->format_name);
+}
+}
+
+}
+
 /*
  * Given an image chain: [BASE] -> [INTER1] -> [INTER2] -> [TOP]
  *
@@ -221,6 +254,7 @@ retry:
 base_id = s->backing_file_id;
 }
 ret = bdrv_change_backing_file(bs, base_id, NULL);
+close_unused_images(bs, base, base_id);
 }
 
 qemu_vfree(buf);

Re: [Qemu-devel] [V5 PATCH 0/4] Send gratuitous packets by guest

[Anthony Liguori]

On 03/16/2012 03:54 AM, Jason Wang wrote:

This an update of series that let guest and qemu to be co-operated to
send gratuitous packets when needed such as after migration, loadvm
and continuing.

As it's hard for qemu to track the network configuration in guest such
as bondings, vlans or ipv6. So current gratuitous may not work under
those situations.


Can you be more specific about the failure scenarios?

Does this mean that migration cannot work today with guests using ipv6?  I don't 
think just pushing this to the guest is an acceptable solution in the short term.


Are there scenarios we cannot handle no matter what in the host?  Does this mean 
that for emulated drivers, we're completely out of luck?


Regards,

Anthony Liguori

Re: [Qemu-devel] [PULL 0/5] Trivial patches for 20 to 26 March 2012

[Anthony Liguori]

On 03/26/2012 07:07 AM, Stefan Hajnoczi wrote:

The following changes since commit cb1977d308f6e1d6bf398d42e6148187b82456c1:

   tcg-sparc: Add debug_frame support. (2012-03-24 19:57:58 +)

are available in the git repository at:

   git://github.com/stefanha/qemu.git trivial-patches

for you to fetch changes up to 95b752bc32ccabe48430c0d0062b7c6947d864d0:

   trace-events: Fix broken build caused by wrong format specifier (2012-03-26 
12:34:20 +0100)


Pulled.  Thanks.

Regards,

Anthony Liguori





Eduardo Habkost (1):
   vl.c: fix '-cpu ?' segfault

Michael Roth (3):
   test: remove qemu-ga reference
   qapi: remove print statements from test-qmp-commands
   test: add test-qmp-commands to make check

Stefan Weil (1):
   trace-events: Fix broken build caused by wrong format specifier

  Makefile|1 +
  test-qmp-commands.c |3 ---
  tests/Makefile  |3 ++-
  trace-events|2 +-
  vl.c|2 +-
  5 files changed, 5 insertions(+), 6 deletions(-)

Re: [Qemu-devel] [PULL] qemu-ga build fixes

[Anthony Liguori]

On 03/26/2012 01:28 PM, Michael Roth wrote:

The following changes since commit cb1977d308f6e1d6bf398d42e6148187b82456c1:

   tcg-sparc: Add debug_frame support. (2012-03-24 19:57:58 +)

are available in the git repository at:
   git://github.com/mdroth/qemu.git qga-pull-3-26-12


Pulled.  Thanks.

Regards,

Anthony Liguori




Michael Roth (1):
   qemu-ga: fix bsd build, and re-org linux-specific implementations

  qga/commands-posix.c |  111 +
  1 files changed, 66 insertions(+), 45 deletions(-)

Re: [Qemu-devel] [PULL 0/2] spice: 32bit support

[Anthony Liguori]

On 03/22/2012 08:40 AM, Gerd Hoffmann wrote:

   Hi,

This patch series fixes the remaining 32bit bugs in spice.  With this
series merged and the latest spice-server bits (from git, no release
yet) spice works on 32bit hosts too.

please pull,
   Gerd


Pulled.  Thanks.

Regards,

Anthony Liguori



The following changes since commit 33cf629a3754b58a1e2dbbe01d91d97e712b7c06:

   Merge remote-tracking branch 'sstabellini/saverestore-8' into staging 
(2012-03-19 13:39:42 -0500)

are available in the git repository at:

   git://anongit.freedesktop.org/spice/qemu spice.v51

Alon Levy (1):
   ui/spice-display: use uintptr_t when casting qxl physical addresses

Peter Maydell (1):
   ui/spice-display.c: Fix compilation warnings on 32 bit hosts

  ui/spice-display.c |   22 +++---
  1 files changed, 11 insertions(+), 11 deletions(-)

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 03:30 PM, Jan Kiszka wrote:

On 2012-03-26 22:13, Anthony Liguori wrote:

On 03/26/2012 03:10 PM, Jan Kiszka wrote:

On 2012-03-26 21:49, Anthony Liguori wrote:

On 03/26/2012 02:44 PM, Jan Kiszka wrote:
This would also mean that reference counting should be revisited
although with how dereferencing a parent affects the child.

It's not rocket science, but it's also something that needs to be done
carefully.


But all this is only a problem for these three here (PIT, RTC, HPET) as
their objects shall be embedded into the super-IO. If you only embed an
object pointer, it shouldn't be an issue anymore, no?


The reference counting stuff obviously needs to be looked at even in
this case.


A composite object is owned by its container. So it should go when the
container leaves.


It's more complicated than that because it's a tree, not a graph.  So there may 
be additional references held beyond the parent.



Also inheritance is not a problem here as we do not derive from the
three types in question. If there is a super/sub-class relation, those
need to share an internal header, of course.


Yes, but then you have two headers for every type.  Is that really a
good thing?


It's cleaner and more explicit than tagging members with comments. And
it's nothing we will have for each and every type as only a small subset
is actually inheriting, the mass is finalizing.


I don't fundamentally disagree with anything you're saying here.  I'm only 
pointing out that (1) it's not a trivial problem and (2) it's not an urgent problem.


Regards,

Anthony Liguori



Jan

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Jan Kiszka]

On 2012-03-26 22:13, Anthony Liguori wrote:
> On 03/26/2012 03:10 PM, Jan Kiszka wrote:
>> On 2012-03-26 21:49, Anthony Liguori wrote:
>>> On 03/26/2012 02:44 PM, Jan Kiszka wrote:
>>> This would also mean that reference counting should be revisited
>>> although with how dereferencing a parent affects the child.
>>>
>>> It's not rocket science, but it's also something that needs to be done
>>> carefully.
>>
>> But all this is only a problem for these three here (PIT, RTC, HPET) as
>> their objects shall be embedded into the super-IO. If you only embed an
>> object pointer, it shouldn't be an issue anymore, no?
> 
> The reference counting stuff obviously needs to be looked at even in
> this case.

A composite object is owned by its container. So it should go when the
container leaves.

> 
>> Also inheritance is not a problem here as we do not derive from the
>> three types in question. If there is a super/sub-class relation, those
>> need to share an internal header, of course.
> 
> Yes, but then you have two headers for every type.  Is that really a
> good thing?

It's cleaner and more explicit than tagging members with comments. And
it's nothing we will have for each and every type as only a small subset
is actually inheriting, the mass is finalizing.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH] qemu-ga: fix bsd build, and re-org linux-specific implementations

[Brad Smith]

On 25/03/12 3:40 PM, Michael Roth wrote:


Signed-off-by: Michael Roth
---
  qga/commands-posix.c |  111 +
  1 files changed, 66 insertions(+), 45 deletions(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 7b2be2f..faf970d 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -12,29 +12,30 @@
   */

  #include
+#include
+#include
+#include "qga/guest-agent-core.h"
+#include "qga-qmp-commands.h"
+#include "qerror.h"
+#include "qemu-queue.h"
+#include "host-utils.h"

  #if defined(__linux__)
  #include
  #include
-
-#if defined(__linux__)&&  defined(FIFREEZE)
-#define CONFIG_FSFREEZE
-#endif
-#endif
-
-#include
-#include
  #include
  #include
  #include
  #include
  #include
-#include "qga/guest-agent-core.h"
-#include "qga-qmp-commands.h"
-#include "qerror.h"
-#include "qemu-queue.h"
-#include "host-utils.h"

+#if defined(__linux__)&&  defined(FIFREEZE)
+#define CONFIG_FSFREEZE
+#endif
+#endif
+
+#if defined(__linux__)
+/* TODO: use this in place of all post-fork() fclose(std*) callers */
  static void reopen_fd_to_null(int fd)
  {
  int nullfd;
@@ -50,6 +51,7 @@ static void reopen_fd_to_null(int fd)
  close(nullfd);
  }
  }
+#endif /* defined(__linux__) */

  void qmp_guest_shutdown(bool has_mode, const char *mode, Error **err)
  {
@@ -309,7 +311,11 @@ static void guest_file_init(void)
  QTAILQ_INIT(&guest_file_state.filehandles);
  }

+/* linux-specific implementations. avoid this if at all possible. */
+#if defined(__linux__)
+
  #if defined(CONFIG_FSFREEZE)
+
  static void disable_logging(void)
  {
  ga_disable_logging(ga_state);
@@ -505,38 +511,7 @@ static void guest_fsfreeze_cleanup(void)
  }
  }
  }
-#else
-/*
- * Return status of freeze/thaw
- */
-GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error **err)
-{
-error_set(err, QERR_UNSUPPORTED);
-
-return 0;
-}
-
-/*
- * Walk list of mounted file systems in the guest, and freeze the ones which
- * are real local file systems.
- */
-int64_t qmp_guest_fsfreeze_freeze(Error **err)
-{
-error_set(err, QERR_UNSUPPORTED);
-
-return 0;
-}
-
-/*
- * Walk list of frozen file systems in the guest, and thaw them.
- */
-int64_t qmp_guest_fsfreeze_thaw(Error **err)
-{
-error_set(err, QERR_UNSUPPORTED);
-
-return 0;
-}
-#endif
+#endif /* CONFIG_FSFREEZE */

  #define LINUX_SYS_STATE_FILE "/sys/power/state"
  #define SUSPEND_SUPPORTED 0
@@ -904,6 +879,52 @@ error:
  return NULL;
  }

+#else /* defined(__linux__) */
+
+GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+
+return 0;
+}
+
+int64_t qmp_guest_fsfreeze_freeze(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+
+return 0;
+}
+
+int64_t qmp_guest_fsfreeze_thaw(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+
+return 0;
+}
+
+void qmp_guest_suspend_disk(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+void qmp_guest_suspend_ram(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+void qmp_guest_suspend_hybrid(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+GuestNetworkInterfaceList *qmp_guest_network_get_interfaces(Error **errp)
+{
+error_set(errp, QERR_UNSUPPORTED);
+return NULL;
+}
+
+#endif
+
  /* register init/cleanup routines for stateful command groups */
  void ga_command_state_init(GAState *s, GACommandState *cs)
  {


This builds. Thank you.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Qemu-devel] [PATCH v3 1/5] qerror: add error codes for fopen failure

[Alon Levy]

On Fri, Mar 23, 2012 at 11:21:25AM -0300, Luiz Capitulino wrote:
> On Sun, 18 Mar 2012 19:29:09 +0100
> Alon Levy  wrote:
> 
> > Added:
> > 
> > QERR_EINTR
> > QERR_EACCES
> > QERR_EEXIST
> > QERR_OPEN_FILE_EMFILE
> > QERR_ENOSPC
> > QERR_EPERM
> > QERR_READ_ONLY
> > QERR_ENOTDIR
> > QERR_EFBIG
> > 
> > Signed-off-by: Alon Levy 
> > ---
> >  qerror.c |   36 
> >  qerror.h |   27 +++
> >  2 files changed, 63 insertions(+)
> > 
> > diff --git a/qerror.c b/qerror.c
> > index f55d435..4915939 100644
> > --- a/qerror.c
> > +++ b/qerror.c
> > @@ -213,6 +213,42 @@ static const QErrorStringTable qerror_table[] = {
> >  .desc  = "Could not open '%(filename)'",
> >  },
> >  {
> > +.error_fmt = QERR_EINTR,
> > +.desc  = "Interrupted open of '%(filename)'",
> > +},
> 
> There are two problems here. First, the QERR_INTR macro doesn't have the
> filename argument, so this will crash.
> 
> The second problem is that, I've talked to Anthony and EINTR should not
> be returned to clients, it should be handled intead. So, please handle it
> during write().

That would require either blocking or using async monitor... and in
general I guess it makes the signature of qemu_fopen_err be:

void qemu_fopen_err(const char *path, const char *mode, int block,
Error **errp)

Sounds ok?

> 
> > +{
> > +.error_fmt = QERR_EACCES,
> > +.desc  = "Cannot access file'",
> > +},
> 
> We already have QERR_PERMISSION_DENIED.
> 
> > +{
> > +.error_fmt = QERR_EEXIST,
> > +.desc  = "File already exists'",
> > +},
> 
> Can you use the description provided by man 3 errno? This is valid for all
> errors you're adding.
> 
> > +{
> > +.error_fmt = QERR_OPEN_FILE_EMFILE,
> > +.desc  = "Max open files when opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_ENOSPC,
> > +.desc  = "No space left opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_EPERM,
> > +.desc  = "Permission denied (EPERM) opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_READ_ONLY,
> > +.desc  = "Read only filesystem opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_ENOTDIR,
> > +.desc  = "Directory related error opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_EFBIG,
> > +.desc  = "File too big opening'",
> > +},
> > +{
> >  .error_fmt = QERR_PERMISSION_DENIED,
> >  .desc  = "Insufficient permission to perform this operation",
> >  },
> > diff --git a/qerror.h b/qerror.h
> > index e26c635..ddc04e8 100644
> > --- a/qerror.h
> > +++ b/qerror.h
> > @@ -181,6 +181,33 @@ QError *qobject_to_qerror(const QObject *obj);
> >  #define QERR_OPEN_FILE_FAILED \
> >  "{ 'class': 'OpenFileFailed', 'data': { 'filename': %s } }"
> >  
> > +#define QERR_OPEN_FILE_EMFILE \
> > +"{ 'class': 'OpenFileEMFILE', 'data': {} }"
> > +
> > +#define QERR_EINTR \
> > +"{ 'class': 'EINTR', 'data': {} }"
> > +
> > +#define QERR_EACCES \
> > +"{ 'class': 'EACCES', 'data': {} }"
> > +
> > +#define QERR_EEXIST \
> > +"{ 'class': 'EEXIST', 'data': {} }"
> 
> We use more descriptive names instead of using the errno name. Like 
> AlreadyExists.
> Please fix it for errors you adding.
> 
> > +
> > +#define QERR_ENOSPC \
> > +"{ 'class': 'ENOSPC', 'data': {} }"
> > +
> > +#define QERR_EPERM \
> > +"{ 'class': 'EPERM', 'data': {} }"
> > +
> > +#define QERR_READ_ONLY \
> > +"{ 'class': 'ReadOnly', 'data': {} }"
> > +
> > +#define QERR_ENOTDIR \
> > +"{ 'class': 'ENOTDIR', 'data': {} }"
> > +
> > +#define QERR_EFBIG \
> > +"{ 'class': 'EFBIG', 'data': {} }"
> > +
> >  #define QERR_PERMISSION_DENIED \
> >  "{ 'class': 'PermissionDenied', 'data': {} }"
> >  
> 
> 

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 03:10 PM, Jan Kiszka wrote:

On 2012-03-26 21:49, Anthony Liguori wrote:

On 03/26/2012 02:44 PM, Jan Kiszka wrote:
This would also mean that reference counting should be revisited
although with how dereferencing a parent affects the child.

It's not rocket science, but it's also something that needs to be done
carefully.


But all this is only a problem for these three here (PIT, RTC, HPET) as
their objects shall be embedded into the super-IO. If you only embed an
object pointer, it shouldn't be an issue anymore, no?


The reference counting stuff obviously needs to be looked at even in this case.


Also inheritance is not a problem here as we do not derive from the
three types in question. If there is a super/sub-class relation, those
need to share an internal header, of course.


Yes, but then you have two headers for every type.  Is that really a good thing?

I think I prefer to just mark fields as /*< private >*/ and scold people if they 
violate that convention.


Regards,

Anthony Liguori



Jan

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Jan Kiszka]

On 2012-03-26 21:49, Anthony Liguori wrote:
> On 03/26/2012 02:44 PM, Jan Kiszka wrote:
>> On 2012-03-26 21:39, Anthony Liguori wrote:
>>> On 03/26/2012 02:37 PM, Jan Kiszka wrote:
 On 2012-03-26 21:35, Anthony Liguori wrote:
>>> Since this is an easily refactorable thing to look at later, I think
>>> we should
>>> start with extracting the types.
>>
>> My worry is that those three refactorings set bad examples for
>> others.
>> So I'd like to avoid such back and forth if possible.
>
> I'm not really worried about it.  It's so easier to refactor this
> later.  Why rush it now?

 You rush changing the current layout, not me. :)
>>>
>>> No, I'm trying to do incremental changes without boiling the ocean in
>>> the process.
>>>
>>> I think we all are in violent agreement about where we want to end up
>>> (as opaque types as possible).  I don't want to hold back additional
>>> refactoring on doing this right (and it's not just a matter of
>>> malloc/free).
>>
>> Either I'm missing it in the code shuffling, or it's not part of this
>> series: Can you point out where more that a forward reference and
>> malloc/free is needed?
> 
> QOM is built around the concept that the type size is know (as is
> GObject). type_initialize() assumes that the pointer passed is an
> adequate size.
> 
> You would either need to move to a model where the memory was completely
> owned by QOM (which would mean folding type_new into type_initialize) or
> have a way to query instance size for a given type.
> 
> This would also mean that reference counting should be revisited
> although with how dereferencing a parent affects the child.
> 
> It's not rocket science, but it's also something that needs to be done
> carefully.

But all this is only a problem for these three here (PIT, RTC, HPET) as
their objects shall be embedded into the super-IO. If you only embed an
object pointer, it shouldn't be an issue anymore, no?

Also inheritance is not a problem here as we do not derive from the
three types in question. If there is a super/sub-class relation, those
need to share an internal header, of course.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v4] Man page: Add -global description

[Anthony Liguori]

On 03/21/2012 07:46 AM, Miroslav Rezanina wrote:

There's only TODO information in qemu man page for -global option. This is a 
basic description of this option with simple example.

Signed-off-by: Miroslav Rezanina


Applied.  Thanks.

Regards,

Anthony Liguori



v4:
  - break long line

v3:
  - add use case description
  - use prop instead of property

v2:
  - Use better value in example
Patch:
--
diff --git a/qemu-options.hx b/qemu-options.hx
index daefce3..662f571 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -288,13 +288,21 @@ TODO
  ETEXI

  DEF("global", HAS_ARG, QEMU_OPTION_global,
-"-global driver.property=value\n"
+"-global driver.prop=value\n"
  "set a global default for a driver property\n",
  QEMU_ARCH_ALL)
  STEXI
-@item -global
+@item -global @var{driver}.@var{prop}=@var{value}
  @findex -global
-TODO
+Set default value of @var{driver}'s property @var{prop} to @var{value}, e.g.:
+
+@example
+qemu -global ide-drive.physical_block_size=4096 -drive 
file=file,if=ide,index=0,media=disk
+@end example
+
+In particular, you can use this to set driver properties for devices which are
+created automatically by the machine model. To create a device which is not
+created automatically and set properties on it, use -@option{device}.
  ETEXI

  DEF("mtdblock", HAS_ARG, QEMU_OPTION_mtdblock,

Re: [Qemu-devel] [PATCH v3] qapi: add c_fun to escape function names

[Anthony Liguori]

On 03/20/2012 08:54 AM, Federico Simoncelli wrote:

Signed-off-by: Federico Simoncelli


Applied.  Thanks.

Regards,

Anthony Liguori


---
  scripts/qapi-commands.py |   14 +++---
  scripts/qapi-types.py|4 ++--
  scripts/qapi-visit.py|4 ++--
  scripts/qapi.py  |5 -
  4 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/scripts/qapi-commands.py b/scripts/qapi-commands.py
index 3aabf61..30a24d2 100644
--- a/scripts/qapi-commands.py
+++ b/scripts/qapi-commands.py
@@ -42,7 +42,7 @@ def generate_command_decl(name, args, ret_type):
  return mcgen('''
  %(ret_type)s qmp_%(name)s(%(args)sError **errp);
  ''',
- ret_type=c_type(ret_type), name=c_var(name), 
args=arglist).strip()
+ ret_type=c_type(ret_type), name=c_fun(name), 
args=arglist).strip()

  def gen_sync_call(name, args, ret_type, indent=0):
  ret = ""
@@ -59,7 +59,7 @@ def gen_sync_call(name, args, ret_type, indent=0):
  %(retval)sqmp_%(name)s(%(args)serrp);

  ''',
-name=c_var(name), args=arglist, retval=retval).rstrip()
+name=c_fun(name), args=arglist, retval=retval).rstrip()
  if ret_type:
  ret += "\n" + mcgen(
  if (!error_is_set(errp)) {
@@ -74,7 +74,7 @@ if (!error_is_set(errp)) {
  def gen_marshal_output_call(name, ret_type):
  if not ret_type:
  return ""
-return "qmp_marshal_output_%s(retval, ret, errp);" % c_var(name)
+return "qmp_marshal_output_%s(retval, ret, errp);" % c_fun(name)

  def gen_visitor_output_containers_decl(ret_type):
  ret = ""
@@ -198,16 +198,16 @@ static void qmp_marshal_output_%(c_name)s(%(c_ret_type)s 
ret_in, QObject **ret_o
  qapi_dealloc_visitor_cleanup(md);
  }
  ''',
-c_ret_type=c_type(ret_type), c_name=c_var(name),
+c_ret_type=c_type(ret_type), c_name=c_fun(name),
  visitor=type_visitor(ret_type))

  return ret

  def gen_marshal_input_decl(name, args, ret_type, middle_mode):
  if middle_mode:
-return 'int qmp_marshal_input_%s(Monitor *mon, const QDict *qdict, 
QObject **ret)' % c_var(name)
+return 'int qmp_marshal_input_%s(Monitor *mon, const QDict *qdict, 
QObject **ret)' % c_fun(name)
  else:
-return 'static void qmp_marshal_input_%s(QDict *args, QObject **ret, 
Error **errp)' % c_var(name)
+return 'static void qmp_marshal_input_%s(QDict *args, QObject **ret, 
Error **errp)' % c_fun(name)



@@ -298,7 +298,7 @@ def gen_registry(commands):
  registry += mcgen('''
  qmp_register_command("%(name)s", qmp_marshal_input_%(c_name)s);
  ''',
- name=cmd['command'], c_name=c_var(cmd['command']))
+ name=cmd['command'], c_name=c_fun(cmd['command']))
  pop_indent()
  ret = mcgen('''
  static void qmp_init_marshal(void)
diff --git a/scripts/qapi-types.py b/scripts/qapi-types.py
index 727fb77..4a734f5 100644
--- a/scripts/qapi-types.py
+++ b/scripts/qapi-types.py
@@ -100,7 +100,7 @@ typedef enum %(name)s
  %(abbrev)s_%(value)s = %(i)d,
  ''',
   abbrev=de_camel_case(name).upper(),
- value=c_var(value).upper(),
+ value=c_fun(value).upper(),
   i=i)
  i += 1

@@ -126,7 +126,7 @@ struct %(name)s
  %(c_type)s %(c_name)s;
  ''',
   c_type=c_type(typeinfo[key]),
- c_name=c_var(key))
+ c_name=c_fun(key))

  ret += mcgen('''
  };
diff --git a/scripts/qapi-visit.py b/scripts/qapi-visit.py
index 54117d4..78c947c 100644
--- a/scripts/qapi-visit.py
+++ b/scripts/qapi-visit.py
@@ -129,9 +129,9 @@ void visit_type_%(name)s(Visitor *m, %(name)s ** obj, const 
char *name, Error **
  break;
  ''',
  abbrev = de_camel_case(name).upper(),
-enum = de_camel_case(key).upper(),
+enum = c_fun(de_camel_case(key)).upper(),
  c_type=members[key],
-c_name=c_var(key))
+c_name=c_fun(key))

  ret += mcgen('''
  default:
diff --git a/scripts/qapi.py b/scripts/qapi.py
index 6e05469..e062336 100644
--- a/scripts/qapi.py
+++ b/scripts/qapi.py
@@ -131,7 +131,10 @@ def camel_case(name):
  return new_name

  def c_var(name):
-return '_'.join(name.split('-')).lstrip("*")
+return name.replace('-', '_').lstrip("*")
+
+def c_fun(name):
+return c_var(name).replace('.', '_')

  def c_list_type(name):
  return '%sList' % name

Re: [Qemu-devel] [PATCH v2] test: remove qemu-ga reference

[Anthony Liguori]

On 03/21/2012 10:10 AM, Michael Roth wrote:

This was added by mistake a while back.

Signed-off-by: Michael Roth


Applied.  Thanks.

Regards,

Anthony Liguori


---
  Makefile   |1 +
  tests/Makefile |2 +-
  2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 1bc3cb0..cab7c74 100644
--- a/Makefile
+++ b/Makefile
@@ -173,6 +173,7 @@ qemu-img-cmds.h: $(SRC_PATH)/qemu-img-cmds.hx
  $(qapi-obj-y): $(GENERATED_HEADERS)
  qapi-dir := $(BUILD_DIR)/qapi-generated
  qemu-ga$(EXESUF): LIBS = $(LIBS_QGA)
+qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir)

  gen-out-type = $(subst .,-,$(suffix $@))

diff --git a/tests/Makefile b/tests/Makefile
index c78ade1..354fdbb 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -17,7 +17,7 @@ test-coroutine: test-coroutine.o qemu-timer-common.o async.o 
$(coroutine-obj-y)

  test-qmp-input-visitor.o test-qmp-output-visitor.o \
  test-string-input-visitor.o test-string-output-visitor.o \
-   test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir)
+   test-qmp-commands.o: QEMU_CFLAGS += -I $(qapi-dir)

  $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\
  $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 02:44 PM, Jan Kiszka wrote:

On 2012-03-26 21:39, Anthony Liguori wrote:

On 03/26/2012 02:37 PM, Jan Kiszka wrote:

On 2012-03-26 21:35, Anthony Liguori wrote:

Since this is an easily refactorable thing to look at later, I think
we should
start with extracting the types.


My worry is that those three refactorings set bad examples for others.
So I'd like to avoid such back and forth if possible.


I'm not really worried about it.  It's so easier to refactor this
later.  Why rush it now?


You rush changing the current layout, not me. :)


No, I'm trying to do incremental changes without boiling the ocean in
the process.

I think we all are in violent agreement about where we want to end up
(as opaque types as possible).  I don't want to hold back additional
refactoring on doing this right (and it's not just a matter of
malloc/free).


Either I'm missing it in the code shuffling, or it's not part of this
series: Can you point out where more that a forward reference and
malloc/free is needed?


Inheritance is the other nasty case.

To inherit from a type, you need to have the type definition.  This is a pretty 
common problem with Object systems and the typical solution is PIMPL[1].


So maybe that's the right thing to do here, but that would have a significant 
affect on the code.  That's what I mean by rushing how to handle this.  There 
are multiple possible solutions and they need to be considered.


The problem is purely aesthetic too, so I don't see a rush to fix it.

[1] http://c2.com/cgi/wiki?PimplIdiom

Regards,

Anthony Liguori



Jan

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 02:44 PM, Jan Kiszka wrote:

On 2012-03-26 21:39, Anthony Liguori wrote:

On 03/26/2012 02:37 PM, Jan Kiszka wrote:

On 2012-03-26 21:35, Anthony Liguori wrote:

Since this is an easily refactorable thing to look at later, I think
we should
start with extracting the types.


My worry is that those three refactorings set bad examples for others.
So I'd like to avoid such back and forth if possible.


I'm not really worried about it.  It's so easier to refactor this
later.  Why rush it now?


You rush changing the current layout, not me. :)


No, I'm trying to do incremental changes without boiling the ocean in
the process.

I think we all are in violent agreement about where we want to end up
(as opaque types as possible).  I don't want to hold back additional
refactoring on doing this right (and it's not just a matter of
malloc/free).


Either I'm missing it in the code shuffling, or it's not part of this
series: Can you point out where more that a forward reference and
malloc/free is needed?


QOM is built around the concept that the type size is know (as is GObject). 
type_initialize() assumes that the pointer passed is an adequate size.


You would either need to move to a model where the memory was completely owned 
by QOM (which would mean folding type_new into type_initialize) or have a way to 
query instance size for a given type.


This would also mean that reference counting should be revisited although with 
how dereferencing a parent affects the child.


It's not rocket science, but it's also something that needs to be done 
carefully.

Regards,

Anthony Liguori



Jan

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Jan Kiszka]

On 2012-03-26 21:39, Anthony Liguori wrote:
> On 03/26/2012 02:37 PM, Jan Kiszka wrote:
>> On 2012-03-26 21:35, Anthony Liguori wrote:
> Since this is an easily refactorable thing to look at later, I think
> we should
> start with extracting the types.

 My worry is that those three refactorings set bad examples for others.
 So I'd like to avoid such back and forth if possible.
>>>
>>> I'm not really worried about it.  It's so easier to refactor this
>>> later.  Why rush it now?
>>
>> You rush changing the current layout, not me. :)
> 
> No, I'm trying to do incremental changes without boiling the ocean in
> the process.
> 
> I think we all are in violent agreement about where we want to end up
> (as opaque types as possible).  I don't want to hold back additional
> refactoring on doing this right (and it's not just a matter of
> malloc/free).

Either I'm missing it in the code shuffling, or it's not part of this
series: Can you point out where more that a forward reference and
malloc/free is needed?

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 1/1] If user doesn't specify a uuid, generate a random one

[Anthony Liguori]

On 03/26/2012 10:13 AM, Serge E. Hallyn wrote:

Currently, if the user doesn't pass a uuid, the system uuid is set to
all zeros.  This patch generates a random one instead.

Is there a reason to prefer all zeros?  If not, can a patch like this
one be applied?

Signed-off-by: Serge Hallyn


The other hypervisors don't have a concept of a transient guest like QEMU does.

There is no state preserved between invocations of QEMU.

Setting a random UUID doesn't seem like the right answer to me as it would 
potentially break Windows VMs.


Perhaps if the DMI UUID isn't set, you could look at the root filesystem's UUID?

Not all platforms have a notion of platform UUID so as Ubuntu supports more 
architectures, this problem would have to be dealt with eventually.


Regards,

Anthony Liguori


---
  vl.c |   11 +++
  1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index 112b0e0..2b53b62 100644
--- a/vl.c
+++ b/vl.c
@@ -247,7 +247,9 @@ int nb_numa_nodes;
  uint64_t node_mem[MAX_NODES];
  uint64_t node_cpumask[MAX_NODES];

+#include
  uint8_t qemu_uuid[16];
+bool uuid_set = false;

  static QEMUBootSetHandler *boot_set_handler;
  static void *boot_set_opaque;
@@ -3030,6 +3032,7 @@ int main(int argc, char **argv, char **envp)
  " Wrong format.\n");
  exit(1);
  }
+uuid_set = true;
  break;
case QEMU_OPTION_option_rom:
if (nb_option_roms>= MAX_OPTION_ROMS) {
@@ -3200,6 +3203,14 @@ int main(int argc, char **argv, char **envp)
  exit(0);
  }

+if (!uuid_set) {
+uuid_t uuid;
+uuid_generate(uuid);
+for (i = 0; i<  16; i++) {
+qemu_uuid[i] = uuid[i];
+}
+}
+
  /* Open the logfile at this point, if necessary. We can't open the logfile
   * when encountering either of the logging options (-d or -D) because the
   * other one may be encountered later on the command line, changing the

Re: [Qemu-devel] [RFC PATCH 06/17] block: use bdrv_{co, aio}_discard for write_zeroes operations

[Richard Laager]

On Sat, 2012-03-24 at 16:30 +0100, Christoph Hellwig wrote:
> On Wed, Mar 14, 2012 at 01:14:18PM +0100, Paolo Bonzini wrote:
> > 
> > Note that the discard granularity is only a hint, so it's really more a
> > maximum suggested value than a granularity.  Outside of a cluster
> > boundary the format would still have to write zeros manually.
> > 
> > Also, Linux for example will only round the number of sectors down to
> > the granularity, not the start sector.
> 
> Which really is more of a bug than a feature.  The current discard
> implementation in Linux is still very poor.

The disk protocols do not require the granularity to be respected. It is
*only a hint*. Therefore, QEMU has to handle non-aligned discards. It
doesn't really matter what we wish was the case; this is the reality.

-- 
Richard


signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] [RFC PATCH 06/17] block: use bdrv_{co, aio}_discard for write_zeroes operations

[Richard Laager]

On Sat, 2012-03-24 at 16:27 +0100, Christoph Hellwig wrote:
> > has_discard = !fallocate(s->fd, FALLOC_FL_PUNCH_HOLE | 
> > FALLOC_FL_KEEP_SIZE,
> 
> There is no point in using FALLOC_FL_KEEP_SIZE together with
> FALLOC_FL_PUNCH_HOLE.

It's *required*. From the man page [0], "The FALLOC_FL_PUNCH_HOLE flag
must be ORed with FALLOC_FL_KEEP_SIZE in mode;"

[0] http://man7.org/linux/man-pages/man2/fallocate.2.html

-- 
Richard


signature.asc
Description: This is a digitally signed message part

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 02:37 PM, Jan Kiszka wrote:

On 2012-03-26 21:35, Anthony Liguori wrote:

Since this is an easily refactorable thing to look at later, I think
we should
start with extracting the types.


My worry is that those three refactorings set bad examples for others.
So I'd like to avoid such back and forth if possible.


I'm not really worried about it.  It's so easier to refactor this
later.  Why rush it now?


You rush changing the current layout, not me. :)


No, I'm trying to do incremental changes without boiling the ocean in the 
process.

I think we all are in violent agreement about where we want to end up (as opaque 
types as possible).  I don't want to hold back additional refactoring on doing 
this right (and it's not just a matter of malloc/free).


Regards,

Anthony Liguori


Jan

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Jan Kiszka]

On 2012-03-26 21:35, Anthony Liguori wrote:
> On 03/26/2012 02:30 PM, Jan Kiszka wrote:
>> On 2012-03-26 19:33, Anthony Liguori wrote:
>>> On 03/26/2012 07:20 AM, Jan Kiszka wrote:
 On 2012-03-26 04:06, Wanpeng Li wrote:
> From: Anthony Liguori
>
>
> This series aggressively refactors the PC machine initialization to
> be more
> modelled and less ad-hoc.  The highlights of this series are:
>
>1) Things like -m and -bios-name are now device model properties
>
>2) The i440fx and piix3 are now modelled in a thorough fashion
>
>3) Most of the chipset features of the piix3 are modelled
> through composition
>
>4) i440fx_init is trivialized to creating devices and setting
> properties
>
>5) convert MemoryRegion to QOM
>
>6) convert PCI host bridge to QOM
>
> The point (4) is the most important one.  As we refactor in this
> fashion,
> we should quickly get to the point where machine->init disappears
> completely in
> favor of just creating a handful of devices.
>
> The two stage initialization of QOM is important here. 
> instance_init() is when
> composed devices are created which means that after you've created
> a device, all
> of its children are visible in the device model.  This lets you set
> properties
> of the parent and its children.
>
> realize() (which is still called DeviceState::init today) will be
> called right
> before the guest starts up for the first time.

 While I see the value of the overall direction, I still disagree on
 making internal data structures of HPET, RTC and 8254 publicly
 available. That's a wrong step back. I'm sure there are smarter
 solutions, alse as there were some proposals back then in the original
 thread.
>>>
>>> I'm not fully decided myself.  A couple things are clear to me though:
>>>
>>> 1) We must expose type proper types in header files.  We need there
>>> to be a
>>> globally accessible RTCState type and functions that operate on it.
>>
>> I'm not sure what "proper type" means in this context, but I'm quite
>> sure that there should be no need for poking into the internal of the
>> class outside of mc146818rtc.c.
> 
> It needs to be at least a forward reference.  So we can avoid stuff like:
> 
> int apic_accept_pic_intr(DeviceState *s);
> 
> It should be:
> 
> int apic_accept_pic_intr(APICState *s);
> 
> So we can make use of the lovely type checking provided by the compiler
> to us.

I do not disagree. A pointer is harmless.

> 
>> We even abstracted the specifics of the
>> RTC away when it is embedded into a super-IO and interacts with an HPET.
>> If QOM requires such poking, then that requirement should be reassessed.
> 
> There are a couple of ways to make types private while still having
> forward declarations.  None of them are straight forward.  That's why I
> suggest we save this for another day.
> 
>>>
>>> 2) We can simplify memory management by knowing the size of the type
>>> in the
>>> header files too.
>>
>> Is this more than a malloc-free pair?
>>
>>>
>>> Since this is an easily refactorable thing to look at later, I think
>>> we should
>>> start with extracting the types.
>>
>> My worry is that those three refactorings set bad examples for others.
>> So I'd like to avoid such back and forth if possible.
> 
> I'm not really worried about it.  It's so easier to refactor this
> later.  Why rush it now?

You rush changing the current layout, not me. :)

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 02:30 PM, Jan Kiszka wrote:

On 2012-03-26 19:33, Anthony Liguori wrote:

On 03/26/2012 07:20 AM, Jan Kiszka wrote:

On 2012-03-26 04:06, Wanpeng Li wrote:

From: Anthony Liguori


This series aggressively refactors the PC machine initialization to be more
modelled and less ad-hoc.  The highlights of this series are:

   1) Things like -m and -bios-name are now device model properties

   2) The i440fx and piix3 are now modelled in a thorough fashion

   3) Most of the chipset features of the piix3 are modelled through composition

   4) i440fx_init is trivialized to creating devices and setting properties

   5) convert MemoryRegion to QOM

   6) convert PCI host bridge to QOM

The point (4) is the most important one.  As we refactor in this fashion,
we should quickly get to the point where machine->init disappears completely in
favor of just creating a handful of devices.

The two stage initialization of QOM is important here.  instance_init() is when
composed devices are created which means that after you've created a device, all
of its children are visible in the device model.  This lets you set properties
of the parent and its children.

realize() (which is still called DeviceState::init today) will be called right
before the guest starts up for the first time.


While I see the value of the overall direction, I still disagree on
making internal data structures of HPET, RTC and 8254 publicly
available. That's a wrong step back. I'm sure there are smarter
solutions, alse as there were some proposals back then in the original
thread.


I'm not fully decided myself.  A couple things are clear to me though:

1) We must expose type proper types in header files.  We need there to be a
globally accessible RTCState type and functions that operate on it.


I'm not sure what "proper type" means in this context, but I'm quite
sure that there should be no need for poking into the internal of the
class outside of mc146818rtc.c.


It needs to be at least a forward reference.  So we can avoid stuff like:

int apic_accept_pic_intr(DeviceState *s);

It should be:

int apic_accept_pic_intr(APICState *s);

So we can make use of the lovely type checking provided by the compiler to us.


We even abstracted the specifics of the
RTC away when it is embedded into a super-IO and interacts with an HPET.
If QOM requires such poking, then that requirement should be reassessed.


There are a couple of ways to make types private while still having forward 
declarations.  None of them are straight forward.  That's why I suggest we save 
this for another day.




2) We can simplify memory management by knowing the size of the type in the
header files too.


Is this more than a malloc-free pair?



Since this is an easily refactorable thing to look at later, I think we should
start with extracting the types.


My worry is that those three refactorings set bad examples for others.
So I'd like to avoid such back and forth if possible.


I'm not really worried about it.  It's so easier to refactor this later.  Why 
rush it now?


Regards,

Anthony Liguori


Jan

Re: [Qemu-devel] [PATCH 1/1] If user doesn't specify a uuid, generate a random one

[Serge E. Hallyn]

Quoting Brian Jackson (i...@theiggy.com):
> On Mon, 26 Mar 2012 10:13:40 -0500, Serge E. Hallyn
>  wrote:
> 
> >Currently, if the user doesn't pass a uuid, the system uuid is set to
> >all zeros.  This patch generates a random one instead.
> >
> >Is there a reason to prefer all zeros?  If not, can a patch like this
> >one be applied?
> >
> >Signed-off-by: Serge Hallyn 
> >---
> > vl.c |   11 +++
> > 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> >diff --git a/vl.c b/vl.c
> >index 112b0e0..2b53b62 100644
> >--- a/vl.c
> >+++ b/vl.c
> >@@ -247,7 +247,9 @@ int nb_numa_nodes;
> > uint64_t node_mem[MAX_NODES];
> > uint64_t node_cpumask[MAX_NODES];
> >+#include 
> 
> 
> 
> This adds a hard dep on libuuid (prior to this it's optional and
> only impacts the vdi block driver).

Yup.  If that's a problem we can re-implement our own, if the
change in default behavior is acceptable.

> > uint8_t qemu_uuid[16];
> >+bool uuid_set = false;
> >static QEMUBootSetHandler *boot_set_handler;
> > static void *boot_set_opaque;
> >@@ -3030,6 +3032,7 @@ int main(int argc, char **argv, char **envp)
> > " Wrong format.\n");
> > exit(1);
> > }
> >+uuid_set = true;
> > break;
> > case QEMU_OPTION_option_rom:
> > if (nb_option_roms >= MAX_OPTION_ROMS) {
> >@@ -3200,6 +3203,14 @@ int main(int argc, char **argv, char **envp)
> > exit(0);
> > }
> >+if (!uuid_set) {
> >+uuid_t uuid;
> >+uuid_generate(uuid);
> >+for (i = 0; i < 16; i++) {
> >+qemu_uuid[i] = uuid[i];
> >+}
> >+}
> >+
> > /* Open the logfile at this point, if necessary. We can't
> >open the logfile
> >  * when encountering either of the logging options (-d or -D)
> >because the
> >  * other one may be encountered later on the command line,
> >changing the

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Jan Kiszka]

On 2012-03-26 19:33, Anthony Liguori wrote:
> On 03/26/2012 07:20 AM, Jan Kiszka wrote:
>> On 2012-03-26 04:06, Wanpeng Li wrote:
>>> From: Anthony Liguori
>>>
>>>
>>> This series aggressively refactors the PC machine initialization to be more
>>> modelled and less ad-hoc.  The highlights of this series are:
>>>
>>>   1) Things like -m and -bios-name are now device model properties
>>>
>>>   2) The i440fx and piix3 are now modelled in a thorough fashion
>>>
>>>   3) Most of the chipset features of the piix3 are modelled through 
>>> composition
>>>
>>>   4) i440fx_init is trivialized to creating devices and setting properties
>>>
>>>   5) convert MemoryRegion to QOM
>>>
>>>   6) convert PCI host bridge to QOM
>>>
>>> The point (4) is the most important one.  As we refactor in this fashion,
>>> we should quickly get to the point where machine->init disappears 
>>> completely in
>>> favor of just creating a handful of devices.
>>>
>>> The two stage initialization of QOM is important here.  instance_init() is 
>>> when
>>> composed devices are created which means that after you've created a 
>>> device, all
>>> of its children are visible in the device model.  This lets you set 
>>> properties
>>> of the parent and its children.
>>>
>>> realize() (which is still called DeviceState::init today) will be called 
>>> right
>>> before the guest starts up for the first time.
>>
>> While I see the value of the overall direction, I still disagree on
>> making internal data structures of HPET, RTC and 8254 publicly
>> available. That's a wrong step back. I'm sure there are smarter
>> solutions, alse as there were some proposals back then in the original
>> thread.
> 
> I'm not fully decided myself.  A couple things are clear to me though:
> 
> 1) We must expose type proper types in header files.  We need there to be a 
> globally accessible RTCState type and functions that operate on it.

I'm not sure what "proper type" means in this context, but I'm quite
sure that there should be no need for poking into the internal of the
class outside of mc146818rtc.c. We even abstracted the specifics of the
RTC away when it is embedded into a super-IO and interacts with an HPET.
If QOM requires such poking, then that requirement should be reassessed.

> 
> 2) We can simplify memory management by knowing the size of the type in the 
> header files too.

Is this more than a malloc-free pair?

> 
> Since this is an easily refactorable thing to look at later, I think we 
> should 
> start with extracting the types.

My worry is that those three refactorings set bad examples for others.
So I'd like to avoid such back and forth if possible.

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] [PATCH] fix multiboot loading if load_end_addr == 0

[Scott Moser]

The previous multiboot load code did not treat the case where
load_end_addr was 0 specially.  The multiboot specification says the
following:
 * load_end_addr
   Contains the physical address of the end of the data segment.
   (load_end_addr - load_addr) specifies how much data to load. This
   implies that the text and data segments must be consecutive in the
   OS image; this is true for existing a.out executable formats. If
   this field is zero, the boot loader assumes that the text and data
   segments occupy the whole OS image file.

Signed-off-by: Scott Moser 

diff --git a/hw/multiboot.c b/hw/multiboot.c
index b4484a3..b1e04c5 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -202,10 +202,16 @@ int load_multiboot(void *fw_cfg,
 uint32_t mh_bss_end_addr = ldl_p(header+i+24);
 mh_load_addr = ldl_p(header+i+16);
 uint32_t mb_kernel_text_offset = i - (mh_header_addr - mh_load_addr);
-uint32_t mb_load_size = mh_load_end_addr - mh_load_addr;
-
+uint32_t mb_load_size = 0;
 mh_entry_addr = ldl_p(header+i+28);
-mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+
+if (mh_load_end_addr) {
+mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+mb_load_size = mh_load_end_addr - mh_load_addr;
+} else {
+mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+mb_load_size = mb_kernel_size;
+}

 /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
 uint32_t mh_mode_type = ldl_p(header+i+32);

Re: [Qemu-devel] [Patch 0/2] Fix QEMU configure / make with Turkish (and maybe other) locale

[Eric Blake]

On 03/25/2012 01:48 PM, Stefan Weil wrote:
> As you see in my patch, I had to override three environment
> variables to (hopefully) handle all cases which lead to wrong
> results,

Technically, you only have to modify LC_ALL.  Modifications to LANG and
LC_CTYPE are pointless once LC_ALL is set, at least on any
standards-compliant i18n platform.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v3 1/2] Force timedrift=none on previous machines

[Anthony Liguori]

On 03/21/2012 11:06 AM, Crístian Viana wrote:

The current value for the -rtc timedrift option is none. This patch
makes sure that the old machines configuration will work the same way
even after that option changes its default value.

Signed-off-by: Crístian Viana


Something's off here:

Using machine: pc-0.14
/home/anthony/build/qemu/x86_64-softmmu/qemu-system-x86_64 -kernel 
bin/vmlinuz-3.0 -initrd .tmp-22118/initramfs-22118.img.gz -append console=ttyS0 
seed=64521 -nographic -enable-kvm -hda .tmp-22118/disk-22118.img -M pc-0.14 
-drive file=.tmp-22118/disk-22118.img,if=virtio,snapshot=on -device 
virtio-balloon-pci -device virtio-serial -net nic,model=virtio -net user 
-pidfile .tmp-22118/pidfile-22118.pid -qmp 
unix:.tmp-22118/qmpsock-22118.sock,server,nowait

qemu-system-x86_64: Invalid parameter 'lost_tick_policy'

Regards,

Anthony Liguori


---
  hw/pc_piix.c |   39 +++
  1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index 3f99f9a..08255b5 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -386,6 +386,10 @@ static QEMUMachine pc_machine_v1_0 = {
  .driver   = "isa-fdc",
  .property = "check_media_rate",
  .value= "off",
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  },
@@ -405,6 +409,10 @@ static QEMUMachine pc_machine_v0_15 = {
  .driver   = "isa-fdc",
  .property = "check_media_rate",
  .value= "off",
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  },
@@ -449,6 +457,10 @@ static QEMUMachine pc_machine_v0_14 = {
  .driver   = "pc-sysfw",
  .property = "rom_only",
  .value= stringify(1),
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  },
@@ -505,6 +517,10 @@ static QEMUMachine pc_machine_v0_13 = {
  .driver   = "pc-sysfw",
  .property = "rom_only",
  .value= stringify(1),
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  },
@@ -565,6 +581,10 @@ static QEMUMachine pc_machine_v0_12 = {
  .driver   = "pc-sysfw",
  .property = "rom_only",
  .value= stringify(1),
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  }
@@ -633,6 +653,10 @@ static QEMUMachine pc_machine_v0_11 = {
  .driver   = "pc-sysfw",
  .property = "rom_only",
  .value= stringify(1),
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  }
@@ -713,6 +737,10 @@ static QEMUMachine pc_machine_v0_10 = {
  .driver   = "pc-sysfw",
  .property = "rom_only",
  .value= stringify(1),
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  },
@@ -728,6 +756,10 @@ static QEMUMachine isapc_machine = {
  .driver   = "pc-sysfw",
  .property = "rom_only",
  .value= stringify(1),
+}, {
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
  },
  { /* end of list */ }
  },
@@ -740,6 +772,13 @@ static QEMUMachine xenfv_machine = {
  .init = pc_xen_hvm_init,
  .max_cpus = HVM_MAX_VCPUS,
  .default_machine_opts = "accel=xen",
+.compat_props = (GlobalProperty[]) {
+{
+.driver   = "mc146818rtc",
+.property = "lost_tick_policy",
+.value= "none",
+},
+{ /* end of list */ }
  };
  #endif

Re: [Qemu-devel] [PATCH] fix multiboot loading if load_end_addr == 0 (fwd)

[Anthony Liguori]

On 03/18/2012 12:45 PM, Scott Moser wrote:

Re-sending to qemu-devel.  I'd originally sent this to kvm mailing list.


Can you submit as a proper patch with a Signed-off-by?

Regards,

Anthony Liguori



-- Forwarded message --
Date: Sat, 17 Mar 2012 00:08:06
From: Scott Moser
To: k...@vger.kernel.org
Subject: [PATCH] fix multiboot loading if load_end_addr == 0

The previous code did not treat the case where load_end_addr was 0
specially.  The multiboot specification says the following:
  * load_end_addr
Contains the physical address of the end of the data segment.
(load_end_addr - load_addr) specifies how much data to load. This
implies that the text and data segments must be consecutive in the
OS image; this is true for existing a.out executable formats. If
this field is zero, the boot loader assumes that the text and data
segments occupy the whole OS image file.

This was raised initially as launchpad bug
https://bugs.launchpad.net/qemu/+bug/957622

diff --git a/hw/multiboot.c b/hw/multiboot.c
index b4484a3..b1e04c5 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -202,10 +202,16 @@ int load_multiboot(void *fw_cfg,
  uint32_t mh_bss_end_addr = ldl_p(header+i+24);
  mh_load_addr = ldl_p(header+i+16);
  uint32_t mb_kernel_text_offset = i - (mh_header_addr - mh_load_addr);
-uint32_t mb_load_size = mh_load_end_addr - mh_load_addr;
-
+uint32_t mb_load_size = 0;
  mh_entry_addr = ldl_p(header+i+28);
-mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+
+if (mh_load_end_addr) {
+mb_kernel_size = mh_bss_end_addr - mh_load_addr;
+mb_load_size = mh_load_end_addr - mh_load_addr;
+} else {
+mb_kernel_size = kernel_file_size - mb_kernel_text_offset;
+mb_load_size = mb_kernel_size;
+}

  /* Valid if mh_flags sets MULTIBOOT_HEADER_HAS_VBE.
  uint32_t mh_mode_type = ldl_p(header+i+32);

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Eduardo Habkost]

On Sun, Mar 25, 2012 at 01:11:04PM -0500, Anthony Liguori wrote:
> On 03/25/2012 10:40 AM, Avi Kivity wrote:
> >On 03/25/2012 05:26 PM, Anthony Liguori wrote:
> >>>Put the emphasis around *configuration*.
> >>
> >>
> >>So how about:
> >>
> >>1) Load ['@SYSCONFDIR@/qemu/qemu.cfg',
> >>'@SYSCONFDIR@/qemu/target-@ARCH@.cfg',
> >>  '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg']
> >>
> >>2) system-@ARCH@.cfg will contain:
> >>
> >>[system]
> >>readconfig=@DATADIR@/target-@a...@-cpus.cfg
> >>readconfig=@DATADIR@/target-@a...@-machine.cfg
> >>
> >>3) -nodefconfig will not load any configuration files from DATADIR or
> >>SYSCONFDIR.  -no-user-config will not load any configuration files
> >>from SYSCONFDIR.
> >
> >What, more options?
> 
> Okay, we can just drop -no-user-config and then if a management tool
> wants to do the equivalent, they can do -nodefconfig + '-readconfig
> @DATADIR@/system-@ARCH@.cfg'.  I'm equally happy with that :-)

I actually prefer -no-user-config, because it gives Qemu freedom to add
more stuff to the outside if needed, but without requiring more
-readconfig options (or -read-something-else options, if we create them)
to be added in the future.

For example, if one day we move machine-types to external files, libvirt
wouldn't have to be changed to add Yet Another -readconfig argument to
make the machine-types available for use. If Qemu moves some device
implementation to external modules, they won't suddenly go away for
users of -no-user-config. The list of possible changes that would break
compatibility for -nodefconfig users but no -no-user-config users is
large.

[...]
> >I don't think -nodefconfig (as defined) is usable, since there is no way
> >for the user to tell what it means short of reading those files.
> 
> *if the user doesn't know specifics about this QEMU version.
> 
> You make the assumption that all users are going to throw arbitrary
> options at arbitrary QEMU versions.  That's certainly an important
> use-case but it's not the only one.

Well, you make the assumption that somebody will every want to use
-nodefconfig the way you want to define it. I don't think nobody will
ever use it if we defined it that way, but that's OK with me. I will
simply ignore the existence of -nodefconfig from now on.  :-)

[...]
> >>>"#define westmere blah" is not configuration, otherwise the meaning of
> >>>configuration will drift over time.
> >>>
> >>>-cpu blah is, of course.
> >>
> >>It's the same mechanism, but the above would create two classes of
> >>default configuration files and then it becomes a question of how
> >>they're used.
> >
> >Confused.
> 
> We don't have a formal concept of -read-definition-config and
> -read-configuration-config
> 
> There's no easy or obvious way to create such a concept either nor do
> I think the distinction is meaningful to users.

The distinction _is_ meaningful to libvirt, that's what started this
thread.

[...]
> >The file defines westmere as an alias for a grab bag of options.
> >Whether it's loaded or not is immaterial, unless someone uses one
> >of the
> >names within.
> 
> But you would agree, a management tool should be able to control
> whether class factories get loaded, right?
> >>>
> >>>No, why?  But perhaps I don't entirely get what you mean by "class
> >>>factories".
> >>>
> >>>Aren't they just implementations of
> >>>
> >>> virtual Device *new_instance(...) = 0?
> >>>
> >>>if so, why not load them?
> >>
> >>No, a class factory creates a new type of class.  -cpudef will
> >>ultimately call type_register() to create a new QOM visible type.
> >> From a management tools perspective, the type is no different than a
> >>built-in type.
> >
> >Exactly.  The types are no different, so there's no reason to
> >discriminate against types that happen to live in qemu-provided data
> >files vs. qemu code.  They aren't instantiated, so we lose nothing by
> >creating the factories (just so long as the factories aren't
> >mass-producing objects).
> 
> At some point, I'd like to have type modules that are shared objects.
> I'd like QEMU to start with almost no builtin types and allow the
> user to configure which modules get loaded.
> 
> In the long term, I'd like QEMU to be a small, robust core with the
> vast majority of code relegated to modules with the user ultimately
> in control of module loading.
> 
> Yes, I'd want some module autoloading system but there should always
> be a way to launch QEMU without loading any modules and then load a
> very specific set of modules (as defined by the user).

And libvirt needs a way to keep module autoloading enabled while
disabling the loading of files from /etc.

> 
> You can imagine this being useful for something like Common Criteria 
> certifications.

No problem, except that this is not the use-case libvirt has. If you
want -nodefconfig to mean that, that's OK. But we need an option to just
disable the loading of files from /etc, but keeping loading the "de

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Anthony Liguori]

On 03/26/2012 11:14 AM, Eduardo Habkost wrote:

On Mon, Mar 26, 2012 at 02:03:21PM +0200, Gleb Natapov wrote:

On Mon, Mar 26, 2012 at 01:59:05PM +0200, Avi Kivity wrote:

On 03/26/2012 01:24 PM, Jiri Denemark wrote:

...

The command line becomes unstable if you use -nodefconfig.


-no-user-config solves this but I fully expect libvirt would continue to use
-nodefconfig.


Libvirt uses -nodefaults -nodefconfig because it wants to fully control how
the virtual machine will look like (mainly in terms of devices). In other
words, we don't want any devices to just magically appear without libvirt
knowing about them. -nodefaults gets rid of default devices that are built
directly in qemu. Since users can set any devices or command line options
(such as enable-kvm) into qemu configuration files in @SYSCONFDIR@, we need to
avoid reading those files as well. Hence we use -nodefconfig. However, we
would still like qemu to read CPU definitions, machine types, etc. once they
become externally loaded configuration (or however we decide to call it). That
said, when CPU definitions are moved into @DATADIR@, and -no-user-config is
introduced, I don't see any reason for libvirt to keep using -nodefconfig.


ACK.



I actually like
-no-user-config
more than
-nodefconfig -readconfig @DATADIR@/...
since it would avoid additional magic to detect what files libvirt should
explicitly pass to -readconfig but basically any approach that would allow us
to do read files only from @DATADIR@ is much better than what we have with
-nodefconfig now.


That's how I see it as well.


+1

except that instead of -no-user-config we can do what most other
programs do. If config file is specified during invocation default one
is not used. After implementing -no-user-config (or similar) we can drop
-nodefconfig entirely since its only user will be gone it its semantics
is not clear.


Awesome. It looks like we have a solution now? Anthony, do you agree
with that? Daniel, it looks good for you?


We cannot and should not drop -nodefconfig.  But yes, I agree that we should 
introduce -no-user-config and use the semantics I specified earlier in the thread.


Regards,

Anthony Liguori

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Anthony Liguori]

On 03/26/2012 04:08 AM, Avi Kivity wrote:

If I see something like -nodefconfig, I assume it will create a bare
bones guest that will not depend on any qemu defaults and will be stable
across releases.


That's not even close to what -nodefconfig is.  That's pretty much
what -nodefaults is but -nodefaults has also had a fluid definition
historically.


Okay.  Let's just make sure to document -nodefconfig as version specific
and -nodefaults as the stable way to create a bare bones guest (and
define exactly what that means).


Agreed.  But I do want to point out, that -nodefaults has not been stable and 
since it doesn't universally create a bare bones guest, it's not clear that it 
will be.


I think what we want to move toward is a -no-machine option which allows a user 
to explicitly build a machine from scratch.  That is:


qemu -no-machine -device i440fx,id=host -device isa-serial,chr=chr0 ...

Regards,

Anthony Liguori

Re: [Qemu-devel] [Bug 588731] Re: PXE boot not working

[Michael Tokarev]

On 26.03.2012 19:18, Michal Suchanek wrote:
> There seems to be an issue with kvm virtual network interface being
> connected to a in-kernel bridge implementation.
> 
> When you configure networking that way the bridge port comes up when the
> kvm instance is started.
> 
> As the time from the kvm start to entering the netboot rom is minimal
> and the timeout before the bridge starts forwarding on new ports is long
> this may cause the machine never getting an address.
> 
> If you are using a bridge try setting the forwarding delay to a small
> value like:
> 
> iface vmbridge inet static
>  bridge_ports  undocumented>
>  address 10.10.10.1
>  netmask 255.255.255.0
>  post-up brctl setfd vmbridge 3

Use
  bridge_fd 0

here instead of these post-up things.

/mjt

Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Anthony Liguori]

On 03/25/2012 01:09 PM, Avi Kivity wrote:

Suppose we define the southbridge via a configuration file.  Does that
mean we don't load it any more?


Yes.  If I want the leanest and meanest version of QEMU that will
start in the smallest number of milliseconds, then being able to tell
QEMU not to load configuration files and create a very specific
machine is a Good Thing.  Why exclude users from being able to do this?


So is this the point?  Reducing startup time?


Yes, that's one reason.  But maybe a user wants to have a whole
different set of machine types and doesn't care to have the ones we
provide.  Why prevent a user from doing this?


How are we preventing a user from doing it?  In what way is -nodefconfig
helping it?


Let me explain it in a different way, perhaps.

We launch smbd in QEMU in order to do file sharing over slirp.  One of the 
historic problems we've had is that we don't assume root privileges, yet want to 
be able to run smbd without using any of the system configuration files.


You can do this by specify -s with the config file, and then in the config file 
you can overload the various default paths (like private dir, lock dir, etc.). 
In some cases, earlier versions of smbd didn't allow you to change private dir.


You should be able to tell a well behaved tool not to read any 
configuration/data files and explicitly tell it where/how to read them.  We 
cannot exhaustively anticipate every future use case of QEMU.


But beyond the justification for -nodefconfig, the fact is that it exists today, 
and has a specific semantic.  If we want to have a different semantic, we should 
introduce a new option (-no-user-config).


Regards,

Anthony Liguori


Maybe they have a management tool that attempts to totally hide QEMU
from the end user and exposes a different set of machine types.  It's
certainly more convenient for something like the Android emulator to
only have to deal with QEMU knowing about the 4 types of machines that
it specifically supports.


If it supports four types, it should always pass one of them to qemu.
The only thing -nodefconfig adds is breakage when qemu moves something
that one of those four machines relies on to a config file.

Re: [Qemu-devel] [PATCH v3 1/5] qerror: add error codes for fopen failure

[Alon Levy]

On Fri, Mar 23, 2012 at 11:21:25AM -0300, Luiz Capitulino wrote:
> On Sun, 18 Mar 2012 19:29:09 +0100
> Alon Levy  wrote:
> 
> > Added:
> > 
> > QERR_EINTR
> > QERR_EACCES
> > QERR_EEXIST
> > QERR_OPEN_FILE_EMFILE
> > QERR_ENOSPC
> > QERR_EPERM
> > QERR_READ_ONLY
> > QERR_ENOTDIR
> > QERR_EFBIG
> > 
> > Signed-off-by: Alon Levy 
> > ---
> >  qerror.c |   36 
> >  qerror.h |   27 +++
> >  2 files changed, 63 insertions(+)
> > 
> > diff --git a/qerror.c b/qerror.c
> > index f55d435..4915939 100644
> > --- a/qerror.c
> > +++ b/qerror.c
> > @@ -213,6 +213,42 @@ static const QErrorStringTable qerror_table[] = {
> >  .desc  = "Could not open '%(filename)'",
> >  },
> >  {
> > +.error_fmt = QERR_EINTR,
> > +.desc  = "Interrupted open of '%(filename)'",
> > +},
> 
> There are two problems here. First, the QERR_INTR macro doesn't have the
> filename argument, so this will crash.
> 
> The second problem is that, I've talked to Anthony and EINTR should not
> be returned to clients, it should be handled intead. So, please handle it
> during write().

>From a brief due dilligence (git grep -A10 fopen | grep EINTR | wc -l ==
0) I gather that no one ever checks EINTR after fopen, so I'm going to
avoid the complexity of possibly blocking in qemu_fopen_err and just
note in the qapi-schema wherever an qemu_fopen_err derived error might
be returned that the generic OpenFileFailed could indicate an EINTR.

I think it will at least be easier to fix it later in a single location,
that is at qemu_fopen_err, in a later patch.

> 
> > +{
> > +.error_fmt = QERR_EACCES,
> > +.desc  = "Cannot access file'",
> > +},
> 
> We already have QERR_PERMISSION_DENIED.
> 
> > +{
> > +.error_fmt = QERR_EEXIST,
> > +.desc  = "File already exists'",
> > +},
> 
> Can you use the description provided by man 3 errno? This is valid for all
> errors you're adding.
> 
> > +{
> > +.error_fmt = QERR_OPEN_FILE_EMFILE,
> > +.desc  = "Max open files when opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_ENOSPC,
> > +.desc  = "No space left opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_EPERM,
> > +.desc  = "Permission denied (EPERM) opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_READ_ONLY,
> > +.desc  = "Read only filesystem opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_ENOTDIR,
> > +.desc  = "Directory related error opening file'",
> > +},
> > +{
> > +.error_fmt = QERR_EFBIG,
> > +.desc  = "File too big opening'",
> > +},
> > +{
> >  .error_fmt = QERR_PERMISSION_DENIED,
> >  .desc  = "Insufficient permission to perform this operation",
> >  },
> > diff --git a/qerror.h b/qerror.h
> > index e26c635..ddc04e8 100644
> > --- a/qerror.h
> > +++ b/qerror.h
> > @@ -181,6 +181,33 @@ QError *qobject_to_qerror(const QObject *obj);
> >  #define QERR_OPEN_FILE_FAILED \
> >  "{ 'class': 'OpenFileFailed', 'data': { 'filename': %s } }"
> >  
> > +#define QERR_OPEN_FILE_EMFILE \
> > +"{ 'class': 'OpenFileEMFILE', 'data': {} }"
> > +
> > +#define QERR_EINTR \
> > +"{ 'class': 'EINTR', 'data': {} }"
> > +
> > +#define QERR_EACCES \
> > +"{ 'class': 'EACCES', 'data': {} }"
> > +
> > +#define QERR_EEXIST \
> > +"{ 'class': 'EEXIST', 'data': {} }"
> 
> We use more descriptive names instead of using the errno name. Like 
> AlreadyExists.
> Please fix it for errors you adding.
> 
> > +
> > +#define QERR_ENOSPC \
> > +"{ 'class': 'ENOSPC', 'data': {} }"
> > +
> > +#define QERR_EPERM \
> > +"{ 'class': 'EPERM', 'data': {} }"
> > +
> > +#define QERR_READ_ONLY \
> > +"{ 'class': 'ReadOnly', 'data': {} }"
> > +
> > +#define QERR_ENOTDIR \
> > +"{ 'class': 'ENOTDIR', 'data': {} }"
> > +
> > +#define QERR_EFBIG \
> > +"{ 'class': 'EFBIG', 'data': {} }"
> > +
> >  #define QERR_PERMISSION_DENIED \
> >  "{ 'class': 'PermissionDenied', 'data': {} }"
> >  
> 
> 

Re: [Qemu-devel] [PATCH] qemu-ga: Make guest-network-get-interfaces Linux only

[Michael Roth]

On Mon, Mar 26, 2012 at 06:35:49PM +0200, Andreas Färber wrote:
> Am 20.03.2012 17:10, schrieb Michael Roth:
> > On Tue, Mar 20, 2012 at 04:09:53PM +0100, Michal Privoznik wrote:
> >> Currently, the implementation of that command is full of
> >> Linux specific code. Before any brave man will step into
> >> and port it to other OSes, make this function Linux only.
> >>
> >> Signed-off-by: Michal Privoznik 
> > 
> > Which aspect is linux-specific? getifaddrs() and getnameinfo() seem to
> > be available on BSD and OpenSolaris, and we're already stubbed for w32.
> > Are you seeing breakage?
> 
> The two OpenBSD buildbots were reporting breakages:
> 
> http://buildbot.b1-systems.de/qemu/buildslaves/brad_openbsd_current
> http://buildbot.b1-systems.de/qemu/buildslaves/kraxel_openbsd49
> 
> Unfortunately they rarely nag the people to blame ;) and the reports on
> qemu-devel are admittedly a bit brief.
> 
> Maybe it might make sense to let the buildbots build your qemu-ga
> staging branch as well, Michael? That could catch this in advance.

That would great! Is there any process in place for having a repo added? I've
been staging directly to pull branches, but started a single staging
branch at:

git://github.com/mdroth/qemu.git qga

> 
> Andreas
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> 

Re: [Qemu-devel] [PATCH 1/1] If user doesn't specify a uuid, generate a random one

[Brian Jackson]

On Mon, 26 Mar 2012 10:13:40 -0500, Serge E. Hallyn   
wrote:



Currently, if the user doesn't pass a uuid, the system uuid is set to
all zeros.  This patch generates a random one instead.

Is there a reason to prefer all zeros?  If not, can a patch like this
one be applied?

Signed-off-by: Serge Hallyn 
---
 vl.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index 112b0e0..2b53b62 100644
--- a/vl.c
+++ b/vl.c
@@ -247,7 +247,9 @@ int nb_numa_nodes;
 uint64_t node_mem[MAX_NODES];
 uint64_t node_cpumask[MAX_NODES];
+#include 




This adds a hard dep on libuuid (prior to this it's optional and only  
impacts the vdi block driver).





 uint8_t qemu_uuid[16];
+bool uuid_set = false;
static QEMUBootSetHandler *boot_set_handler;
 static void *boot_set_opaque;
@@ -3030,6 +3032,7 @@ int main(int argc, char **argv, char **envp)
 " Wrong format.\n");
 exit(1);
 }
+uuid_set = true;
 break;
case QEMU_OPTION_option_rom:
if (nb_option_roms >= MAX_OPTION_ROMS) {
@@ -3200,6 +3203,14 @@ int main(int argc, char **argv, char **envp)
 exit(0);
 }
+if (!uuid_set) {
+uuid_t uuid;
+uuid_generate(uuid);
+for (i = 0; i < 16; i++) {
+qemu_uuid[i] = uuid[i];
+}
+}
+
 /* Open the logfile at this point, if necessary. We can't open the  
logfile
  * when encountering either of the logging options (-d or -D)  
because the
  * other one may be encountered later on the command line, changing  
the

[Qemu-devel] [PATCH] qemu-ga: fix bsd build, and re-org linux-specific implementations

[Michael Roth]

Signed-off-by: Michael Roth 
---
 qga/commands-posix.c |  111 +
 1 files changed, 66 insertions(+), 45 deletions(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 7b2be2f..faf970d 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -12,29 +12,30 @@
  */
 
 #include 
+#include 
+#include 
+#include "qga/guest-agent-core.h"
+#include "qga-qmp-commands.h"
+#include "qerror.h"
+#include "qemu-queue.h"
+#include "host-utils.h"
 
 #if defined(__linux__)
 #include 
 #include 
-
-#if defined(__linux__) && defined(FIFREEZE)
-#define CONFIG_FSFREEZE
-#endif
-#endif
-
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include "qga/guest-agent-core.h"
-#include "qga-qmp-commands.h"
-#include "qerror.h"
-#include "qemu-queue.h"
-#include "host-utils.h"
 
+#if defined(__linux__) && defined(FIFREEZE)
+#define CONFIG_FSFREEZE
+#endif
+#endif
+
+#if defined(__linux__)
+/* TODO: use this in place of all post-fork() fclose(std*) callers */
 static void reopen_fd_to_null(int fd)
 {
 int nullfd;
@@ -50,6 +51,7 @@ static void reopen_fd_to_null(int fd)
 close(nullfd);
 }
 }
+#endif /* defined(__linux__) */
 
 void qmp_guest_shutdown(bool has_mode, const char *mode, Error **err)
 {
@@ -309,7 +311,11 @@ static void guest_file_init(void)
 QTAILQ_INIT(&guest_file_state.filehandles);
 }
 
+/* linux-specific implementations. avoid this if at all possible. */
+#if defined(__linux__)
+
 #if defined(CONFIG_FSFREEZE)
+
 static void disable_logging(void)
 {
 ga_disable_logging(ga_state);
@@ -505,38 +511,7 @@ static void guest_fsfreeze_cleanup(void)
 }
 }
 }
-#else
-/*
- * Return status of freeze/thaw
- */
-GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error **err)
-{
-error_set(err, QERR_UNSUPPORTED);
-
-return 0;
-}
-
-/*
- * Walk list of mounted file systems in the guest, and freeze the ones which
- * are real local file systems.
- */
-int64_t qmp_guest_fsfreeze_freeze(Error **err)
-{
-error_set(err, QERR_UNSUPPORTED);
-
-return 0;
-}
-
-/*
- * Walk list of frozen file systems in the guest, and thaw them.
- */
-int64_t qmp_guest_fsfreeze_thaw(Error **err)
-{
-error_set(err, QERR_UNSUPPORTED);
-
-return 0;
-}
-#endif
+#endif /* CONFIG_FSFREEZE */
 
 #define LINUX_SYS_STATE_FILE "/sys/power/state"
 #define SUSPEND_SUPPORTED 0
@@ -904,6 +879,52 @@ error:
 return NULL;
 }
 
+#else /* defined(__linux__) */
+
+GuestFsfreezeStatus qmp_guest_fsfreeze_status(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+
+return 0;
+}
+
+int64_t qmp_guest_fsfreeze_freeze(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+
+return 0;
+}
+
+int64_t qmp_guest_fsfreeze_thaw(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+
+return 0;
+}
+
+void qmp_guest_suspend_disk(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+void qmp_guest_suspend_ram(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+void qmp_guest_suspend_hybrid(Error **err)
+{
+error_set(err, QERR_UNSUPPORTED);
+}
+
+GuestNetworkInterfaceList *qmp_guest_network_get_interfaces(Error **errp)
+{
+error_set(errp, QERR_UNSUPPORTED);
+return NULL;
+}
+
+#endif
+
 /* register init/cleanup routines for stateful command groups */
 void ga_command_state_init(GAState *s, GACommandState *cs)
 {
-- 
1.7.4.1

[Qemu-devel] [PULL] qemu-ga build fixes

[Michael Roth]

The following changes since commit cb1977d308f6e1d6bf398d42e6148187b82456c1:

  tcg-sparc: Add debug_frame support. (2012-03-24 19:57:58 +)

are available in the git repository at:
  git://github.com/mdroth/qemu.git qga-pull-3-26-12

Michael Roth (1):
  qemu-ga: fix bsd build, and re-org linux-specific implementations

 qga/commands-posix.c |  111 +
 1 files changed, 66 insertions(+), 45 deletions(-)

[Qemu-devel] [RFC PATCH v2 4/8] tracetool: Add support for the 'stderr' backend

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 scripts/tracetool/backend/stderr.py |   61 +++
 1 files changed, 61 insertions(+), 0 deletions(-)
 create mode 100644 scripts/tracetool/backend/stderr.py

diff --git a/scripts/tracetool/backend/stderr.py 
b/scripts/tracetool/backend/stderr.py
new file mode 100644
index 000..5f9abcd
--- /dev/null
+++ b/scripts/tracetool/backend/stderr.py
@@ -0,0 +1,61 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+"""
+Stderr built-in backend.
+"""
+
+__author__ = "Lluís Vilanova "
+__copyright__  = "Copyright 2012, Lluís Vilanova "
+__license__= "GPL version 2 or (at your option) any later version"
+
+__maintainer__ = "Stefan Hajnoczi"
+__email__  = "stefa...@linux.vnet.ibm.com"
+
+
+from tracetool import out
+
+
+PUBLIC = True
+
+
+def c(events):
+out('#include "trace.h"',
+'',
+'TraceEvent trace_list[] = {')
+
+for e in events:
+out('{.tp_name = "%(name)s", .state=0},' %
+{
+'name': e.name,
+})
+
+out('};')
+
+def h(events):
+out('#include ',
+'#include "trace/stderr.h"',
+'',
+'extern TraceEvent trace_list[];')
+
+for num, e in enumerate(events):
+argnames = ", ".join(e.args.names())
+if len(e.args) > 0:
+argnames = ", " + argnames
+
+out('''
+static inline void trace_%(name)s(%(args)s)
+{
+if (trace_list[%(event_num)s].state != 0) {
+fprintf(stderr, "%(name)s " %(fmt)s "\\n" %(argnames)s);
+}
+}''' % {
+'name': e.name,
+'args': e.args,
+'event_num': num,
+'fmt': e.fmt,
+'argnames': argnames,
+})
+
+out('',
+'#define NR_TRACE_EVENTS %d' % len(events))

[Qemu-devel] [RFC PATCH v2 7/8] tracetool: Add support for the 'dtrace' backend

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 scripts/tracetool.py|   31 ++
 scripts/tracetool/__init__.py   |8 +++
 scripts/tracetool/backend/dtrace.py |  104 +++
 scripts/tracetool/format/d.py   |   20 +++
 scripts/tracetool/format/stap.py|   20 +++
 5 files changed, 183 insertions(+), 0 deletions(-)
 create mode 100644 scripts/tracetool/backend/dtrace.py
 create mode 100644 scripts/tracetool/format/d.py
 create mode 100644 scripts/tracetool/format/stap.py

diff --git a/scripts/tracetool.py b/scripts/tracetool.py
index 22623ae..2dd9da0 100755
--- a/scripts/tracetool.py
+++ b/scripts/tracetool.py
@@ -44,6 +44,11 @@ Options:
 --help   This help message.
 --list-backends  Print list of available backends.
 --check-backend  Check if the given backend is valid.
+--binary   Full path to QEMU binary.
+--target-type  QEMU emulator target type ('system' or 'user').
+--target-arch  QEMU emulator target arch.
+--probe-prefix   Prefix for dtrace probe names
+ (default: qemu--).\
 """ % {
 "script" : _SCRIPT,
 "backends" : backend_descr,
@@ -71,6 +76,10 @@ def main(args):
 check_backend = False
 arg_backend = ""
 arg_format = ""
+binary = None
+target_type = None
+target_arch = None
+probe_prefix = None
 for opt, arg in opts:
 if opt == "--help":
 error_opt()
@@ -87,6 +96,15 @@ def main(args):
 elif opt == "--check-backend":
 check_backend = True
 
+elif opt == "--binary":
+binary = arg
+elif opt == '--target-type':
+target_type = arg
+elif opt == '--target-arch':
+target_arch = arg
+elif opt == '--probe-prefix':
+probe_prefix = arg
+
 else:
 error_opt("unhandled option: %s" % opt)
 
@@ -101,6 +119,19 @@ def main(args):
 
 kwargs = {}
 
+if format == "stap":
+if binary is None:
+error_opt("--binary is required for SystemTAP tapset generator")
+if probe_prefix is None and target_type is None:
+error_opt("--target-type is required for SystemTAP tapset 
generator")
+if probe_prefix is None and target_arch is None:
+error_opt("--target-arch is required for SystemTAP tapset 
generator")
+
+if probe_prefix is None:
+probe_prefix = ".".join([ "qemu", target_type, target_arch ])
+kwargs["binary"] = binary
+kwargs["probe_prefix"] = probe_prefix
+
 try:
 tracetool.generate(sys.stdin, arg_format, arg_backend, **kwargs)
 except tracetool.TracetoolError as e:
diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index d8e5cdd..d21f88a 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -167,6 +167,9 @@ def generate(fevents, format, backend, **options):
 # fix strange python error (UnboundLocalError tracetool)
 import tracetool
 
+binary = options.pop("binary", None)
+probe_prefix = options.pop("probe_prefix", None)
+
 if len(options) > 0:
 raise ValueError("unknown options: " + ", ".join(options))
 
@@ -188,6 +191,11 @@ def generate(fevents, format, backend, **options):
 raise TracetoolError("backend '%s' not compatible with format '%s'" %
  (backend, format))
 
+if backend == "dtrace":
+import tracetool.backend.dtrace
+tracetool.backend.dtrace.BINARY = binary
+tracetool.backend.dtrace.PROBEPREFIX = probe_prefix
+
 events = _read_events(fevents)
 
 if backend == "nop":
diff --git a/scripts/tracetool/backend/dtrace.py 
b/scripts/tracetool/backend/dtrace.py
new file mode 100644
index 000..7c2051c
--- /dev/null
+++ b/scripts/tracetool/backend/dtrace.py
@@ -0,0 +1,104 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+"""
+DTrace/SystemTAP backend.
+"""
+
+__author__ = "Lluís Vilanova "
+__copyright__  = "Copyright 2012, Lluís Vilanova "
+__license__= "GPL version 2 or (at your option) any later version"
+
+__maintainer__ = "Stefan Hajnoczi"
+__email__  = "stefa...@linux.vnet.ibm.com"
+
+
+from tracetool import out
+
+
+PUBLIC = True
+
+
+PROBEPREFIX = None
+
+def _probeprefix():
+if PROBEPREFIX is None:
+raise ValueError("you must set PROBEPREFIX")
+return PROBEPREFIX
+
+
+BINARY = None
+
+def _binary():
+if BINARY is None:
+raise ValueError("you must set BINARY")
+return BINARY
+
+
+def c(events):
+pass
+
+
+def h(events):
+out('#include "trace-dtrace.h"',
+'')
+
+for e in events:
+out('''static inline void trace_%(name)s(%(args)s) {
+QEMU_%(uppername)s(%(argnames)s);
+}
+''' %
+{
+'name': e.name,
+'args': e.args,
+'uppername': e.name.upper(),
+'argnames'

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Blue Swirl]

On Mon, Mar 26, 2012 at 18:07, Anthony Liguori  wrote:
> On 03/26/2012 01:01 PM, Blue Swirl wrote:
>>
>> On Mon, Mar 26, 2012 at 17:45, Anthony Liguori
>>  wrote:
>>>
>>>
>>>
>>> Is this something we universally want to do?  What would we do about
>>> patches
>>> to audio?
>>
>>
>> I'd do it in cases when there is code movement, then git blame will
>> not be very useful anyway and other people have to rebase their
>> patches as well.
>>
>> The audio case has an additional factor, namely maintainer disagreeing
>> with global style and consistency. There are several ways how to
>> handle that case, one of which is to maintain status quo.
>>
>>> I'd prefer not to go down this road.  Let's keep discussion of fixing
>>> CODING_STYLE of existing code separate from rearchitecting/enhancing
>>> code.
>>
>>
>> When code is moved, rearchitected or enhanced, that would be a good
>> point when to fix style too. Though this assumes that just fixing
>> style without those events is evil, but is it? I think you have not
>> been fully consistent in this matter.
>
>
> I think modifying coding style alone is evil.
>
> But I'm also sick of arguing about coding style.  If you take this patch
> series as an example, this is the beginning of a fundamental refactoring to
> how we do machines and devices in QEMU--and yet, we're discussing coding
> style.

Well, if for example this "fix style in the first patch, then move"
would be a widely accepted rule, there would be no discussion. Now we
can discuss forever if reformatting is needed or not.

> I don't see an obvious way to just get past the coding style discussions.
>  If there was a perfect way to automate fixing coding style, at this point,
> I would say let's do it.  But there is no way I want to spend the next two
> years taking coding style fixup patches.

I'd just reformat once, that would reduce fixup patches considerably.
I can also volunteer to review and apply all pure style fixup patches
if that helps.

> Regards,
>
> Anthony Liguori
>
>>> Regards,
>>>
>>> Anthony Liguori
>>>

> Regards,
>
> Anthony Liguori
>>>
>>>
>>>
>

[Qemu-devel] [PULL] libcacard queue, start with no reader fixes

[Alon Levy]

Hi Anthony,

 Some small fixes for libcacard to handle starting when no readers
 are available, and reader removal and reinsertion while running.
 
 Sent last weekend, no comments so far so I'm sending a pull request.

Thanks,
Alon

The following changes since commit cb1977d308f6e1d6bf398d42e6148187b82456c1:

  tcg-sparc: Add debug_frame support. (2012-03-24 19:57:58 +)

are available in the git repository at:

  git://people.freedesktop.org/~alon/qemu libcacard

for you to fetch changes up to 6f06f178f96de3597e1098258ab5d11733ae8602:

  libcacard/vcard_emul_nss: add warning for old coolkey (2012-03-26 18:39:00 
+0200)


Alon Levy (3):
  libcacard/vcard_emul_nss: don't stop thread when there are no slots
  libcacard/vcard_emul_nss: handle no readers at startup
  libcacard/vcard_emul_nss: add warning for old coolkey

 libcacard/vcard_emul_nss.c |   36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 01:01 PM, Blue Swirl wrote:

On Mon, Mar 26, 2012 at 17:45, Anthony Liguori  wrote:



Is this something we universally want to do?  What would we do about patches
to audio?


I'd do it in cases when there is code movement, then git blame will
not be very useful anyway and other people have to rebase their
patches as well.

The audio case has an additional factor, namely maintainer disagreeing
with global style and consistency. There are several ways how to
handle that case, one of which is to maintain status quo.


I'd prefer not to go down this road.  Let's keep discussion of fixing
CODING_STYLE of existing code separate from rearchitecting/enhancing code.


When code is moved, rearchitected or enhanced, that would be a good
point when to fix style too. Though this assumes that just fixing
style without those events is evil, but is it? I think you have not
been fully consistent in this matter.


I think modifying coding style alone is evil.

But I'm also sick of arguing about coding style.  If you take this patch series 
as an example, this is the beginning of a fundamental refactoring to how we do 
machines and devices in QEMU--and yet, we're discussing coding style.


I don't see an obvious way to just get past the coding style discussions.  If 
there was a perfect way to automate fixing coding style, at this point, I would 
say let's do it.  But there is no way I want to spend the next two years taking 
coding style fixup patches.


Regards,

Anthony Liguori


Regards,

Anthony Liguori




Regards,

Anthony Liguori

[Qemu-devel] [RFC PATCH v2 5/8] tracetool: Add support for the 'simple' backend

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 scripts/tracetool/backend/simple.py |   60 +++
 1 files changed, 60 insertions(+), 0 deletions(-)
 create mode 100644 scripts/tracetool/backend/simple.py

diff --git a/scripts/tracetool/backend/simple.py 
b/scripts/tracetool/backend/simple.py
new file mode 100644
index 000..fea0a37
--- /dev/null
+++ b/scripts/tracetool/backend/simple.py
@@ -0,0 +1,60 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+"""
+Simple built-in backend.
+"""
+
+__author__ = "Lluís Vilanova "
+__copyright__  = "Copyright 2012, Lluís Vilanova "
+__license__= "GPL version 2 or (at your option) any later version"
+
+__maintainer__ = "Stefan Hajnoczi"
+__email__  = "stefa...@linux.vnet.ibm.com"
+
+
+from tracetool import out
+
+
+PUBLIC = True
+
+
+def c(events):
+out('#include "trace.h"',
+'',
+'TraceEvent trace_list[] = {')
+
+for e in events:
+out('{.tp_name = "%(name)s", .state=0},' % {
+'name': e.name,
+})
+
+out('};')
+
+def h(events):
+out('#include "trace/simple.h"',
+'')
+
+for num, e in enumerate(events):
+if len(e.args):
+argstr = e.args.names()
+arg_prefix = ', (uint64_t)(uintptr_t)'
+cast_args = arg_prefix + arg_prefix.join(argstr)
+simple_args = (str(num) + cast_args)
+else:
+simple_args = str(num)
+
+out('''\
+static inline void trace_%(name)s(%(args)s)
+{
+trace%(argc)d(%(trace_args)s);
+}
+''' % {
+'name': e.name,
+'args': e.args,
+'argc': len(e.args),
+'trace_args': simple_args,
+})
+
+out('#define NR_TRACE_EVENTS %d' % len(events))
+out('extern TraceEvent trace_list[NR_TRACE_EVENTS];')

[Qemu-devel] [RFC PATCH v2 6/8] tracetool: Add support for the 'ust' backend

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 scripts/tracetool/backend/ust.py |  102 ++
 1 files changed, 102 insertions(+), 0 deletions(-)
 create mode 100644 scripts/tracetool/backend/ust.py

diff --git a/scripts/tracetool/backend/ust.py b/scripts/tracetool/backend/ust.py
new file mode 100644
index 000..6871373
--- /dev/null
+++ b/scripts/tracetool/backend/ust.py
@@ -0,0 +1,102 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+"""
+LTTng User Space Tracing backend.
+"""
+
+__author__ = "Lluís Vilanova "
+__copyright__  = "Copyright 2012, Lluís Vilanova "
+__license__= "GPL version 2 or (at your option) any later version"
+
+__maintainer__ = "Stefan Hajnoczi"
+__email__  = "stefa...@linux.vnet.ibm.com"
+
+
+from tracetool import out
+
+
+PUBLIC = True
+
+
+def c(events):
+out('#include ',
+'#undef mutex_lock',
+'#undef mutex_unlock',
+'#undef inline',
+'#undef wmb',
+'#include "trace.h"')
+
+for e in events:
+argnames = ", ".join(e.args.names())
+if len(e.args) > 0:
+argnames = ', ' + argnames
+
+out('''
+DEFINE_TRACE(ust_%(name)s);
+
+static void ust_%(name)s_probe(%(args)s)
+{
+trace_mark(ust, %(name)s, %(fmt)s%(argnames)s);
+}''' %
+{
+'name': e.name,
+'args': e.args,
+'fmt': e.fmt,
+'argnames': argnames,
+})
+
+else:
+out('''
+DEFINE_TRACE(ust_%(name)s);
+
+static void ust_%(name)s_probe(%(args)s)
+{
+trace_mark(ust, %(name)s, UST_MARKER_NOARGS);
+}''' %
+{
+'name': e.name,
+'args': e.args,
+})
+
+# register probes
+out('',
+'static void __attribute__((constructor)) trace_init(void)',
+'{')
+
+for e in events:
+out('register_trace_ust_%(name)s(ust_%(name)s_probe);' %
+{
+'name': e.name,
+})
+
+out('}')
+
+
+def h(events):
+out('#include ',
+'#undef mutex_lock',
+'#undef mutex_unlock',
+'#undef inline',
+'#undef wmb')
+
+for e in events:
+if len(e.args) > 0:
+out('''
+DECLARE_TRACE(ust_%(name)s, TP_PROTO(%(args)s), TP_ARGS(%(argnames)s));
+#define trace_%(name)s trace_ust_%(name)s''' %
+{
+'name': e.name,
+'args': e.args,
+'argnames': ", ".join(e.args.names())
+})
+
+else:
+out('''
+_DECLARE_TRACEPOINT_NOARGS(ust_%(name)s);
+#define trace_%(name)s trace_ust_%(name)s''' %
+{
+'name': e.name,
+})
+
+out()

Re: [Qemu-devel] [PATCH 1/1] If user doesn't specify a uuid, generate a random one

[Serge E. Hallyn]

Quoting Andreas Färber (afaer...@suse.de):
> Am 26.03.2012 17:13, schrieb Serge E. Hallyn:
> > Currently, if the user doesn't pass a uuid, the system uuid is set to
> > all zeros.  This patch generates a random one instead.
> > 
> > Is there a reason to prefer all zeros?
> 
> Yes, documented somewhere in the archives, we wanted to have
> reproducible defaults in QEMU (cf. MAC address, IP addresses) so that it
> doesn't change for each invocation or depending on host.

Thanks.  Though I don't know of a case offhand, I guess I could imagine
a case where a guest's userspace acts differently (and mis-behaves)
based on the random uuid...

> As a general rule, randomization should be done either explicitly (-uuid
> `uuidgen` or -generate-me-a-uuid) or via frontends such as libvirt.
> 
> If all zeros causes genuine problems then we should change the default,
> taking care of backwards compatibility as usual.

The bug this was in reply to is at http://pad.lv/959308 .  IIUC the main
problem is that our crash database uses the uuid, so users need to set
one to report bugs.  (There was also a suggestion that Microsoft requires
it for Logo Certification.)  My suggestion was also to have callers
specify it, but the crash db issue means we'd have to wrap all calls to
qemu.

So thanks - I understand if this patch doesn't make it upstream.  I'll
just carry a patch in our package in that case.

thanks,
-serge

[Qemu-devel] [RFC PATCH v2 2/8] tracetool: Add module for the 'c' format

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 scripts/tracetool/format/c.py |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)
 create mode 100644 scripts/tracetool/format/c.py

diff --git a/scripts/tracetool/format/c.py b/scripts/tracetool/format/c.py
new file mode 100644
index 000..3ae
--- /dev/null
+++ b/scripts/tracetool/format/c.py
@@ -0,0 +1,20 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+"""
+Generate .c file.
+"""
+
+__author__ = "Lluís Vilanova "
+__copyright__  = "Copyright 2012, Lluís Vilanova "
+__license__= "GPL version 2 or (at your option) any later version"
+
+__maintainer__ = "Stefan Hajnoczi"
+__email__  = "stefa...@linux.vnet.ibm.com"
+
+
+from tracetool import out
+
+
+def begin(events):
+out('/* This file is autogenerated by tracetool, do not edit. */')

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Blue Swirl]

On Mon, Mar 26, 2012 at 17:45, Anthony Liguori  wrote:
> On 03/26/2012 12:43 PM, Blue Swirl wrote:
>>
>> On Mon, Mar 26, 2012 at 17:35, Anthony Liguori
>>  wrote:
>>>
>>> On 03/26/2012 12:09 PM, Blue Swirl wrote:


 On Mon, Mar 26, 2012 at 02:06, Wanpeng Li
  wrote:
>
>
>
> From: Anthony Liguori
>
>
> This series aggressively refactors the PC machine initialization to be
> more
> modelled and less ad-hoc.  The highlights of this series are:



 Please fix coding style while moving.
>>>
>>>
>>>
>>> I disagree.  That makes reviewing the movement and rebasing the movement
>>> pretty difficult.
>>
>>
>> Yes, a separate step would be nice.
>>
>>> If we were to fix the issues, it should before or after.  But in that
>>> context, I think it makes it orthogonal to moving the code and should be
>>> treated independently.
>>
>>
>> I'd fix the style in the first patch, then perform moves etc. That way
>> no patch would add noncompliant code, only remove.
>
>
> Is this something we universally want to do?  What would we do about patches
> to audio?

I'd do it in cases when there is code movement, then git blame will
not be very useful anyway and other people have to rebase their
patches as well.

The audio case has an additional factor, namely maintainer disagreeing
with global style and consistency. There are several ways how to
handle that case, one of which is to maintain status quo.

> I'd prefer not to go down this road.  Let's keep discussion of fixing
> CODING_STYLE of existing code separate from rearchitecting/enhancing code.

When code is moved, rearchitected or enhanced, that would be a good
point when to fix style too. Though this assumes that just fixing
style without those events is evil, but is it? I think you have not
been fully consistent in this matter.

> Regards,
>
> Anthony Liguori
>
>>
>>> Regards,
>>>
>>> Anthony Liguori
>
>

Re: [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion

[Lluís Vilanova]

Blue Swirl writes:

> On Mon, Mar 26, 2012 at 13:05, Paul Brook  wrote:
>>> On 24 March 2012 18:58, Blue Swirl  wrote:
>>> > v2: fix patch 1, tweak patch 2 and rebase to master.
>>> >
>>> > URL     git://repo.or.cz/qemu/blueswirl.git
>>> >        http://repo.or.cz/r/qemu/blueswirl.git
>>> >
>>> > Blue Swirl (6):
>>> >  arm: move neon_tbl to neon_helper.c
>>> >  arm: move saturating arithmetic to helper.c
>>> >  arm: move other arithmetic to helper.c
>>> >  arm: move cpsr and banked register access to helper.c
>>> >  arm: move exception and wfi helpers to helper.c
>>> >  arm: move load and store helpers, switch to AREG0 free mode
>>> 
>>> The patches themselves look OK, but do we really want to take
>>> a 5% performance hit for this cleanup?
>> 
>> I have a similar concern.  I'd like to at least have some idea where this
>> slowdown is coming from.

> At least stack protector is protecting more code than before (for
> example TLB miss handler), but could overhead from that amount to 5%?

Then you can try comparing both builds with a modified configure that does not
add the "-fstack-protector-all" option.

If you want to fine-tune it, you can add
"__attribute__((optimize("no-stack-protector")))" to those functions or just
add:

#pragma GCC push_options
#pragma GCC optimize ("no-stack-protector")

at the beginning of the "softmmu_template.h", and:

#pragma GCC pop_options

at the end of it.

Or even better, use it for the whole "target-*/*helper.c" file, as there should
be no user-induced overflow in helpers (unless the instr decoding code in
"translate.c" is exploitable).


Thanks,
  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

[Qemu-devel] [RFC PATCH v2 8/8] tracetool: Add MAINTAINERS info

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 MAINTAINERS |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f83d07c2..0e66dd8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -548,6 +548,8 @@ Tracing
 M: Stefan Hajnoczi 
 S: Maintained
 F: trace/
+F: scripts/tracetool.py
+F: scripts/tracetool/
 F: docs/tracing.txt
 T: git://github.com/stefanha/qemu.git tracing
 

[Qemu-devel] [RFC PATCH v2 1/8] tracetool: Rewrite infrastructure as python modules

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 Makefile.objs |6 
 Makefile.target   |   13 -
 configure |4 
 scripts/tracetool |  648 -
 scripts/tracetool.py  |  110 ++
 scripts/tracetool/__init__.py |  205 ++
 scripts/tracetool/backend/__init__.py |  114 ++
 scripts/tracetool/format/__init__.py  |   91 +
 8 files changed, 532 insertions(+), 659 deletions(-)
 delete mode 100755 scripts/tracetool
 create mode 100755 scripts/tracetool.py
 create mode 100644 scripts/tracetool/__init__.py
 create mode 100644 scripts/tracetool/backend/__init__.py
 create mode 100644 scripts/tracetool/format/__init__.py

diff --git a/Makefile.objs b/Makefile.objs
index 226b01d..8e56f48 100644
--- a/Makefile.objs
+++ b/Makefile.objs
@@ -373,12 +373,12 @@ else
 trace.h: trace.h-timestamp
 endif
 trace.h-timestamp: $(SRC_PATH)/trace-events $(BUILD_DIR)/config-host.mak
-   $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool 
--$(TRACE_BACKEND) -h < $< > $@,"  GEN   trace.h")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/tracetool.py 
--format=h --backend=$(TRACE_BACKEND) < $< > $@,"  GEN   trace.h")
@cmp -s $@ trace.h || cp $@ trace.h
 
 trace.c: trace.c-timestamp
 trace.c-timestamp: $(SRC_PATH)/trace-events $(BUILD_DIR)/config-host.mak
-   $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool 
--$(TRACE_BACKEND) -c < $< > $@,"  GEN   trace.c")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/tracetool.py 
--format=c --backend=$(TRACE_BACKEND) < $< > $@,"  GEN   trace.c")
@cmp -s $@ trace.c || cp $@ trace.c
 
 trace.o: trace.c $(GENERATED_HEADERS)
@@ -391,7 +391,7 @@ trace-dtrace.h: trace-dtrace.dtrace
 # rule file. So we use '.dtrace' instead
 trace-dtrace.dtrace: trace-dtrace.dtrace-timestamp
 trace-dtrace.dtrace-timestamp: $(SRC_PATH)/trace-events 
$(BUILD_DIR)/config-host.mak
-   $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool 
--$(TRACE_BACKEND) -d < $< > $@,"  GEN   trace-dtrace.dtrace")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/tracetool.py 
--format=d --backend=$(TRACE_BACKEND) < $< > $@,"  GEN   trace-dtrace.dtrace")
@cmp -s $@ trace-dtrace.dtrace || cp $@ trace-dtrace.dtrace
 
 trace-dtrace.o: trace-dtrace.dtrace $(GENERATED_HEADERS)
diff --git a/Makefile.target b/Makefile.target
index 63cf769..fe28e8b 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -59,12 +59,13 @@ TARGET_TYPE=system
 endif
 
 $(QEMU_PROG).stp:
-   $(call quiet-command,sh $(SRC_PATH)/scripts/tracetool \
-   --$(TRACE_BACKEND) \
-   --binary $(bindir)/$(QEMU_PROG) \
-   --target-arch $(TARGET_ARCH) \
-   --target-type $(TARGET_TYPE) \
-   --stap < $(SRC_PATH)/trace-events > $(QEMU_PROG).stp,"  GEN   
$(QEMU_PROG).stp")
+   $(call quiet-command,$(PYTHON) $(SRC_PATH)/scripts/tracetool.py \
+   --format=stap \
+   --backend=$(TRACE_BACKEND) \
+   --binary=$(bindir)/$(QEMU_PROG) \
+   --target-arch=$(TARGET_ARCH) \
+   --target-type=$(TARGET_TYPE) \
+   < $(SRC_PATH)/trace-events > $(QEMU_PROG).stp,"  GEN   
$(QEMU_PROG).stp")
 else
 stap:
 endif
diff --git a/configure b/configure
index 8b4e3c1..c2d6117 100755
--- a/configure
+++ b/configure
@@ -1097,7 +1097,7 @@ echo "  --disable-docs   disable documentation 
build"
 echo "  --disable-vhost-net  disable vhost-net acceleration support"
 echo "  --enable-vhost-net   enable vhost-net acceleration support"
 echo "  --enable-trace-backend=B Set trace backend"
-echo "   Available backends:" 
$("$source_path"/scripts/tracetool --list-backends)
+echo "   Available backends:" $($python 
"$source_path"/scripts/tracetool.py --list-backends)
 echo "  --with-trace-file=NAME   Full PATH,NAME of file to store traces"
 echo "   Default:trace-"
 echo "  --disable-spice  disable spice"
@@ -2654,7 +2654,7 @@ fi
 ##
 # check if trace backend exists
 
-sh "$source_path/scripts/tracetool" "--$trace_backend" --check-backend > 
/dev/null 2> /dev/null
+$python "$source_path/scripts/tracetool.py" "--backend=$trace_backend" 
--check-backend  > /dev/null 2> /dev/null
 if test "$?" -ne 0 ; then
   echo
   echo "Error: invalid trace backend"
diff --git a/scripts/tracetool b/scripts/tracetool
deleted file mode 100755
index 65bd0a1..000
--- a/scripts/tracetool
+++ /dev/null
@@ -1,648 +0,0 @@
-#!/bin/sh
-#
-# Code generator for trace events
-#
-# Copyright IBM, Corp. 2010
-#
-# This work is licensed under the terms of the GNU GPL, version 2.  See
-# the COPYING file in the top-level directory.
-
-# Disable pathname expansion, makes processing text with '*' characters simpler
-set -f
-
-usage()
-{
-cat >&2 < retur

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 12:43 PM, Blue Swirl wrote:

On Mon, Mar 26, 2012 at 17:35, Anthony Liguori  wrote:

On 03/26/2012 12:09 PM, Blue Swirl wrote:


On Mon, Mar 26, 2012 at 02:06, Wanpeng Liwrote:



From: Anthony Liguori


This series aggressively refactors the PC machine initialization to be
more
modelled and less ad-hoc.  The highlights of this series are:



Please fix coding style while moving.



I disagree.  That makes reviewing the movement and rebasing the movement
pretty difficult.


Yes, a separate step would be nice.


If we were to fix the issues, it should before or after.  But in that
context, I think it makes it orthogonal to moving the code and should be
treated independently.


I'd fix the style in the first patch, then perform moves etc. That way
no patch would add noncompliant code, only remove.


Is this something we universally want to do?  What would we do about patches to 
audio?


I'd prefer not to go down this road.  Let's keep discussion of fixing 
CODING_STYLE of existing code separate from rearchitecting/enhancing code.


Regards,

Anthony Liguori




Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Blue Swirl]

On Mon, Mar 26, 2012 at 17:35, Anthony Liguori  wrote:
> On 03/26/2012 12:09 PM, Blue Swirl wrote:
>>
>> On Mon, Mar 26, 2012 at 02:06, Wanpeng Li  wrote:
>>>
>>>
>>> From: Anthony Liguori
>>>
>>>
>>> This series aggressively refactors the PC machine initialization to be
>>> more
>>> modelled and less ad-hoc.  The highlights of this series are:
>>
>>
>> Please fix coding style while moving.
>
>
> I disagree.  That makes reviewing the movement and rebasing the movement
> pretty difficult.

Yes, a separate step would be nice.

> If we were to fix the issues, it should before or after.  But in that
> context, I think it makes it orthogonal to moving the code and should be
> treated independently.

I'd fix the style in the first patch, then perform moves etc. That way
no patch would add noncompliant code, only remove.

> Regards,
>
> Anthony Liguori

[Qemu-devel] [RFC PATCH v2 3/8] tracetool: Add module for the 'h' format

[Lluís Vilanova]

Signed-off-by: Lluís Vilanova 
---
 scripts/tracetool/format/h.py |   45 +
 1 files changed, 45 insertions(+), 0 deletions(-)
 create mode 100644 scripts/tracetool/format/h.py

diff --git a/scripts/tracetool/format/h.py b/scripts/tracetool/format/h.py
new file mode 100644
index 000..41a3e2b
--- /dev/null
+++ b/scripts/tracetool/format/h.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+
+"""
+Generate .h file.
+"""
+
+__author__ = "Lluís Vilanova "
+__copyright__  = "Copyright 2012, Lluís Vilanova "
+__license__= "GPL version 2 or (at your option) any later version"
+
+__maintainer__ = "Stefan Hajnoczi"
+__email__  = "stefa...@linux.vnet.ibm.com"
+
+
+from tracetool import out
+
+
+def begin(events):
+out('/* This file is autogenerated by tracetool, do not edit. */',
+'',
+'#ifndef TRACE_H',
+'#define TRACE_H',
+'',
+'#include "qemu-common.h"')
+
+def end(events):
+for e in events:
+if "disable" in e.properties:
+enabled = 0
+else:
+enabled = 1
+out('#define TRACE_%s_ENABLED %d' % (e.name.upper(), enabled))
+out('',
+'#endif /* TRACE_H */')
+
+def nop(events):
+for e in events:
+out('',
+'static inline void trace_%(name)s(%(args)s)' % {
+'name': e.name,
+'args': e.args
+},
+'{',
+'}')

Re: [Qemu-devel] [PATCH 5/6] merge pc_piix.c to pc.c

[Anthony Liguori]

On 03/26/2012 07:47 AM, Jan Kiszka wrote:

On 2012-03-26 14:42, Avi Kivity wrote:

On 03/26/2012 04:06 AM, Wanpeng Li wrote:

From: Anthony Liguori

@@ -889,7 +900,7 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
  DeviceState *dev;
  static int apic_mapped;

-if (kvm_irqchip_in_kernel()) {
+if (kvm_enabled()&&  kvm_irqchip_in_kernel()) {
  dev = qdev_create(NULL, "kvm-apic");
  } else {
  dev = qdev_create(NULL, "apic");
@@ -908,7 +919,7 @@ static DeviceState *apic_init(void *env, uint8_t apic_id)
  }

  /* KVM does not support MSI yet. */
-if (!kvm_irqchip_in_kernel()) {
+if (!kvm_enabled() || !kvm_irqchip_in_kernel()) {
  msi_supported = true;


Why these changes?



Yep, they are obsolete, likely related to the rebase of the original
patch. A lot of code is moved around here, and I bet there are more
artifacts...


git should have thrown a rebase error here.  I think that means the conflicts 
were ignored.


For something like this, if there's a rebase error, you pretty much have to 
repeat the copy/paste of the code for the section that threw a rebase error.


I'd suggest rebasing again but this time, be a bit more careful when resolving 
conflicts.


Regards,

Anthony Liguori



Jan

[Qemu-devel] [RFC PATCH v2 0/8] Rewrite tracetool using python modules

[Lluís Vilanova]

A full rewrite of the tracetool script using per-format and per-backend modules,
so that it's easier to read and extend it in the future.

Signed-off-by: Lluís Vilanova 
---
NOTE: This series applies in current master, ignoring the "Rewrite tracetool
  using python" series.

Changes in v2:

* Fixed a strange import error.
* Add a pointer to 'tracetool.out' in the format and backend documentation.

Lluís Vilanova (8):
  tracetool: Rewrite infrastructure as python modules
  tracetool: Add module for the 'c' format
  tracetool: Add module for the 'h' format
  tracetool: Add support for the 'stderr' backend
  tracetool: Add support for the 'simple' backend
  tracetool: Add support for the 'ust' backend
  tracetool: Add support for the 'dtrace' backend
  tracetool: Add MAINTAINERS info


 MAINTAINERS   |2 
 Makefile.objs |6 
 Makefile.target   |   13 -
 configure |4 
 scripts/tracetool |  648 -
 scripts/tracetool.py  |  141 +++
 scripts/tracetool/__init__.py |  213 +++
 scripts/tracetool/backend/__init__.py |  114 ++
 scripts/tracetool/backend/dtrace.py   |  104 +
 scripts/tracetool/backend/simple.py   |   60 +++
 scripts/tracetool/backend/stderr.py   |   61 +++
 scripts/tracetool/backend/ust.py  |  102 +
 scripts/tracetool/format/__init__.py  |   91 +
 scripts/tracetool/format/c.py |   20 +
 scripts/tracetool/format/d.py |   20 +
 scripts/tracetool/format/h.py |   45 ++
 scripts/tracetool/format/stap.py  |   20 +
 17 files changed, 1005 insertions(+), 659 deletions(-)
 delete mode 100755 scripts/tracetool
 create mode 100755 scripts/tracetool.py
 create mode 100644 scripts/tracetool/__init__.py
 create mode 100644 scripts/tracetool/backend/__init__.py
 create mode 100644 scripts/tracetool/backend/dtrace.py
 create mode 100644 scripts/tracetool/backend/simple.py
 create mode 100644 scripts/tracetool/backend/stderr.py
 create mode 100644 scripts/tracetool/backend/ust.py
 create mode 100644 scripts/tracetool/format/__init__.py
 create mode 100644 scripts/tracetool/format/c.py
 create mode 100644 scripts/tracetool/format/d.py
 create mode 100644 scripts/tracetool/format/h.py
 create mode 100644 scripts/tracetool/format/stap.py

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 12:09 PM, Blue Swirl wrote:

On Mon, Mar 26, 2012 at 02:06, Wanpeng Li  wrote:


From: Anthony Liguori


This series aggressively refactors the PC machine initialization to be more
modelled and less ad-hoc.  The highlights of this series are:


Please fix coding style while moving.


I disagree.  That makes reviewing the movement and rebasing the movement pretty 
difficult.


If we were to fix the issues, it should before or after.  But in that context, I 
think it makes it orthogonal to moving the code and should be treated independently.


Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 07:20 AM, Jan Kiszka wrote:

On 2012-03-26 04:06, Wanpeng Li wrote:

From: Anthony Liguori


This series aggressively refactors the PC machine initialization to be more
modelled and less ad-hoc.  The highlights of this series are:

  1) Things like -m and -bios-name are now device model properties

  2) The i440fx and piix3 are now modelled in a thorough fashion

  3) Most of the chipset features of the piix3 are modelled through composition

  4) i440fx_init is trivialized to creating devices and setting properties

  5) convert MemoryRegion to QOM

  6) convert PCI host bridge to QOM

The point (4) is the most important one.  As we refactor in this fashion,
we should quickly get to the point where machine->init disappears completely in
favor of just creating a handful of devices.

The two stage initialization of QOM is important here.  instance_init() is when
composed devices are created which means that after you've created a device, all
of its children are visible in the device model.  This lets you set properties
of the parent and its children.

realize() (which is still called DeviceState::init today) will be called right
before the guest starts up for the first time.


While I see the value of the overall direction, I still disagree on
making internal data structures of HPET, RTC and 8254 publicly
available. That's a wrong step back. I'm sure there are smarter
solutions, alse as there were some proposals back then in the original
thread.


I'm not fully decided myself.  A couple things are clear to me though:

1) We must expose type proper types in header files.  We need there to be a 
globally accessible RTCState type and functions that operate on it.


2) We can simplify memory management by knowing the size of the type in the 
header files too.


Since this is an easily refactorable thing to look at later, I think we should 
start with extracting the types.




I'm also sure we will have to refactor the merge significantly again for
the introduction of additional chipsets and PC boards. But unless those
requirements can already be specified (Isaku?), that might be unavoidable.


We cannot introduce another chipset without properly refactoring the i440fx. 
The previous refactorings that were oriented around moving code into functions 
created a nasty spaghetti of reference passing.


Regards,

Anthony Liguori


Jan

Re: [Qemu-devel] [RFC PATCH 0/8] Rewrite tracetool using python modules

[Lluís Vilanova]

Stefan Hajnoczi writes:
> I tried to build this after make distclean with the nop backend:

>   GEN   trace.h
> Traceback (most recent call last):
>   File "/home/stefanha/qemu/scripts/tracetool.py", line 141, in 
> main(sys.argv)
>   File "/home/stefanha/qemu/scripts/tracetool.py", line 136, in main
> tracetool.generate(sys.stdin, arg_format, arg_backend, **kwargs)
>   File "/home/stefanha/qemu/scripts/tracetool/__init__.py", line 177,
> in generate
> if not tracetool.format.exists(mformat):
> UnboundLocalError: local variable 'tracetool' referenced before assignment

> Do you also get this error?

Strange, I didn't get it on my first tests, but now I do on a clean checkout.

I'll resend the series (a simple "import tracetool" in the "generate" body seems
to work).


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] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/26/2012 10:54 AM, Isaku Yamahata wrote:

On Mon, Mar 26, 2012 at 02:20:24PM +0200, Jan Kiszka wrote:

I'm also sure we will have to refactor the merge significantly again for
the introduction of additional chipsets and PC boards. But unless those
requirements can already be specified (Isaku?), that might be unavoidable.


Agreed. At least I'd like pam/smram stuff decoupled from piix.


s/piix/i440fx/

PAM/SRAM has nothing do to with the piix.  Part of the problem with the current 
layout is that the distinction between i440fx and piix is not clear.  The piix 
is just a SuperIO chip (and southbridge).


I think the better approach is to have a PCNorthBridge base-class that contains 
functionality like PAM/SRAM that both I440FX and Q35 inherit from.


Obviously, without getting the I440FX/PIIX3 modeling in shape, we can't look 
reasonable at how to share code.


Regards,

Anthony Liguori


It is difficult to understand why patches of 5, 6 are needed without further
patches because they don't show how the code will look like eventually.
Anyway I expect some sort of refactor again and am waiting for QOM related
stuff stabilizing.

thanks,

[Qemu-devel] [PATCH v6 2/2] target-arm: Minimalistic CPU QOM'ification

[Andreas Färber]

Introduce only one non-abstract type TYPE_ARM_CPU and do not touch
cp15 registers to not interfere with Peter's ongoing remodelling.
Embed CPUARMState as first (additional) field of ARMCPU.

Let reset call cpu_state_reset() for now.

Signed-off-by: Andreas Färber 
---
 Makefile.target  |1 +
 target-arm/cpu-qom.h |   70 ++
 target-arm/cpu.c |   59 ++
 target-arm/cpu.h |1 +
 target-arm/helper.c  |4 ++-
 5 files changed, 134 insertions(+), 1 deletions(-)
 create mode 100644 target-arm/cpu-qom.h
 create mode 100644 target-arm/cpu.c

diff --git a/Makefile.target b/Makefile.target
index 44b2e83..6e8b997 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -92,6 +92,7 @@ endif
 libobj-$(TARGET_SPARC64) += vis_helper.o
 libobj-$(CONFIG_NEED_MMU) += mmu.o
 libobj-$(TARGET_ARM) += neon_helper.o iwmmxt_helper.o
+libobj-$(TARGET_ARM) += cpu.o
 ifeq ($(TARGET_BASE_ARCH), sparc)
 libobj-y += fop_helper.o cc_helper.o win_helper.o mmu_helper.o ldst_helper.o
 libobj-y += cpu_init.o
diff --git a/target-arm/cpu-qom.h b/target-arm/cpu-qom.h
new file mode 100644
index 000..cf107c9
--- /dev/null
+++ b/target-arm/cpu-qom.h
@@ -0,0 +1,70 @@
+/*
+ * QEMU ARM CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * 
+ */
+#ifndef QEMU_ARM_CPU_QOM_H
+#define QEMU_ARM_CPU_QOM_H
+
+#include "qemu/cpu.h"
+#include "cpu.h"
+
+#define TYPE_ARM_CPU "arm-cpu"
+
+#define ARM_CPU_CLASS(klass) \
+OBJECT_CLASS_CHECK(ARMCPUClass, (klass), TYPE_ARM_CPU)
+#define ARM_CPU(obj) \
+OBJECT_CHECK(ARMCPU, (obj), TYPE_ARM_CPU)
+#define ARM_CPU_GET_CLASS(obj) \
+OBJECT_GET_CLASS(ARMCPUClass, (obj), TYPE_ARM_CPU)
+
+/**
+ * ARMCPUClass:
+ *
+ * An ARM CPU model.
+ */
+typedef struct ARMCPUClass {
+/*< private >*/
+CPUClass parent_class;
+/*< public >*/
+
+void (*parent_reset)(CPUState *cpu);
+} ARMCPUClass;
+
+/**
+ * ARMCPU:
+ * @env: #CPUARMState
+ *
+ * An ARM CPU core.
+ */
+typedef struct ARMCPU {
+/*< private >*/
+CPUState parent_obj;
+/*< public >*/
+
+CPUARMState env;
+} ARMCPU;
+
+static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
+{
+return ARM_CPU(container_of(env, ARMCPU, env));
+}
+
+#define ENV_GET_CPU(e) CPU(arm_env_get_cpu(e))
+
+
+#endif
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
new file mode 100644
index 000..dda6b09
--- /dev/null
+++ b/target-arm/cpu.c
@@ -0,0 +1,59 @@
+/*
+ * QEMU ARM CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * 
+ */
+
+#include "cpu-qom.h"
+#include "qemu-common.h"
+
+static void arm_cpu_reset(CPUState *c)
+{
+ARMCPU *cpu = ARM_CPU(c);
+ARMCPUClass *class = ARM_CPU_GET_CLASS(cpu);
+
+class->parent_reset(c);
+
+/* TODO Drop this in favor of cpu_arm_reset() calling cpu_reset()
+ *  once cpu_reset_model_id() is gone. */
+cpu_state_reset(&cpu->env);
+}
+
+static void arm_cpu_class_init(ObjectClass *c, void *data)
+{
+ARMCPUClass *class = ARM_CPU_CLASS(c);
+CPUClass *cpu_class = CPU_CLASS(class);
+
+class->parent_reset = cpu_class->reset;
+cpu_class->reset = arm_cpu_reset;
+}
+
+static const TypeInfo arm_cpu_type_info = {
+.name = TYPE_ARM_CPU,
+.parent = TYPE_CPU,
+.instance_size = sizeof(ARMCPU),
+.abstract = false, /* TODO Reconsider once cp15 reworked. */
+.class_size = sizeof(ARMCPUClass),
+.class_init = arm_cpu_class_init,
+};
+
+static void arm_cpu_register_types(void)
+{
+type_register_static(&arm_cpu_type_info);
+}
+
+type_init(arm_cpu_register_types)
diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 69ef142..a68df61 100644
--

[Qemu-devel] [PATCH v6 1/2] target-arm: Drop cpu_arm_close()

[Andreas Färber]

It's unused, so no need to QOM'ify it later.

Signed-off-by: Andreas Färber 
Reviewed-by: Peter Maydell 
---
 target-arm/cpu.h|1 -
 target-arm/helper.c |5 -
 2 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index 26c114b..69ef142 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -238,7 +238,6 @@ typedef struct CPUARMState {
 CPUARMState *cpu_arm_init(const char *cpu_model);
 void arm_translate_init(void);
 int cpu_arm_exec(CPUARMState *s);
-void cpu_arm_close(CPUARMState *s);
 void do_interrupt(CPUARMState *);
 void switch_mode(CPUARMState *, int);
 uint32_t do_arm_semihosting(CPUARMState *env);
diff --git a/target-arm/helper.c b/target-arm/helper.c
index 1314f23..1ce8105 100644
--- a/target-arm/helper.c
+++ b/target-arm/helper.c
@@ -493,11 +493,6 @@ static uint32_t cpu_arm_find_by_name(const char *name)
 return id;
 }
 
-void cpu_arm_close(CPUARMState *env)
-{
-g_free(env);
-}
-
 static int bad_mode_switch(CPUARMState *env, int mode)
 {
 /* Return true if it is not valid for us to switch to
-- 
1.7.7

[Qemu-devel] [PATCH v6 0/2] QOM'ify ARM CPU

[Andreas Färber]

Hello Peter,

Here's the revised mini-conversion with CPUState::reset supported again.

Please apply to target-arm.next tree.

Available at:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-arm.v6

Regards,
Andreas

Cc: Anthony Liguori 
Cc: Peter Maydell 
Cc: Paul Brook 
Cc: Andrzej Zaborowski 

v5 -> v6:
* By dropping some of the patches in the series, cpu_reset() would no longer
  reset the CPUARMState. Fix this by re-adding a reset handler and calling
  cpu_state_reset() for now.

v4 -> v5:
* Use only one non-abstract CPU type for now, leave everything else as is.
* Drop cpu_arm_close() instead of converting it.
* Still make available cpu-qom.h through cpu.h for convenience.

v3 -> v4:
* Rebased on top of type_init() v2, object_class_get_list() v2, qom-cpu v4.

* Rename cpu-core.h to cpu-qom.h. While the term "ARM core" is quite common,
  it is less so for other architectures like s390x so use a neutral term.
* Use container_of() for CPUState -> CPU macros (suggested by Anthony).
* Rework arm_env_get_object() -> arm_env_get_cpu(), avoids some casts
  (suggested by Anthony). Also rename ENV_GET_OBJECT() -> ENV_GET_CPU().
* Sort -cpu ? list.
* Use object_class_get_list() and sort ourselves rather than using
  object_class_foreach_ordered() with callbacks (suggested by Anthony).
* Drop ARMCPUClass jtag_id since it turned out unneeded in QEMU (Peter+Andrzej).

* Drop experimental "halted" property since that should be in common code.
* Introduce "cpuid-variant" and "cpuid-revision" properties.
* Use CPU properties to drop unneeded pxa270-* classes.
* Move "/cpu" child property to integratorcp machine.

v2 -> v3:
* Rebased against qom-upstream.14 branch (and that against master).

* Rename target-arm/cpu-core.c to cpu.c now that we no longer need VPATH.
* Leave cpu-core.h as is to separate from legacy cpu.h.
* Fix -cpu alias "pxa270": handled in cpu_arm_init().
* Use proper GPL headers.

* Start removing CPUID uses in cpu_reset_model_id() and cpu.h.
* Fully convert cpu_reset_model_id() to ARMCPUInfo or per-model code.

* Experiment with adding properties ("halted").
* For testing, add a "/cpu" child property (HACK).

v1 -> v2:

* Cherry-pick Anthony's object_class_foreach() patch.

* Fix ARMCPUClass type name (arm-cpu-core -> arm-cpu).
* Add documentation.
* Rename ARMCPUDef to ARMCPUInfo.
* Use a C99-style table for initializing the classes through class_data
  instead of individual class_init functions (suggested by Anthony).
* Prepare reset callback.

* Make ENV_GET_OBJECT() use an inline function for readability.
* Invoke the CPU's reset method from cpu_reset().

* Do feature initialization via table where sensible.
* Add feature flags to ARMCPU as well (suggested by PMM for future tweaking,
  also simplifies load/save a bit) and initialize them from ARMCPUClass.
* Make feature inference work for ARMCPU as well by not passing the ARMCPUClass.
  Use function-local macros to avoid the ugliness of deferencing the features 
pointer.

Andreas Färber (2):
  target-arm: Drop cpu_arm_close()
  target-arm: Minimalistic CPU QOM'ification

 Makefile.target  |1 +
 target-arm/cpu-qom.h |   70 ++
 target-arm/cpu.c |   59 ++
 target-arm/cpu.h |2 +-
 target-arm/helper.c  |9 ++
 5 files changed, 134 insertions(+), 7 deletions(-)
 create mode 100644 target-arm/cpu-qom.h
 create mode 100644 target-arm/cpu.c

-- 
1.7.7

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Anthony Liguori]

On 03/25/2012 09:06 PM, Wanpeng Li wrote:

From: Anthony Liguori


This series aggressively refactors the PC machine initialization to be more
modelled and less ad-hoc.  The highlights of this series are:

  1) Things like -m and -bios-name are now device model properties

  2) The i440fx and piix3 are now modelled in a thorough fashion

  3) Most of the chipset features of the piix3 are modelled through composition

  4) i440fx_init is trivialized to creating devices and setting properties

  5) convert MemoryRegion to QOM

  6) convert PCI host bridge to QOM

The point (4) is the most important one.  As we refactor in this fashion,
we should quickly get to the point where machine->init disappears completely in
favor of just creating a handful of devices.

The two stage initialization of QOM is important here.  instance_init() is when
composed devices are created which means that after you've created a device, all
of its children are visible in the device model.  This lets you set properties
of the parent and its children.

realize() (which is still called DeviceState::init today) will be called right
before the guest starts up for the first time.

Signed-off-by: Anthony Liguori
Signed-off-by: Wanpeng Li


I should add that there's a short term focus on refactoring the i440fx in such a 
way that we can introduce a new chipset (Q35).


Regards,

Anthony Liguori



---
  Makefile.target |3 +-
  hw/hpet.c   |   39 +---
  hw/hpet_emul.h  |   41 +++
  hw/i440fx.c |  431 ++
  hw/i440fx.h |   78 +
  hw/i8254_internal.h |2 +-
  hw/mc146818rtc.c|   26 --
  hw/mc146818rtc.h|   29 ++
  hw/pc.c |  838 +--
  hw/pc.h |   46 +---
  hw/pc_piix.c|  762 --
  hw/pci_host.c   |   26 ++
  hw/pci_host.h   |5 +
  hw/piix3.c  |  274 +
  hw/piix3.h  |   79 +
  hw/piix_pci.c   |  600 
  memory.c|   94 +--
  memory.h|8 +
  18 files changed, 1795 insertions(+), 1586 deletions(-)
  create mode 100644 hw/i440fx.c
  create mode 100644 hw/i440fx.h
  delete mode 100644 hw/pc_piix.c
  create mode 100644 hw/piix3.c
  create mode 100644 hw/piix3.h
  delete mode 100644 hw/piix_pci.c
--

Re: [Qemu-devel] [PATCH] sh4-linux-user: fix multi-threading regression.

[Peter Maydell]

2012/3/26 Cédric VINCENT :
> This reverts commit fd4bab10 "target-sh4: optimize exceptions":

[cc'ing Aurelien as the author of that commit]

> the function cpu_restore_state() isn't expected to be called in user-mode,

Is this really true? host_signal_handler() calls cpu_signal_handler()
calls handle_cpu_signala) calls cpu_restore_state() so hopefully
it's OK to be called in at least *some* situations...

> as a consequence it isn't protected from race conditions.  For
> information, syscalls are exceptions on Linux/SH4.
>
> There were two possible fixes: either "tb_lock" is acquired/released
> around the call to cpu_restore_state() [1] or the commit that
> introduced this regression is reverted [2].

Can you explain a bit further what the race condition is that occurs
here?

NB the whole tb_lock thing is broken anyway.

thanks
-- PMM

Re: [Qemu-devel] [PATCH 09/15] tcg-sparc: Do not use a global register for AREG0.

[Blue Swirl]

On Mon, Mar 26, 2012 at 16:52, Richard Henderson  wrote:
> On 03/26/12 09:31, Blue Swirl wrote:
>>> > +/* In dyngen-exec.h, without AREG0, we fall back to an alias to 
>>> > cpu_single_env.
>>> > +   We can't actually tell from here whether that's needed or not, but it 
>>> > does
>>> > +   not hurt to go ahead and make the declaration.  */
>>> > +#ifndef CONFIG_TCG_PASS_AREG0
>>> > +extern
>>> > +#ifdef __linux__
>>> > +  __thread
>>> > +#endif
>>> > +  CPUArchState *env __attribute__((alias("tls__cpu_single_env")));
>>> > +#endif /* CONFIG_TCG_PASS_AREG0 */
>> Please use DECLARE_TLS/DEFINE_TLS and global env accesses should also
>> use tls_var().
>>
>
> That won't work.
>
> This is intended to be a drop-in replacement for the "env" symbol that
> we declare in dyngen-exec.h.  For all other hosts, this symbol is a
> global register variable.  We can't go wrapping tls_var around all uses
> in all target backends.
>
> As I say in the comment, the most natural replacement is a preprocessor
> macro, but then that fails with the uses of "env" in the DEF_HELPER_N
> macros.
>
> Which leaves no alternative -- short of converting *all* targets to
> CONFIG_TCG_PASS_AREG0 first -- except the symbol alias you see there.

But at that point there will be no global env use anymore, so
dyngen-exec.h etc. can be removed. Perhaps this patch and its
dependencies should wait for that to happen. As an intermediate hack
it's sort of OK.

> Hmm... actually... I'm wrong about the use of preprocessor macros.
> The simple solution there is to re-order the includes on a few ports.
> I.e. "helper.h" must come before "dyngen-exec.h".  Now that's a much
> simpler fix...

OK.

>
>
> r~

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Blue Swirl]

On Mon, Mar 26, 2012 at 12:20, Jan Kiszka  wrote:
> On 2012-03-26 04:06, Wanpeng Li wrote:
>> From: Anthony Liguori 
>>
>>
>> This series aggressively refactors the PC machine initialization to be more
>> modelled and less ad-hoc.  The highlights of this series are:
>>
>>  1) Things like -m and -bios-name are now device model properties
>>
>>  2) The i440fx and piix3 are now modelled in a thorough fashion
>>
>>  3) Most of the chipset features of the piix3 are modelled through 
>> composition
>>
>>  4) i440fx_init is trivialized to creating devices and setting properties
>>
>>  5) convert MemoryRegion to QOM
>>
>>  6) convert PCI host bridge to QOM
>>
>> The point (4) is the most important one.  As we refactor in this fashion,
>> we should quickly get to the point where machine->init disappears completely 
>> in
>> favor of just creating a handful of devices.
>>
>> The two stage initialization of QOM is important here.  instance_init() is 
>> when
>> composed devices are created which means that after you've created a device, 
>> all
>> of its children are visible in the device model.  This lets you set 
>> properties
>> of the parent and its children.
>>
>> realize() (which is still called DeviceState::init today) will be called 
>> right
>> before the guest starts up for the first time.
>
> While I see the value of the overall direction, I still disagree on
> making internal data structures of HPET, RTC and 8254 publicly
> available. That's a wrong step back. I'm sure there are smarter
> solutions, alse as there were some proposals back then in the original
> thread.

Fully agree. At least there should be something like this memory.c line:

/* All fields are private - violators will be prosecuted */

or other C++-ish comments about the fields being private to the class.
Device classes should not have friend classes except in exceptional
cases like LAPIC/RTC.

> I'm also sure we will have to refactor the merge significantly again for
> the introduction of additional chipsets and PC boards. But unless those
> requirements can already be specified (Isaku?), that might be unavoidable.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>

[Qemu-devel] [PATCH] fix evdev_keycode_to_pc_keycode for Hangul/Latin & Hangul/Hanja toggles

[Dohyung Hong]

Scan code for Hangul/English is 0xf2,

Scan code for Hangul/Hanja is 0xf1

 

Signed-off-by: Dohyung Hong 

---

diff --git a/ui/x_keymap.c b/ui/x_keymap.c

index b9b0944..5e1b796 100644

--- a/ui/x_keymap.c

+++ b/ui/x_keymap.c

@@ -127,8 +127,8 @@ static const uint8_t evdev_keycode_to_pc_keycode[61] = {

 0, /* 127 EVDEV - PAUS */

 0, /* 128 EVDEV -  */

 0, /* 129 EVDEV - I129 ("Internet" Keyboards) */

-0xf1,  /* 130 EVDEV - HNGL (Korean Hangul Latin toggle) */

-0xf2,  /* 131 EVDEV - HJCV (Korean Hangul Hanja toggle) */

+0xf2,  /* 130 EVDEV - HNGL (Korean Hangul Latin toggle) */

+0xf1,  /* 131 EVDEV - HJCV (Korean Hangul Hanja toggle) */

 0x7d,  /* 132 AE13 (Yen)*/

 0xdb,  /* 133 EVDEV - LWIN */

 0xdc,  /* 134 EVDEV - RWIN */

[Qemu-devel] PRoot: a new companion for QEMU user-mode

[cedric.vinc...@st.com]

Hello,

We are pleased to announce the first public release of PRoot, a tool
created to extend QEMU user-mode:

http://proot.me

As you probably know, QEMU user-mode is mainly used with binfmt_misc,
chroot, and sometimes "mount --bind".  PRoot basically brings a
user-space implementation of these three kernel features to QEMU
user-mode, without requiring any privilege or setup.  PRoot was
designed with simplicity and consistency in mind, thus we do hope it
should ease the adoption of QEMU user-mode.

PRoot+QEMU can typically be used to build, develop, test, and debug
embedded applications directly on users' PC.  One of my favorite
example is the cross-compilation and cross-validation of Perl (the
prompts were changed for readability purpose only):

$ proot -Q qemu-arm /path/to/any/arm-rootfs/

$ cd perl-5.14.2/
$ ./Configure -de
$ make
$ make check

As you can see no cross-compilation support was required.  You can
also run programs non-interactively and pass options to QEMU.  For
instance the following command runs "/usr/bin/perl" directly and
activates the QEMU GDB server:

$ proot -Q "qemu-arm -g 1234" /path/to/any/arm-rootfs/ 
/usr/bin/perl

PRoot can also mix automatically the execution of host programs and
the execution of guest programs emulated by QEMU user-mode.  It's a
convenient way to speed up build-time by using a cross-compiler
instead of emulating the guest compiler.  Even when mixing such
applications, build-systems still believe they are running in a native
guest environment, as a consequence most cross-compilation issues are
avoided by design.  For instance, with a typical "./configure" script
(many lines were removed for readability purpose):

$ proot -Q qemu-arm /path/to/any/arm-rootfs/

$ ./configure 
CC=/host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc
checking whether build environment is sane... yes
checking build system type... armv7l-unknown-linux-gnueabi
checking host system type... armv7l-unknown-linux-gnueabi
checking for gcc... /host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc
checking whether the C compiler works... yes
checking whether we are cross compiling... no

Note that the purpose of PRoot and ScratchBox2 looks similiar, however
they are different in their architecture and usage.  One of the main
differences being that PRoot is a single command that doesn't require
any setup nor cross-compilation tools.

If you have some questions and/or comments, we will be pleased to
answer you either in this thread if its related to QEMU user-mode, or
in PRoot mailing-list/forum otherwise:

http://proot.me/#help

Regards,
Cédric.

PS: sorry if you received this mail twice, it seems my first attempt
was discarded.

Re: [Qemu-devel] [PATCH 0/6] refactor PC machine, i440fx and piix3 to take advantage of QOM

[Blue Swirl]

On Mon, Mar 26, 2012 at 02:06, Wanpeng Li  wrote:
>
> From: Anthony Liguori 
>
>
> This series aggressively refactors the PC machine initialization to be more
> modelled and less ad-hoc.  The highlights of this series are:

Please fix coding style while moving.

>  1) Things like -m and -bios-name are now device model properties
>
>  2) The i440fx and piix3 are now modelled in a thorough fashion
>
>  3) Most of the chipset features of the piix3 are modelled through composition
>
>  4) i440fx_init is trivialized to creating devices and setting properties
>
>  5) convert MemoryRegion to QOM
>
>  6) convert PCI host bridge to QOM
>
> The point (4) is the most important one.  As we refactor in this fashion,
> we should quickly get to the point where machine->init disappears completely 
> in
> favor of just creating a handful of devices.
>
> The two stage initialization of QOM is important here.  instance_init() is 
> when
> composed devices are created which means that after you've created a device, 
> all
> of its children are visible in the device model.  This lets you set properties
> of the parent and its children.
>
> realize() (which is still called DeviceState::init today) will be called right
> before the guest starts up for the first time.
>
> Signed-off-by: Anthony Liguori 
> Signed-off-by: Wanpeng Li 
>
> ---
>  Makefile.target     |    3 +-
>  hw/hpet.c           |   39 +---
>  hw/hpet_emul.h      |   41 +++
>  hw/i440fx.c         |  431 ++
>  hw/i440fx.h         |   78 +
>  hw/i8254_internal.h |    2 +-
>  hw/mc146818rtc.c    |   26 --
>  hw/mc146818rtc.h    |   29 ++
>  hw/pc.c             |  838 
> +--
>  hw/pc.h             |   46 +---
>  hw/pc_piix.c        |  762 --
>  hw/pci_host.c       |   26 ++
>  hw/pci_host.h       |    5 +
>  hw/piix3.c          |  274 +
>  hw/piix3.h          |   79 +
>  hw/piix_pci.c       |  600 
>  memory.c            |   94 +--
>  memory.h            |    8 +
>  18 files changed, 1795 insertions(+), 1586 deletions(-)
>  create mode 100644 hw/i440fx.c
>  create mode 100644 hw/i440fx.h
>  delete mode 100644 hw/pc_piix.c
>  create mode 100644 hw/piix3.c
>  create mode 100644 hw/piix3.h
>  delete mode 100644 hw/piix_pci.c
> --
>
>

Re: [Qemu-devel] Build broken -- qemu-ga: add guest-network-get-interfaces command

[Blue Swirl]

On Mon, Mar 26, 2012 at 15:18, Anthony Liguori  wrote:
> On 03/26/2012 10:15 AM, Michael Roth wrote:
>>
>> On Mon, Mar 26, 2012 at 09:55:15AM -0500, Anthony Liguori wrote:
>>
>> Yup, I can't confirm the BSD fix atm though, only that it doesn't break
>> builds
>> on linux/w32. Send anyway or wait for confirmation?
>
>
> Brad/Michal,
>
> Can you confirm the fix?

Fixes build.

Tested-by:  Blue Swirl 

> Regards,
>
> Anthony Liguori
>
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>

>
> Michal
>

>>>
>
>

Re: [Qemu-devel] [PATCH v2 0/6] ARM: AREG0 conversion

[Blue Swirl]

On Mon, Mar 26, 2012 at 13:05, Paul Brook  wrote:
>> On 24 March 2012 18:58, Blue Swirl  wrote:
>> > v2: fix patch 1, tweak patch 2 and rebase to master.
>> >
>> > URL     git://repo.or.cz/qemu/blueswirl.git
>> >        http://repo.or.cz/r/qemu/blueswirl.git
>> >
>> > Blue Swirl (6):
>> >  arm: move neon_tbl to neon_helper.c
>> >  arm: move saturating arithmetic to helper.c
>> >  arm: move other arithmetic to helper.c
>> >  arm: move cpsr and banked register access to helper.c
>> >  arm: move exception and wfi helpers to helper.c
>> >  arm: move load and store helpers, switch to AREG0 free mode
>>
>> The patches themselves look OK, but do we really want to take
>> a 5% performance hit for this cleanup?
>
> I have a similar concern.  I'd like to at least have some idea where this
> slowdown is coming from.

At least stack protector is protecting more code than before (for
example TLB miss handler), but could overhead from that amount to 5%?

Otherwise there should be just a few extra register moves here and
there, that should be cheap on modern processors.

[Qemu-devel] PRoot: a new companion for QEMU user-mode

[cedric.vinc...@st.com]

Hello,

We are pleased to announce the first public release of PRoot, a tool
created to extend QEMU user-mode:

http://proot.me

As you probably know, QEMU user-mode is mainly used with binfmt_misc,
chroot, and sometimes "mount --bind".  PRoot basically brings a
user-space implementation of these three kernel features to QEMU
user-mode, without requiring any privilege or setup.  PRoot was
designed with simplicity and consistency in mind, thus we do hope it
should ease the adoption of QEMU user-mode.

PRoot+QEMU can typically be used to build, develop, test, and debug
embedded applications directly on users' PC.  One of my favorite
example is the cross-compilation and cross-validation of Perl (the
prompts were changed for readability purpose only):

$ proot -Q qemu-arm /path/to/any/arm-rootfs/

$ cd perl-5.14.2/
$ ./Configure -de
$ make
$ make check

As you can see no cross-compilation support was required.  You can
also run programs non-interactively and pass options to QEMU.  For
instance the following command runs "/usr/bin/perl" directly and
activates the QEMU GDB server:

$ proot -Q "qemu-arm -g 1234" /path/to/any/arm-rootfs/ 
/usr/bin/perl

PRoot can also mix automatically the execution of host programs and
the execution of guest programs emulated by QEMU user-mode.  It's a
convenient way to speed up build-time by using a cross-compiler
instead of emulating the guest compiler.  Even when mixing such
applications, build-systems still believe they are running in a native
guest environment, as a consequence most cross-compilation issues are
avoided by design.  For instance, with a typical "./configure" script
(many lines were removed for readability purpose):

$ proot -Q qemu-arm /path/to/any/arm-rootfs/

$ ./configure 
CC=/host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc
checking whether build environment is sane... yes
checking build system type... armv7l-unknown-linux-gnueabi
checking host system type... armv7l-unknown-linux-gnueabi
checking for gcc... /host-rootfs/opt/devkit/armv7/bin/armv7-linux-gcc
checking whether the C compiler works... yes
checking whether we are cross compiling... no

Note that the purpose of PRoot and ScratchBox2 looks similiar, however
they are different in their architecture and usage.  One of the main
differences being that PRoot is a single command that doesn't require
any setup nor cross-compilation tools.

If you have some questions and/or comments, we will be pleased to
answer you either in this thread if its related to QEMU user-mode, or
in PRoot mailing-list/forum otherwise:

http://proot.me/#help

Regards,
Cédric.

[Qemu-devel] [Bug 237164] Re: kvm needs to correctly simulate a proper monitor

[Michal Suchanek]

Isn't the issue here that the emulated card has too low video memory
forcing 800x600 when the driver selects the default 24bpp depth?

This is an issue with some very old real hardware too.

I guess X could account for that but due to its architecture every
driver would likely have a separate check for this condition (S3,
cirrus, and any other driver that could be possibly used with such low-
mem card).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/237164

Title:
  kvm needs to correctly simulate a proper monitor

Status in QEMU:
  Triaged
Status in “kvm” package in Ubuntu:
  Won't Fix
Status in “xorg” package in Ubuntu:
  Invalid

Bug description:
  Binary package hint: xorg

  With xserver-xor-video-cirrus 1.2.1, there should be no need to require 
special handling for kvm in dexconf any longer.
  See also: bug 193323.

  If kvm would properly simulate an attached monitor, we could drop the
  dexconf quirks. they are currently forcing the driver to use a
  1024x768 display where the driver could autodetect the monitor
  correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/237164/+subscriptions

Re: [Qemu-devel] [PATCH 09/15] tcg-sparc: Do not use a global register for AREG0.

[Richard Henderson]

On 03/26/12 09:31, Blue Swirl wrote:
>> > +/* In dyngen-exec.h, without AREG0, we fall back to an alias to 
>> > cpu_single_env.
>> > +   We can't actually tell from here whether that's needed or not, but it 
>> > does
>> > +   not hurt to go ahead and make the declaration.  */
>> > +#ifndef CONFIG_TCG_PASS_AREG0
>> > +extern
>> > +#ifdef __linux__
>> > +  __thread
>> > +#endif
>> > +  CPUArchState *env __attribute__((alias("tls__cpu_single_env")));
>> > +#endif /* CONFIG_TCG_PASS_AREG0 */
> Please use DECLARE_TLS/DEFINE_TLS and global env accesses should also
> use tls_var().
> 

That won't work.

This is intended to be a drop-in replacement for the "env" symbol that
we declare in dyngen-exec.h.  For all other hosts, this symbol is a
global register variable.  We can't go wrapping tls_var around all uses
in all target backends.

As I say in the comment, the most natural replacement is a preprocessor
macro, but then that fails with the uses of "env" in the DEF_HELPER_N
macros.

Which leaves no alternative -- short of converting *all* targets to
CONFIG_TCG_PASS_AREG0 first -- except the symbol alias you see there.

Hmm... actually... I'm wrong about the use of preprocessor macros.
The simple solution there is to re-order the includes on a few ports.
I.e. "helper.h" must come before "dyngen-exec.h".  Now that's a much
simpler fix...


r~

[Qemu-devel] [Bug 614958] Re: copy-paste between client and host

[Michal Suchanek]

I use serial console to cut&paste between host and guest without
networking.

It's nice SPICE is addressing this but I agree this is not really
something qemu itself should do. There is no  hardware cut&paste device
qemu can emulate, the video hardware has not notion of cut&paste.

At the very least qemu could support paste but since the SDL interface
has no controls and is direct input to the virtual machine there would
be need for different interface with more features.

You can copy screenshots. To support true clipboard copy you need in-
client software for every OS you run. While a nice project, and nice
thing to point people to in qemu docs (if it exists) it is definitely
out of the scope of qemu - a hardware emulator. Note that for SPICE
cut&paste to work you will surely need some SPICE driver installed in
the guest, and few platforms are supported.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/614958

Title:
  copy-paste between client and host

Status in QEMU:
  New

Bug description:
  Hi,

  I propose that copy/paste between VMs be implemented somehow directly in QEMU.
  This has been discussed repeatedly elsewhere; various solutions are proposed. 
 See below.

  As it is, each user has to do their own research and testing if they
  are to find a solution.   This makes the product frustratingly
  unattractive for many.

  Most solutions involve either running vnc and using a vnc client that
  supports copy/paste (this can be tricky to find itself), or running
  some other tcp-based copy-paste application.

  For many users, the networking in a client VM is unimportant--they
  just want to run some application there, and setting up netoworking in
  a VM itself can be an issue.  Most of these solutions rely on un-
  maintained software, and some require that other software be installed
  to make them work (Basic interpreter, Java, etc).  Any of these
  solutions take some work to set up.

  I can tell you, the absence of a copy/paste mechanism makes the
  project an immediate no-go for many users.  I work with a guy who
  spent a lot of time trying, gave up, and switched to VirtualBox for
  this exact reason.

  It would be much better if copy/paste worked out of the box.  Ideally,
  it should work independently of networking.

  Cheers!

  Some discussions and proposed solutions:
  -
  http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=161
  Somebody suggests VNC into the virtual host, and use vncviewer
  Somebody else suggests TCP/IP Clipboard (text editor with tcp/ip)

  http://qemu-forum.ipi.fi/viewtopic.php?f=4&t=2626
  primitive app for sharing text across machines (in Basic)
  http://homepage.mac.com/bnej/shareclip/

  http://borderworlds.dk/blog/20070217-00.html
  Says doesn't know a good solution but points to unmaintained package
  Qemu Guest Tools
  http://wolfpackally.wo.funpic.de/qemu/qgt/

  http://bonzoli.com/docs/How_to_setup_Qemu_on_Fedora_8.html
  proposes Java remoteclip running on client and server
  http://www.cs.cmu.edu/afs/cs/user/rcm/WWW/RemoteClip/

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/614958/+subscriptions

[Qemu-devel] [PATCH] fix usb hid usage id table

[홍도형]

Add(or fix) following key conversions

-   0x3a -> 0x39 : CapsLock 

-   0x56 -> 0x64 : Europe 2

-   0x59 -> 0x67 : Keypad =

-   0x5c -> 0x8c : Keyboard Int’l 6(PC9800 Keypad)

-   0x64 -> 0x68 : F13

-   0x65 -> 0x69 : F14

-   0x66 -> 0x6a : F15

-   0x67 -> 0x6b : F16

-   0x68 -> 0x6c : F17

-   0x69 -> 0x6d : F18

-   0x6a -> 0x6e : F19

-   0x6b -> 0x6f : F20

-   0x6c -> 0x70 : F21

-   0x6d -> 0x71 : F22

-   0x6e -> 0x72 : F23

-   0x70 -> 0x88 : Keyboard Int’l 2(Katakana/Hiragana)

-   0x73 -> 0x87 : Keyboard Int’l 1

-   0x76 -> 0x73 : F24(or 0x76 -> 0x94 : Keyboard Int’l 5)

-   0x77 -> 0x93 : Keyboard Lang 4 (Hiragana)

-   0x78 -> 0x92 : Keyboard Lang 3 (Katakana)

-   0x79 -> 0x8a : Keyboard Int’l 4

-   0x7b -> 0x8b : Keyboard Int’l 5

-   0x7d -> 0x89 : Keyboard Int’l 2(Yen)

-   0x7e -> 0x85 : Keypad , (Brazilian Keypad .)

-   0xc6 -> 0x48 : Break(Ctl-Pause)

-   0xde -> 0x66 : Keyboard Power

-   0xf1 -> 0x91 : Keyboard Lang 2 (Hanja)

-   0xf2 -> 0x90 : Keyboard Lang 1 (Hanguel/English)

-   0xfc -> 0x02 : POST Fail

-   0xff -> 0x01 : Overrun Error

 

Signed-off-by : Dohyung Hong 

---

diff --git a/hw/hid.c b/hw/hid.c

index 03761ab..d3a0f65 100644

--- a/hw/hid.c

+++ b/hw/hid.c

@@ -41,15 +41,15 @@ static const uint8_t hid_usage_keys[0x100] = {

 0x07, 0x09, 0x0a, 0x0b, 0x0d, 0x0e, 0x0f, 0x33,

 0x34, 0x35, 0xe1, 0x31, 0x1d, 0x1b, 0x06, 0x19,

 0x05, 0x11, 0x10, 0x36, 0x37, 0x38, 0xe5, 0x55,

-0xe2, 0x2c, 0x32, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e,

+0xe2, 0x2c, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e,

 0x3f, 0x40, 0x41, 0x42, 0x43, 0x53, 0x47, 0x5f,

 0x60, 0x61, 0x56, 0x5c, 0x5d, 0x5e, 0x57, 0x59,

-0x5a, 0x5b, 0x62, 0x63, 0x00, 0x00, 0x00, 0x44,

-0x45, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e,

-0xe8, 0xe9, 0x71, 0x72, 0x73, 0x00, 0x00, 0x00,

-0x00, 0x00, 0x00, 0x85, 0x00, 0x00, 0x00, 0x00,

-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

-0x00, 0x00, 0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65,

+0x5a, 0x5b, 0x62, 0x63, 0x00, 0x64, 0x00, 0x44,

+0x45, 0x67, 0x00, 0x00, 0x8c, 0x00, 0x00, 0x00,

+0xe8, 0xe9, 0x00, 0x00, 0x68, 0x69, 0x6a, 0x6b,

+0x6c, 0x6d, 0x6e, 0x6f, 0x70, 0x71, 0x72, 0x00,

+0x88, 0x00, 0x00, 0x87, 0x00, 0x00, 0x73, 0x93,

+0x92, 0x8a, 0x00, 0x8b, 0x00, 0x89, 0x85, 0x00,

 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

@@ -59,14 +59,14 @@ static const uint8_t hid_usage_keys[0x100] = {

 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

 0x00, 0x00, 0x00, 0x00, 0x00, 0x54, 0x00, 0x46,

 0xe6, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

-0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00, 0x4a,

+0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x48, 0x4a,

 0x52, 0x4b, 0x00, 0x50, 0x00, 0x4f, 0x00, 0x4d,

 0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00,

-0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00,

-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

-0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

+0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x66, 0x00,

 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

+0x00, 0x91, 0x90, 0x00, 0x00, 0x00, 0x00, 0x00,

+0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x00, 0x01,

};

 bool hid_has_events(HIDState *hs)

---

Re: [Qemu-devel] [PATCH 13/15] tcg-sparc: Use defines for temporaries.

[Blue Swirl]

On Sun, Mar 25, 2012 at 22:27, Richard Henderson  wrote:
> And change from %i4 to %g1 to remove a v8plus fixme.
>
> Signed-off-by: Richard Henderson 
> ---
>  tcg/sparc/tcg-target.c |  110 ---
>  1 files changed, 56 insertions(+), 54 deletions(-)
>
> diff --git a/tcg/sparc/tcg-target.c b/tcg/sparc/tcg-target.c
> index 181ba26..896fab1 100644
> --- a/tcg/sparc/tcg-target.c
> +++ b/tcg/sparc/tcg-target.c
> @@ -59,8 +59,11 @@ static const char * const 
> tcg_target_reg_names[TCG_TARGET_NB_REGS] = {
>  };
>  #endif
>
> +#define TCG_REG_TMP  TCG_REG_G1
> +#define TCG_REG_TMP2 TCG_REG_I5
> +
>  #ifdef CONFIG_USE_GUEST_BASE
> -# define TCG_GUEST_BASE_REG TCG_REG_I3
> +# define TCG_GUEST_BASE_REG TCG_REG_I4
>  #else
>  # define TCG_GUEST_BASE_REG TCG_REG_G0
>  #endif
> @@ -372,10 +375,10 @@ static inline void tcg_out_movi(TCGContext *s, TCGType 
> type,
>         tcg_out_sethi(s, ret, ~arg);
>         tcg_out_arithi(s, ret, ret, (arg & 0x3ff) | -0x400, ARITH_XOR);
>     } else {
> -        tcg_out_movi_imm32(s, TCG_REG_I4, arg >> (TCG_TARGET_REG_BITS / 2));
> -        tcg_out_arithi(s, TCG_REG_I4, TCG_REG_I4, 32, SHIFT_SLLX);
> -        tcg_out_movi_imm32(s, ret, arg);
> -        tcg_out_arith(s, ret, ret, TCG_REG_I4, ARITH_OR);
> +        tcg_out_movi_imm32(s, ret, arg >> (TCG_TARGET_REG_BITS / 2));
> +        tcg_out_arithi(s, ret, ret, 32, SHIFT_SLLX);
> +        tcg_out_movi_imm32(s, TCG_REG_TMP2, arg);
> +        tcg_out_arith(s, ret, ret, TCG_REG_TMP2, ARITH_OR);
>     }
>  }
>
> @@ -392,8 +395,8 @@ static inline void tcg_out_ldst(TCGContext *s, int ret, 
> int addr,
>         tcg_out32(s, op | INSN_RD(ret) | INSN_RS1(addr) |
>                   INSN_IMM13(offset));
>     } else {
> -        tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_I5, offset);
> -        tcg_out_ldst_rr(s, ret, addr, TCG_REG_I5, op);
> +        tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_TMP, offset);
> +        tcg_out_ldst_rr(s, ret, addr, TCG_REG_TMP, op);
>     }
>  }
>
> @@ -435,8 +438,8 @@ static inline void tcg_out_addi(TCGContext *s, int reg, 
> tcg_target_long val)
>         if (check_fit_tl(val, 13))
>             tcg_out_arithi(s, reg, reg, val, ARITH_ADD);
>         else {
> -            tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_I5, val);
> -            tcg_out_arith(s, reg, reg, TCG_REG_I5, ARITH_ADD);
> +            tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_TMP, val);
> +            tcg_out_arith(s, reg, reg, TCG_REG_TMP, ARITH_ADD);
>         }
>     }
>  }
> @@ -448,8 +451,8 @@ static inline void tcg_out_andi(TCGContext *s, int rd, 
> int rs,
>         if (check_fit_tl(val, 13))
>             tcg_out_arithi(s, rd, rs, val, ARITH_AND);
>         else {
> -            tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_I5, val);
> -            tcg_out_arith(s, rd, rs, TCG_REG_I5, ARITH_AND);
> +            tcg_out_movi(s, TCG_TYPE_I32, TCG_REG_TMP, val);
> +            tcg_out_arith(s, rd, rs, TCG_REG_TMP, ARITH_AND);
>         }
>     }
>  }
> @@ -461,8 +464,8 @@ static void tcg_out_div32(TCGContext *s, int rd, int rs1,
>     if (uns) {
>         tcg_out_sety(s, TCG_REG_G0);
>     } else {
> -        tcg_out_arithi(s, TCG_REG_I5, rs1, 31, SHIFT_SRA);
> -        tcg_out_sety(s, TCG_REG_I5);
> +        tcg_out_arithi(s, TCG_REG_TMP, rs1, 31, SHIFT_SRA);
> +        tcg_out_sety(s, TCG_REG_TMP);
>     }
>
>     tcg_out_arithc(s, rd, rs1, val2, val2const,
> @@ -608,8 +611,8 @@ static void tcg_out_setcond_i32(TCGContext *s, TCGCond 
> cond, TCGArg ret,
>     case TCG_COND_GTU:
>     case TCG_COND_GEU:
>         if (c2const && c2 != 0) {
> -            tcg_out_movi_imm13(s, TCG_REG_I5, c2);
> -            c2 = TCG_REG_I5;
> +            tcg_out_movi_imm13(s, TCG_REG_TMP, c2);
> +            c2 = TCG_REG_TMP;
>         }
>         t = c1, c1 = c2, c2 = t, c2const = 0;
>         cond = tcg_swap_cond(cond);
> @@ -656,15 +659,15 @@ static void tcg_out_setcond2_i32(TCGContext *s, TCGCond 
> cond, TCGArg ret,
>
>     switch (cond) {
>     case TCG_COND_EQ:
> -        tcg_out_setcond_i32(s, TCG_COND_EQ, TCG_REG_I5, al, bl, blconst);
> +        tcg_out_setcond_i32(s, TCG_COND_EQ, TCG_REG_TMP, al, bl, blconst);
>         tcg_out_setcond_i32(s, TCG_COND_EQ, ret, ah, bh, bhconst);
> -        tcg_out_arith(s, ret, ret, TCG_REG_I5, ARITH_AND);
> +        tcg_out_arith(s, ret, ret, TCG_REG_TMP, ARITH_AND);
>         break;
>
>     case TCG_COND_NE:
> -        tcg_out_setcond_i32(s, TCG_COND_NE, TCG_REG_I5, al, al, blconst);
> +        tcg_out_setcond_i32(s, TCG_COND_NE, TCG_REG_TMP, al, al, blconst);
>         tcg_out_setcond_i32(s, TCG_COND_NE, ret, ah, bh, bhconst);
> -        tcg_out_arith(s, ret, ret, TCG_REG_I5, ARITH_OR);
> +        tcg_out_arith(s, ret, ret, TCG_REG_TMP, ARITH_OR);
>         break;
>
>     default:
> @@ -964,8 +967,8 @@ static void tcg_out_qemu_ld(TCGContext *s, const TCGArg 
> *args, int sizeop)
>  #else
>     addr_reg = args[addrlo_idx];
>     if (TCG_TARGET_REG_BITS == 64 && TARGET_LONG_BITS == 32) {
> -   

[Qemu-devel] [Bug 965133] [NEW] Sparc64 crash on start

[Tiziano Vecchi]

Public bug reported:

qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64
architecture.

With more than 4G of memory sparc64 machine crash on start.

command line: qemu-system-sparc64 -m 4G

output:
VNC server running on `127.0.0.1:5900'
qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state
pc: ffd04c80  npc: ffd04c84
General Registers:
%g0-3:    
%g4-7:    

Current Register Window:
%o0-3: ffd0 0008 0008  
%o4-7:   fff754e1 ffd144d4 
%l0-3: 0001 fff75c4d   
%l4-7:     
%i0-3:   0001 0036 
%i4-7: ffe87418 ffe87648 fff75591 ffd0bf54 

Floating Point Registers:
%f00:    
%f08:    
%f16:    
%f24:    
%f32:    
%f40:    
%f48:    
%f56:    
pstate: 0414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0
cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3
fsr:  y:  fprs: 
Aborted (core dumped)

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/965133

Title:
  Sparc64 crash on start

Status in QEMU:
  New

Bug description:
  qemu version 1.0.1 compiled on a Ubuntu live on a HP laptop win a x64
  architecture.

  With more than 4G of memory sparc64 machine crash on start.

  command line: qemu-system-sparc64 -m 4G

  output:
  VNC server running on `127.0.0.1:5900'
  qemu: fatal: Trap 0x0064 while trap level (5) >= MAXTL (5), Error state
  pc: ffd04c80  npc: ffd04c84
  General Registers:
  %g0-3:    
  %g4-7:    

  Current Register Window:
  %o0-3: ffd0 0008 0008  
  %o4-7:   fff754e1 ffd144d4 
  %l0-3: 0001 fff75c4d   
  %l4-7:     
  %i0-3:   0001 0036 
  %i4-7: ffe87418 ffe87648 fff75591 ffd0bf54 

  Floating Point Registers:
  %f00:    
  %f08:    
  %f16:    
  %f24:    
  %f32:    
  %f40:    
  %f48:    
  %f56:    
  pstate: 0414 ccr: 99 (icc: N--C xcc: N--C) asi: 00 tl: 5 pil: 0
  cansave: 5 canrestore: 1 otherwin: 0 wstate: 0 cleanwin: 6 cwp: 3
  fsr:  y:  fprs: 
  Aborted (core dumped)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/965133/+subscriptions

Re: [Qemu-devel] [PATCH] qemu-ga: Make guest-network-get-interfaces Linux only

[Andreas Färber]

Am 20.03.2012 17:10, schrieb Michael Roth:
> On Tue, Mar 20, 2012 at 04:09:53PM +0100, Michal Privoznik wrote:
>> Currently, the implementation of that command is full of
>> Linux specific code. Before any brave man will step into
>> and port it to other OSes, make this function Linux only.
>>
>> Signed-off-by: Michal Privoznik 
> 
> Which aspect is linux-specific? getifaddrs() and getnameinfo() seem to
> be available on BSD and OpenSolaris, and we're already stubbed for w32.
> Are you seeing breakage?

The two OpenBSD buildbots were reporting breakages:

http://buildbot.b1-systems.de/qemu/buildslaves/brad_openbsd_current
http://buildbot.b1-systems.de/qemu/buildslaves/kraxel_openbsd49

Unfortunately they rarely nag the people to blame ;) and the reports on
qemu-devel are admittedly a bit brief.

Maybe it might make sense to let the buildbots build your qemu-ga
staging branch as well, Michael? That could catch this in advance.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH 09/15] tcg-sparc: Do not use a global register for AREG0.

[Blue Swirl]

On Sun, Mar 25, 2012 at 22:27, Richard Henderson  wrote:
>
> Signed-off-by: Richard Henderson 
> ---
>  dyngen-exec.h |   20 +++-
>  exec.c        |   16 ++--
>  2 files changed, 25 insertions(+), 11 deletions(-)
>
> diff --git a/dyngen-exec.h b/dyngen-exec.h
> index 65fcb43..d673f9f 100644
> --- a/dyngen-exec.h
> +++ b/dyngen-exec.h
> @@ -41,13 +41,8 @@
>  #elif defined(__mips__)
>  #define AREG0 "s0"
>  #elif defined(__sparc__)
> -#ifdef CONFIG_SOLARIS
> -#define AREG0 "g2"
> -#elif HOST_LONG_BITS == 64
> -#define AREG0 "g5"
> -#else
> -#define AREG0 "g6"
> -#endif
> +/* Don't use a global register.  Working around glibc clobbering these
> +   global registers is more trouble than just using TLS.  */
>  #elif defined(__s390__)
>  #define AREG0 "r10"
>  #elif defined(__alpha__)
> @@ -62,12 +57,19 @@
>  #error unsupported CPU
>  #endif
>
> -#if defined(AREG0)
> +#ifdef AREG0
>  register CPUArchState *env asm(AREG0);
>  #else
> -/* TODO: Try env = cpu_single_env. */
> +/* It's tempting to #define env cpu_single_cpu, but that runs afoul of
> +   the other macro usage in target-foo/helper.h.  Instead use an alias.
> +   That has to happen where cpu_single_cpu is defined, so just a
> +   declaration here.  */
> +#ifdef __linux__
> +extern __thread CPUArchState *env;
> +#else
>  extern CPUArchState *env;
>  #endif
> +#endif /* AREG0 */
>
>  #endif /* !CONFIG_TCG_PASS_AREG0 */
>  #endif /* !defined(__DYNGEN_EXEC_H__) */
> diff --git a/exec.c b/exec.c
> index 6731ab8..d84caa5 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -124,9 +124,21 @@ static MemoryRegion io_mem_subpage_ram;
>  #endif
>
>  CPUArchState *first_cpu;
> -/* current CPU in the current thread. It is only valid inside
> -   cpu_exec() */
> +
> +/* Current CPU in the current thread. It is only valid inside cpu_exec().  */
>  DEFINE_TLS(CPUArchState *,cpu_single_env);
> +
> +/* In dyngen-exec.h, without AREG0, we fall back to an alias to 
> cpu_single_env.
> +   We can't actually tell from here whether that's needed or not, but it does
> +   not hurt to go ahead and make the declaration.  */
> +#ifndef CONFIG_TCG_PASS_AREG0
> +extern
> +#ifdef __linux__
> +  __thread
> +#endif
> +  CPUArchState *env __attribute__((alias("tls__cpu_single_env")));
> +#endif /* CONFIG_TCG_PASS_AREG0 */

Please use DECLARE_TLS/DEFINE_TLS and global env accesses should also
use tls_var().

> +
>  /* 0 = Do not count executed instructions.
>    1 = Precise instruction counting.
>    2 = Adaptive rate instruction counting.  */
> --
> 1.7.7.6
>