[Qemu-devel] [PATCH v1 1/2] qom/object.c: Reset interface list on inheritance
The QOM framework will attempt the recreate a classes interface list from
scratch for each class. This means that a child class should zero out the
list of interfaces when cloned from the parent class.
Currently the list is memcpy()d from the parent to the child. As the interface
list is just a pointer to a list, this means the parent and child will share
the same list of interfaces. When the child inits, it will append its own
interfaces to the parents list. This is incorrect as the parent should not pick
up its childs interfaces.
This actually causes an infinite loop at class init time, as the child will
iterate through the parent interface list adding each itf to its own list(in
type_initialize()). As the list is (erroneously) shared, the new interface
instances for the child are appended to the parent, and the iterator never hits
the tail and loops forever.
Signed-off-by: Peter Crosthwaite
---
qom/object.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index 563e45b..4b72a64 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -245,6 +245,7 @@ static void type_initialize(TypeImpl *ti)
g_assert(parent->class_size <= ti->class_size);
memcpy(ti->class, parent->class, parent->class_size);
+ti->class->interfaces = NULL;
for (e = parent->class->interfaces; e; e = e->next) {
ObjectClass *iface = e->data;
--
1.7.0.4
[Qemu-devel] Email address change for Eric Johnson
My email address is changing from: er...@mips.com to eric.john...@imgtec.com I've already subscribed the new email address to the list. Emails to the previous address will forward to my new address for an unspecified amount of time. The MIPS Technologies website (http://www.mips.com) announces the acquisition by Imagination Technologies. Eric Johnson
[Qemu-devel] [PATCH v1 2/2] qom/object.c: Allow itf cast with num_itfs = 0
num_interfaces only tells you how many interfaces the concrete child class has
(as defined in the TypeInfo). This means if you have a child class which defines
no interfaces of its own, but its parent has interfaces you cannot cast to those
parent interfaces.
Fixed by removing the guard altogether.
Signed-off-by: Peter Crosthwaite
---
qom/object.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qom/object.c b/qom/object.c
index 4b72a64..da442be 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -449,7 +449,7 @@ ObjectClass *object_class_dynamic_cast(ObjectClass *class,
TypeImpl *type = class->type;
ObjectClass *ret = NULL;
-if (type->num_interfaces && type_is_ancestor(target_type, type_interface))
{
+if (type_is_ancestor(target_type, type_interface)) {
int found = 0;
GSList *i;
--
1.7.0.4
[Qemu-devel] [PATCH v1 0/2] QOM Interface Fixes
I recently tried to create a new QOM class which inherited from a class which defined interfaces. This has so far gone untested and my little experiment exposed two bugs in the QOM interface system. Please see patches for corrections. Im pretty convinced about patch 2, patch 1 less so and could use some input on what the original intention was on how inheritance and interfaces was supposed to be implemented. Peter Crosthwaite (2): qom/object.c: Reset interface list on inheritance qom/object.c: Allow itf cast with num_itfs = 0 qom/object.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
Re: [Qemu-devel] 绛�澶�: [RFC 19/19] target-unicore32: Refactor deb ug output macros
> Am 29.01.2013 10:23, schrieb Guan Xuetao: >>> -���浠跺��浠�- >>> ���浠朵��: Andreas F盲rber [mailto:afaer...@suse.de] >>> 堕��: Sunday, January 27, 2013 21:32 >>> ��朵欢浜�: qemu-devel@nongnu.org >>> ��: Andreas F盲rber; Guan Xuetao (maintainer:UniCore32) >>> 涓婚��: [RFC 19/19] target-unicore32: Refactor debug output macros >>> >>> Make debug output compile-testable even if disabled. >>> >>> Signed-off-by: Andreas F盲rber >> >> The patch could work, but I don't think it's a good idea. > > Yes, I agree. The plan for v2 is to use static inline functions and to > keep using #ifdef rather than #if. > >> Perhaps tracetools can be better. > > Tracepoints are not as flexible as they require a fixed set of up to > 6(?) arguments. But yes, if you were to replace these macros in > unicore32 code with specific tracepoints that would solve the issue at > hand as well and would even allow to enable/disable them at runtime. Tracepoints, or tracetools? As tracetools, it's unneccessary to have fixed 6 arguments. In my recent development on unicore64, all debug information is output by tracetools, and it's very convenient. I hope to reform unicore32 by this means. > > CC'ing some more people on this new input. Maybe there would be a common > subset of tracepoints? Anthony mentioned LOG_EXCP and LOG_DIS; would not > only the names but also the arguments be generalizable? I haven't learned about tracepoints and LOG_*. I will put it on my TODO list. Thanks, Xuetao > > Regards, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N眉rnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend枚rffer; HRB 16746 AG N眉rnberg >
[Qemu-devel] [PATCH] xilinx_axienet.c: Assert no error when making link
This gives an awful silent failure when it doesn't work. Assert against link
creation failure.
Signed-off-by: Peter Crosthwaite
---
hw/xilinx_axienet.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/hw/xilinx_axienet.c b/hw/xilinx_axienet.c
index 34e344c..e5d9251 100644
--- a/hw/xilinx_axienet.c
+++ b/hw/xilinx_axienet.c
@@ -869,9 +869,11 @@ static int xilinx_enet_init(SysBusDevice *dev)
static void xilinx_enet_initfn(Object *obj)
{
struct XilinxAXIEnet *s = FROM_SYSBUS(typeof(*s), SYS_BUS_DEVICE(obj));
+Error *errp = NULL;
object_property_add_link(obj, "axistream-connected", TYPE_STREAM_SLAVE,
- (Object **) &s->tx_dev, NULL);
+ (Object **) &s->tx_dev, &errp);
+assert_no_error(errp);
}
static Property xilinx_enet_properties[] = {
--
1.7.0.4
Re: [Qemu-devel] 绛�澶�: [PATCH qom-cpu for-1.4] targe t-unicore32: Rename CPU subtypes
> > As indicated above, this patch has a bug, sorry. I will send a v2. > Forking in linux-user will be broken (cpu_copy()), everything else > should work though, no? > > Can you please test qemu.git master and confirm that it is not broken > without this patch? > > I do not have any unicore32 image for testing. I therefore tested > "./unicore32-softmmu/qemu-system-unicore32 -cpu ?" (which did not seem > implemented) and "./unicore32-softmmu/qemu-system-unicore32" without > parameters, which ran into a kernel_filename assertion IIRC. > Can you upload a test image and static linux-user binaries somewhere? Or > provide me with instructions how to build a toolchain and kernel? Sorry for replying so late. Since it's chinese spring festival, I can't access my linux server recently. My suggestion is that you can apply your patches on unicore32 to qemu.git freely, and when I rebase my repo on qemu.git, I will review and adjust my codes. Happy Chinese New Year! Xuetao > > Thanks, > Andreas > > P.S. FYI a hw/uc32/ directory has been created in the meantime. If you > still wish to move your puv3 files out of hw/, please feel invited to > send a patch. > > -- > 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] Char flow control patches
On (Wed) 30 Jan 2013 [08:38:50], Anthony Liguori wrote: > Amit Shah writes: > > > Hi Anthony, > > > > I did some basic testing of the char flow control patches from your > > char-flow.2 branch. With the following patch applied, things seem to > > be working fine. I tested the isa-serial and virtio-serial devices. > > > > I haven't yet tested with virtio-serial flow control, but at least no > > regressions as of now. > > Awesome! Well -- just tested starting sockets in non-server mode, and that fails with: (process:922): GLib-CRITICAL **: g_io_channel_write_chars: assertion `channel != NULL' failed cmdline: ./x86_64-softmmu/qemu-system-x86_64 -m 512 /guests/f14-nolvm.qcow2 \ -snapshot -enable-kvm -chardev socket,path=/tmp/foo,id=foo \ -device virtio-serial -device virtserialport,chardev=foo,nr=2 \ -monitor stdio on the host, also start a listening process, like: $ socat UNIX-LISTEN:/tmp/foo - and doing 'echo foo > /dev/vport0p2' in the guest results in the error message above. Amit
Re: [Qemu-devel] [PATCH 3/4] This patch adds new qemu-img subcommand that compares content of two disk images.
- Original Message -
> From: "Eric Blake"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, kw...@redhat.com, pbonz...@redhat.com,
> stefa...@redhat.com
> Sent: Friday, February 8, 2013 8:19:45 PM
> Subject: Re: [PATCH 3/4] This patch adds new qemu-img subcommand that
> compares content of two disk images.
>
> On 02/08/2013 01:33 AM, Miroslav Rezanina wrote:
> > This patch adds new qemu-img subcommand that compares content of
> > two disk
> > images.
> >
>
> > +static int64_t sectors_to_process(int64_t total, int64_t from)
> > +{
> > +return MIN((total - from), (IO_BUF_SIZE >> BDRV_SECTOR_BITS));
>
> Why the spurious ()? This can be written:
>
> return MIN(total - from, IO_BUF_SIZE >> BDRV_SECTOR_BITS);
>
> unless the definition of MIN() is horribly busted (in which case, fix
> the broken macro, don't make callers suffer).
>
Just my habit - do not trust code you did not write (and not event the one you
wrote).
> > +/*
> > + * Compares two images. Exit codes:
> > + *
> > + * 0 - Images are identical
> > + * 1 - Images differ
> > + * <0 - Error occurred
> > + */
> > +static int img_compare(int argc, char **argv)
> > +{
> > +const char *fmt1 = NULL, *fmt2 = NULL, *filename1, *filename2;
> > +BlockDriverState *bs1, *bs2;
> > +int64_t total_sectors1, total_sectors2;
> > +uint8_t *buf1 = NULL, *buf2 = NULL;
> > +int pnum1, pnum2;
> > +int allocated1, allocated2;
> > +int ret = 0; /* return value - 0 Ident, 1 Different, 2 Error
> > */
>
> This comment disagrees with the comment at the top of the function.
> I
> would just delete the comment here, instead of trying to keep them in
> sync.
>
Yeah, I miss this one. Thx for pointing it out.
> > Commit the changes recorded in @var{filename} in its base image.
> >
> > +@item compare [-f @var{fmt}] [-F @var{fmt}] [-p] [-s] [-q]
> > @var{filename1} @var{filename2}
>
> While this line is okay long...
>
> > +
> > +Check if two images have the same content. You can compare images
> > with
> > +different format or settings.
> > +
> > +The format is probed unless you specify it by @var{-f} (used for
> > @var{filename1}) and/or @var{-F} (used for @var{filename2})
> > option.
>
> ...this line should be wrapped.
>
You're right..
> > +
> > +Compare exits with @code{0} in case the images are equal and with
> > @code{1}
> > +in case the images differ. Negative exit code means an error
> > occured during
>
> s/occured/occurred/
>
> There's no such thing as a negative exit in shell. Rather, you
> should
> document that an exit code > 1 indicates an error during execution.
>
Oh, I was not aware of this fact. Thanks for explaining, have to be fixed.
> > +execution and standard error output should contain an error
> > message.
> > +Error exit codes are:
> > +
> > +@table @option
> > +
> > +@item -1
> > +Error on opening an image
> > +@item -2
> > +Error on cheking a sector allorcation
>
> s/cheking/checking/
> s/allorcation/allocation/
>
> > +@item -3
> > +Error on reading data
>
> Does it make sense to be this fine-grained in exit reporting? I'd be
> okay with blindly using exit status 2 for all failures. But if you
> really do want to call out this many different statuses, I'd list a
> single table for ALL possible exits, rather than prose about success
> and
> table for failure, as in:
>
> 0 - images are identical
> 1 - images differ
> 2 - error opening an image
> 3 - error checking sector allocation
> 4 - error reading from an image
>
> Isn't failure to determine sector allocation a subset of failure to
> read
> from an image?
>
This table is describing behavior prior the last change. I forget
to update it so the values are not correct. However, allocation
checking error is (or should be) on bdrv_is_allocated_above call
and reading error is on bdrv_read. (Yeah, it can be problem with
reading but this is hidden in bdrv).
> --
> Eric Blake eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
--
Miroslav Rezanina
Software Engineer - Virtualization Team
Re: [Qemu-devel] [PATCH 2/4] qemu-img: Add "Quiet mode" option
Hi Eric,
- Original Message -
> From: "Eric Blake"
> To: "Miroslav Rezanina"
> Cc: qemu-devel@nongnu.org, kw...@redhat.com, pbonz...@redhat.com,
> stefa...@redhat.com
> Sent: Friday, February 8, 2013 6:07:35 PM
> Subject: Re: [PATCH 2/4] qemu-img: Add "Quiet mode" option
>
> On 02/08/2013 01:33 AM, Miroslav Rezanina wrote:
> > There can be a need to turn output to stdout off. This patch adds a
> > -q option
> > that enable "Quiet mode". In Quiet mode, only errors are printed
> > out.
> >
> > Signed-off-by: Miroslav Rezanina
> > ---
> >
> > if (result.bfi.total_clusters != 0 &&
> > result.bfi.allocated_clusters != 0) {
> > -printf("%" PRId64 "/%" PRId64 "= %0.2f%% allocated,
> > %0.2f%% fragmented\n",
> > +/* BEWARE: parameter list not indented due to long
> > expressions */
>
> This code is being touched in an independent patch, with a solution
> much
> nicer than adding a BEWARE comment:
> https://lists.gnu.org/archive/html/qemu-devel/2013-02/msg01101.html
>
Yeah, you're right. Unfortunatelly, this patch was sent after this one was
prepared. I agree, that
my solution is not best but I do not want to do any unnecessary change in code.
> > +qprintf(quiet,
> > +"%" PRId64 "/%" PRId64 "= %0.2f%% allocated, %0.2f%%
> > fragmented\n",
> > result.bfi.allocated_clusters, result.bfi.total_clusters,
> > result.bfi.allocated_clusters * 100.0 /
> > result.bfi.total_clusters,
> > result.bfi.fragmented_clusters * 100.0 /
> > result.bfi.allocated_clusters);
> > +/* end of parameter list */
> > }
>
> This /* end of parameter list */ comment is bogus.
>
> > @@ -742,9 +775,16 @@ static int img_convert(int argc, char **argv)
> > case 't':
> > cache = optarg;
> > break;
> > +case 'q':
> > +quiet = true;
> > +break;
> > }
> > }
> >
> > +if (quiet) {
> > +progress = 0;
> > +}
>
> I'm still not sure I buy this. Since '-p' normally adds output, and
> '-q' normally removes output, I'm wondering if it is better to follow
> conventions of other apps like ls, when when faced with mutually
> competing options will favor the last one specified. Something like:
>
> qemu-img convert -p -q => turns off -p with quiet results
> qemu-img convert -q -p => turns off -q, with progress bar results
>
> Or, it might be worth actually erroring out if both -p and -q are
> present, in any order.
>
I do not like when order of the "-" parameters matter, so I'm not going
to implement this behavior. I could live with error for this combination.
However, I still feel that logic "-p adds something to output and -q
turns output off" is correct. "-p" does not activate output, just improve it.
> > +++ b/qemu-img.texi
> > @@ -54,6 +54,9 @@ indicates that target image must be compressed
> > (qcow format only)
> > with or without a command shows help and lists the supported
> > formats
> > @item -p
> > display progress bar (convert and rebase commands only)
> > +@item -q
> > +Quiet mode - do not print any output (except errors). There's no
> > progress bar
> > +in case both @var{-q} and @var{-p} options are used.
>
> But at least your documentation matches your code, so I guess I can
> live
> with your choice that -q is always more powerful than -p, no matter
> what
> order they appear in.
>
> You have an extra space before the second @var.
>
> --
> Eric Blake eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
--
Miroslav Rezanina
Software Engineer - Virtualization Team
[Qemu-devel] [PATCH] pseries: Add cleanup hook for PAPR virtual LAN device
Currently the spapr-vlan device does not supply a cleanup call for its
NetClientInfo structure. With current qemu versions, that leads to a SEGV
on exit, when net_cleanup() attempts to call the cleanup handlers on all
net clients.
Signed-off-by: David Gibson
---
hw/spapr_llan.c |8
1 file changed, 8 insertions(+)
As a SEGV fix, this really should go in for 1.4. What needs to be
done to make that happen.
diff --git a/hw/spapr_llan.c b/hw/spapr_llan.c
index 6ef2936..0ace2eb 100644
--- a/hw/spapr_llan.c
+++ b/hw/spapr_llan.c
@@ -175,11 +175,19 @@ static ssize_t spapr_vlan_receive(NetClientState *nc,
const uint8_t *buf,
return size;
}
+static void spapr_vlan_cleanup(NetClientState *nc)
+{
+VIOsPAPRVLANDevice *dev = qemu_get_nic_opaque(nc);
+
+dev->nic = NULL;
+}
+
static NetClientInfo net_spapr_vlan_info = {
.type = NET_CLIENT_OPTIONS_KIND_NIC,
.size = sizeof(NICState),
.can_receive = spapr_vlan_can_receive,
.receive = spapr_vlan_receive,
+.cleanup = spapr_vlan_cleanup,
};
static void spapr_vlan_reset(VIOsPAPRDevice *sdev)
--
1.7.10.4
[Qemu-devel] [PATCH] (RFC) target-ppc: Remove vestigial PowerPC 620 support
The PowerPC 620 was the very first 64-bit PowerPC implementation, but
hardly anyone ever actually used the chips. qemu notionally supports the
620, but since we don't actually have code to implement the segment table,
the support is broken (quite likely in other ways too).
This partch, therefore, removes all remaining pieces of 620 support, to
stop it cluttering up the platforms we actually care about.
Signed-off-by: David Gibson
---
monitor.c |4 -
target-ppc/cpu.h| 29 -
target-ppc/helper.h |1 -
target-ppc/machine.c|4 +-
target-ppc/misc_helper.c|6 --
target-ppc/mmu_helper.c | 44 +---
target-ppc/translate.c |1 -
target-ppc/translate_init.c | 251 ---
8 files changed, 7 insertions(+), 333 deletions(-)
Andreas,
I know Alex Graf is happy to remove the PPC620 stuff, but he suggested
I talk to you since prep is the only existing ppc machine which would
ever have supported a PPC620 CPU. Any objections?
diff --git a/monitor.c b/monitor.c
index 20bd19b..7b2c4da 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2936,10 +2936,6 @@ static const MonitorDef monitor_defs[] = {
{ "xer", 0, &monitor_get_xer, },
{ "tbu", 0, &monitor_get_tbu, },
{ "tbl", 0, &monitor_get_tbl, },
-#if defined(TARGET_PPC64)
-/* Address space register */
-{ "asr", offsetof(CPUPPCState, asr) },
-#endif
/* Segment registers */
{ "sdr1", offsetof(CPUPPCState, spr[SPR_SDR1]) },
{ "sr0", offsetof(CPUPPCState, sr[0]) },
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 8c081db..5d04b4c 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -115,8 +115,6 @@ enum powerpc_mmu_t {
#define POWERPC_MMU_1TSEG0x0002
/* 64 bits PowerPC MMU */
POWERPC_MMU_64B= POWERPC_MMU_64 | 0x0001,
-/* 620 variant (no segment exceptions) */
-POWERPC_MMU_620= POWERPC_MMU_64 | 0x0002,
/* Architecture 2.06 variant */
POWERPC_MMU_2_06 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG | 0x0003,
/* Architecture 2.06 "degraded" (no 1T segments) */
@@ -976,8 +974,6 @@ struct CPUPPCState {
/* MMU context - only relevant for full system emulation */
#if !defined(CONFIG_USER_ONLY)
#if defined(TARGET_PPC64)
-/* Address space register */
-target_ulong asr;
/* PowerPC 64 SLB area */
ppc_slb_t slb[64];
int slb_nr;
@@ -1501,11 +1497,9 @@ static inline void cpu_clone_regs(CPUPPCState *env,
target_ulong newsp)
#define SPR_RCPU_MI_RBA2 (0x302)
#define SPR_MPC_MI_AP (0x302)
#define SPR_PERF3 (0x303)
-#define SPR_620_PMC1R (0x303)
#define SPR_RCPU_MI_RBA3 (0x303)
#define SPR_MPC_MI_EPN(0x303)
#define SPR_PERF4 (0x304)
-#define SPR_620_PMC2R (0x304)
#define SPR_PERF5 (0x305)
#define SPR_MPC_MI_TWC(0x305)
#define SPR_PERF6 (0x306)
@@ -1521,7 +1515,6 @@ static inline void cpu_clone_regs(CPUPPCState *env,
target_ulong newsp)
#define SPR_RCPU_L2U_RBA2 (0x30A)
#define SPR_MPC_MD_AP (0x30A)
#define SPR_PERFB (0x30B)
-#define SPR_620_MMCR0R(0x30B)
#define SPR_RCPU_L2U_RBA3 (0x30B)
#define SPR_MPC_MD_EPN(0x30B)
#define SPR_PERFC (0x30C)
@@ -1536,9 +1529,7 @@ static inline void cpu_clone_regs(CPUPPCState *env,
target_ulong newsp)
#define SPR_UPERF1(0x311)
#define SPR_UPERF2(0x312)
#define SPR_UPERF3(0x313)
-#define SPR_620_PMC1W (0x313)
#define SPR_UPERF4(0x314)
-#define SPR_620_PMC2W (0x314)
#define SPR_UPERF5(0x315)
#define SPR_UPERF6(0x316)
#define SPR_UPERF7(0x317)
@@ -1546,7 +1537,6 @@ static inline void cpu_clone_regs(CPUPPCState *env,
target_ulong newsp)
#define SPR_UPERF9(0x319)
#define SPR_UPERFA(0x31A)
#define SPR_UPERFB(0x31B)
-#define SPR_620_MMCR0W(0x31B)
#define SPR_UPERFC(0x31C)
#define SPR_UPERFD(0x31D)
#define SPR_UPERFE(0x31E)
@@ -1618,49 +1608,33 @@ static inline void cpu_clone_regs(CPUPPCState *env,
target_ulong newsp)
#define SPR_USDA (0x3AF)
#define SPR_40x_ZPR (0x3B0)
#define SPR_BOOKE_MAS7(0x3B0)
-#define SPR_620_PMR0 (0x3B0)
#define SPR_MMCR2 (0x3B0)
#define SPR_PMC5 (0x3B1)
#define SPR_40x_PID (0x3B1)
-#define SPR_620_PMR1 (0x3B1)
#define SPR_PMC6 (0x3B2)
#define SPR_440_MMUCR (0x3B2)
-#define SPR_620_PMR2 (0x3B2)
#define SPR_4xx_CCR0 (0x3B3)
#define SPR_BOOKE_EPLC(0x3B3)
-#define SPR_620_PMR3 (0x3B3)
#define SPR_405_IAC3 (0x3B4)
#define SPR_BOOKE_EPSC(0x3B4)
-#define SPR_620_PMR4
Re: [Qemu-devel] [RFC V6 00/33] QCOW2 deduplication core functionality
Hello Stefan, As you can read dedup keep me awake at night. I still think that there is a need for a deduplication implementation that would perform nearly as fast as regular qcow2. I though about this: http://en.wikipedia.org/wiki/Normal_distribution. Not all block are equals for deduplication. Some will deduplicate well and some won't. My idea would be to run periodically a filter on the in ram tree in order to drop the less performing and the less promising block. The less performing block involved on a deduplication operation since the last run of the filter would be kept because they are promising so they would survive and have a chance to climb among the top performers. The less performing block not involved in a deduplication operation since the last run of the filter would be definitively dropped from the HashNode tree since they are loosers. The center of the bell curve would be kept since they are champions. This way this ram based implementation could offer speed while it's memory usage being limited. Regards Benoît
Re: [Qemu-devel] [PATCH 3/5] target-i386: Slim conversion to X86CPU subclasses
On Fri, 8 Feb 2013 16:13:02 -0200
Eduardo Habkost wrote:
> On Fri, Feb 08, 2013 at 05:54:50PM +0100, Andreas Färber wrote:
> > Am 08.02.2013 15:52, schrieb Eduardo Habkost:
> > > On Fri, Feb 08, 2013 at 01:58:42PM +0100, Igor Mammedov wrote:
> > >> On Fri, 08 Feb 2013 12:16:17 +0100
> > >> Andreas Färber wrote:
> > >>> Am 08.02.2013 10:03, schrieb Igor Mammedov:
> > On Thu, 7 Feb 2013 13:08:19 -0200
> > Eduardo Habkost wrote:
> >
> > > On Tue, Feb 05, 2013 at 05:39:22PM +0100, Igor Mammedov wrote:
> > >> @@ -2236,6 +2083,44 @@ static void x86_cpu_initfn(Object *obj)
> > >> }
> > >> }
> > >>
> > >> +static void x86_cpu_def_class_init(ObjectClass *oc, void *data)
> > >> +{
> > >> +X86CPUClass *xcc = X86_CPU_CLASS(oc);
> > >> +ObjectClass *hoc = object_class_by_name(TYPE_HOST_X86_CPU);
> > >> +X86CPUClass *hostcc;
> > >> +x86_def_t *def = data;
> > >> +int i;
> > >> +static const char *versioned_models[] = { "qemu32", "qemu64",
> > >> "athlon" };
> > >> +
> > >> +memcpy(&xcc->info, def, sizeof(x86_def_t));
> > >> +
> > >> +/* host cpu class is available if KVM is enabled,
> > >> + * get kvm overrides from it */
> > >> +if (hoc) {
> > >> +hostcc = X86_CPU_CLASS(hoc);
> > >> +/* sysenter isn't supported in compatibility mode on AMD,
> > >> + * syscall isn't supported in compatibility mode on Intel.
> > >> + * Normally we advertise the actual CPU vendor, but you can
> > >> + * override this using the 'vendor' property if you want to
> > >> use
> > >> + * KVM's sysenter/syscall emulation in compatibility mode
> > >> and
> > >> + * when doing cross vendor migration
> > >> + */
> > >> +memcpy(xcc->info.vendor, hostcc->info.vendor,
> > >> + sizeof(xcc->info.vendor));
> > >> +}
> > >
> > > Again, we have the same problem we had before, but now in the non-host
> > > classes. What if class_init is called before KVM is initialized? I
> > > believe we will be forced to move this hack to the instance init
> > > function.
> > I believe, the in the case where non-host CPU classes might be
> > initialized
> > before KVM "-cpu ?" we do not care what their defaults are, since we
> > only
> > would use class names there and then exit.
> >
> > For case where classes could be inspected over QMP, OQM, KVM would be
> > already
> > initialized if enabled and we would get proper initialization order
> > without
> > hack.
> > >
> > > Who guarantees that KVM will be already initialized when we get a QMP
> > > monitor? We can't do that today because of limitations in the QEMU main
> > > code, but I believe we want to get rid of this limitation eventually,
> > > instead of making it harder to get rid of.
> > >
> > > If we could initialize KVM before QMP is initialized, we could simply
> > > initialize KVM before class_init is called, instead. It would be easier
> > > to reason about, and it would make the limitations of our code very
> > > clear to anybody reading the code in main().
> > That wouldn't work (currently) due to -device and -object being command
> > line options just like -enable-kvm, -disable-kvm and -machine accel=.
>
> Well, we could loop over the command-line options twice.
>
> It is just an alternative that would be better than making class_init
> unreliable. I don't think it would be a great solution anyway.
>
> >
> > >>>
> > >>> I think you're missing Eduardo's and my point:
> > >>>
> > >>> diff --git a/vl.c b/vl.c
> > >>> index a8dc73d..6b9378e 100644
> > >>> --- a/vl.c
> > >>> +++ b/vl.c
> > >>> @@ -2844,6 +2844,7 @@ int main(int argc, char **argv, char **envp)
> > >>> }
> > >>>
> > >>> module_call_init(MODULE_INIT_QOM);
> > >>> +object_class_foreach(walkerfn, TYPE_OBJECT, false, NULL);
> > >>>
> > >>> qemu_add_opts(&qemu_drive_opts);
> > >>> qemu_add_opts(&qemu_chardev_opts);
> > >>>
> > >>> Anyone may iterate over QOM classes at any time after their type
> > >>> registration, which is before the first round of option parsing.
> > >>> Sometime later, after option parsing, there's the -cpu ? handling in
> > >>> vl.c:3854, then vl.c:4018:configure_accelerator().
> > >>>
> > >>> Like I said, mostly a theoretical issue today.
> > >> Question is if we should drop this theoretical issue for 1.5?
> > >
> > > I wouldn't call it just theoretical. It is something that will surely
> > > hit us back. The people working on QMP or on the main() code 6 months
> > > from now will no idea that our class_init code is broken and will
> > > explode if class_init is called too early.
> >
> > We should try to find a reliable solution here or at least add
> > appropriate comments to the module_call_init() call in vl.c.
>
> Agreed. But I beli
[Qemu-devel] [Bug 1120383] Re: incremental live block migration of qemu 1.3.1 doesn't work
That's great, thanks -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1120383 Title: incremental live block migration of qemu 1.3.1 doesn't work Status in QEMU: New Bug description: We tested qemu 1.3.1 for live migration of block device. It failed with error. Since qemu-kvm 1.2.0 is ok for this test, we think this problem is introduced by new qemu 1.3.x releases. To reproduce: 1. compile qemu 1.3.1: # cd qemu-1.3.1 # ./configure --prefix=/usr --sysconfdir=/etc --target-list=x86_64-softmmu # make; make install 2. prepare source(172.16.1.13): # qemu-img create -f qcow2 os.img -b /home/reno/wheezyx64 ###Note: wheezyx64 is a template image for Debian Wheezy # qemu-system-x86_64 -hda os.img -m 512 --enable-kvm -vnc :51 -monitor stdio 3. prepare destination(172.16.1.14): # qemu-img create -f qcow2 os.img -b /home/reno/wheezyx64 # qemu-system-x86_64 -hda os.img -m 512 --enable-kvm -vnc :51 -incoming tcp:0: 4. do live migrate: on source monitor command prompt, input: (qemu) migrate -i tcp:172.16.1.14: monitor command will quit immediately and on destination host, there are errors thrown: Receiving block device images Co-routine re-entered recursively Aborted To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1120383/+subscriptions
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Implements h_read hcall
On Thu, Feb 07, 2013 at 09:28:20AM -0200, Erlon Cruz wrote:
> From: Erlon Cruz
>
> This h_call is useful for DLPAR in future amongst other things. Given an index
> it fetches the corresponding PTE stored in the htab.
Nice. It would be good to add in this little bit of PAPR compliance.
Couple of small nits in the implementation:
>
> Signed-off-by: Erlon Cruz
> ---
> hw/spapr_hcall.c | 58
> ++
> 1 file changed, 58 insertions(+)
>
> diff --git a/hw/spapr_hcall.c b/hw/spapr_hcall.c
> index 2889742..5ba07e5 100644
> --- a/hw/spapr_hcall.c
> +++ b/hw/spapr_hcall.c
> @@ -323,6 +323,63 @@ static target_ulong h_protect(PowerPCCPU *cpu,
> sPAPREnvironment *spapr,
> return H_SUCCESS;
> }
>
> +static target_ulong h_read(PowerPCCPU *cpu, sPAPREnvironment *spapr,
> +target_ulong opcode, target_ulong *args)
> +{
> +CPUPPCState *env = &cpu->env;
> +target_ulong flags = args[0];
> +target_ulong pte_index = args[1];
> +uint8_t *hpte;
> +
> +if ((pte_index * HASH_PTE_SIZE_64) & ~env->htab_mask) {
> +return H_PARAMETER;
> +}
> +
> +if (!(flags & H_READ_4)) {
It would be nice to combine the H_READ_4 and !H_READ_4 paths together,
since except for the masking and stopping sooner the !H_READ_4 path is
just like the H_READ_4 path.
> +target_ulong v, r;
> +target_ulong *pteh = &args[0];
> +target_ulong *ptel = &args[1];
> +
> +hpte = env->external_htab + (pte_index * HASH_PTE_SIZE_64);
> +
> +v = ldq_p(hpte);
> +r = ldq_p(hpte + (HASH_PTE_SIZE_64/2));
> +
> +if (flags & H_R_XLATE) {
> +/* FIXME: include a valid logical page num in the pte */
This comment is misleading. Since you do copy out both words of the
hpte, and qemu stores the external_htab in terms of guest physical (==
logical) addresses, in fact you're *always* supplying a valid logical
page num. So you've already correctly implemented the flag as a
no-op.
I believe that flag is included for the benefit of a true hypervisor,
where the native htab would be stored as true physical addresses, and
it might be expensive for the hypervisor to recompute the logical
address.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
[Qemu-devel] [PATCH for-1.4 stable v2 3/3] block-migration: fix block_save_iterate() return value
The .save_live_iterate() function returns 0 to continue iterating or 1 to stop iterating. Since 16310a3cca7320edb9341c976f7819de0a8c27e0 it only ever returns 0, leading to an infinite loop. Return 1 if we have finished sending dirty blocks. Signed-off-by: Stefan Hajnoczi --- block-migration.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/block-migration.c b/block-migration.c index a91d96b..bcd0039 100644 --- a/block-migration.c +++ b/block-migration.c @@ -582,7 +582,12 @@ static int block_save_iterate(QEMUFile *f, void *opaque) qemu_put_be64(f, BLK_MIG_FLAG_EOS); -return 0; +/* Complete when bulk transfer is done and all dirty blocks have been + * transferred. + */ +return block_mig_state.bulk_completed && + block_mig_state.submitted == 0 && + block_mig_state.read_done == 0; } static int block_save_complete(QEMUFile *f, void *opaque) -- 1.8.1.2
[Qemu-devel] [PATCH for-1.4 stable v2 2/3] block-migration: fix blk_mig_save_dirty_block() return value checking
Commit 43be3a25c931a7f61a76fbfc9d35584cbfc5fb58 changed the
blk_mig_save_dirty_block() return code handling. The function's doc
comment says:
/* return value:
* 0: too much data for max_downtime
* 1: few enough data for max_downtime
*/
Because of the 1 return value, callers must check for ret < 0 instead of
just:
if (ret) { ... }
We do not want to bail when 1 is returned, only on error.
Signed-off-by: Stefan Hajnoczi
---
block-migration.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 573319a..a91d96b 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -569,7 +569,7 @@ static int block_save_iterate(QEMUFile *f, void *opaque)
}
}
}
-if (ret) {
+if (ret < 0) {
blk_mig_cleanup();
return ret;
}
@@ -609,7 +609,7 @@ static int block_save_complete(QEMUFile *f, void *opaque)
} while (ret == 0);
blk_mig_cleanup();
-if (ret) {
+if (ret < 0) {
return ret;
}
/* report completion */
--
1.8.1.2
[Qemu-devel] [PATCH for-1.4 stable v2 1/3] block-migration: improve "Unknown flags" error message
Show the actual flags value and include "block migration" in the error
message so it's clear where the error is coming from.
Signed-off-by: Stefan Hajnoczi
---
block-migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block-migration.c b/block-migration.c
index 9ac7de6..573319a 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -695,7 +695,7 @@ static int block_load(QEMUFile *f, void *opaque, int
version_id)
(addr == 100) ? '\n' : '\r');
fflush(stdout);
} else if (!(flags & BLK_MIG_FLAG_EOS)) {
-fprintf(stderr, "Unknown flags\n");
+fprintf(stderr, "Unknown block migration flags: %#x\n", flags);
return -EINVAL;
}
ret = qemu_file_get_error(f);
--
1.8.1.2
[Qemu-devel] [PATCH for-1.4 stable v2 0/3] block-migration: fix "Unknown flags" error
Block migration is currently broken. This series fixes it. Patch 1 - improve "Unknown flags" error message Patch 2 - the "Unknown flags" error means the source and destination QEMUs are not in sync. The destination expects a block migration message but finds an unexpected message. This is because the source is incorrectly returning early when block migration finishes. Patch 3 - the source is calling iterate() in an infinite loop and never completing block migration. This is because block migration never returns 1 to stop iterating. v2: * Improve iteration stop condition to check: 1. Bulk phase has completed (entire image copied) 2. No aio requests pending 3. All read blocks have been transferred Reno Gan reports this was already broken in qemu-kvm-1.2.0, we're touching that code so fix it. Stefan Hajnoczi (3): block-migration: improve "Unknown flags" error message block-migration: fix blk_mig_save_dirty_block() return value checking block-migration: fix block_save_iterate() return value block-migration.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) -- 1.8.1.2
[Qemu-devel] [PATCH] ide: log error when trying to use ATAPI overlapping features
Signed-off-by: Hervé Poussineau
---
hw/ide/core.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/hw/ide/core.c b/hw/ide/core.c
index 3743dc3..f0ab1a8 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1394,8 +1394,10 @@ void ide_exec_cmd(IDEBus *bus, uint32_t val)
break;
case WIN_PACKETCMD:
/* overlapping commands not supported */
-if (s->feature & 0x02)
+if (s->feature & 0x02) {
+qemu_log_mask(LOG_UNIMP, "ide: overlapping command not supported");
goto abort_cmd;
+}
s->status = READY_STAT | SEEK_STAT;
s->atapi_dma = s->feature & 1;
s->nsector = 1;
--
1.7.10.4
[Qemu-devel] [PATCH] Remove forward declaration of non-existant variable
This variable has been removed 5 years ago in
970ac5a3082428dca91171f270dcd95d6f4b2636.
Signed-off-by: Hervé Poussineau
---
include/sysemu/sysemu.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 1d9599e..ae49088 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -94,7 +94,6 @@ typedef enum DisplayType
} DisplayType;
extern int autostart;
-extern int bios_size;
typedef enum {
VGA_NONE, VGA_STD, VGA_CIRRUS, VGA_VMWARE, VGA_XENFB, VGA_QXL,
--
1.7.10.4
Re: [Qemu-devel] [Bug 1120383] Re: incremental live block migration of qemu 1.3.1 doesn't work
On Sun, Feb 10, 2013 at 3:48 AM, Reno Gan wrote: > Another thing i want to mention about live block migration, though i > don't know if this is really an issue of qemu or downstream libvirt. > > When I was testing live migration of qemu-kvm-1.2.0 for long run, i > found a problem that block data are not completed transferred to target > host. I traced that and found block migration thinks migration is > completed when "block_mig_state.submitted == 0", but actually in some > cases, data are not really transferred yet. > > I think the reasonable judgement for whether block migration is > completed is "block_mig_state.submitted == 0 && > block_mig_state.read_done == 0", that is all data have been transferred. > > I don't see anything about this in block-migration-fixes-for-1.4. Maybe > it has been addressed somewhere else, but if it is not, please consider > this issue and make sure data is integrated during block migration. You are right. Thanks for pointing out this bug. I have changed it to: +/* Complete when bulk transfer is done and all dirty blocks have been + * transferred. + */ +return block_mig_state.bulk_completed && + block_mig_state.submitted == 0 && + block_mig_state.read_done == 0; Stefan
Re: [Qemu-devel] git master endless migration
Hi, tried to reproduce... but wasn't able to... Stefan Am 08.02.2013 11:43, schrieb Paolo Bonzini: Il 08/02/2013 11:29, Stefan Priebe - Profihost AG ha scritto: Hello list, while testing current git master (ecd8d4715ea33aa2c146a5047bacb031e86af599) i've seen a VM endless looping - the monitor socket also did not answer anymore while migrating. The VM was under very low load but the migration never finishs and the VM was not accessable anymore. Is this a known issue? No, can you provide reproduction instructions and/or bisect it? Paolo
[Qemu-devel] [PATCH 01/10] mips-linux-user: Delete n32 and n64 signal stubs
Signed-off-by: Richard Henderson
---
linux-user/signal.c | 58 -
1 file changed, 58 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 67c2311..b2f1d29 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2438,64 +2438,6 @@ void sparc64_get_context(CPUSPARCState *env)
force_sig(TARGET_SIGSEGV);
}
#endif
-#elif defined(TARGET_ABI_MIPSN64)
-
-# warning signal handling not implemented
-
-static void setup_frame(int sig, struct target_sigaction *ka,
-target_sigset_t *set, CPUMIPSState *env)
-{
-fprintf(stderr, "setup_frame: not implemented\n");
-}
-
-static void setup_rt_frame(int sig, struct target_sigaction *ka,
- target_siginfo_t *info,
- target_sigset_t *set, CPUMIPSState *env)
-{
-fprintf(stderr, "setup_rt_frame: not implemented\n");
-}
-
-long do_sigreturn(CPUMIPSState *env)
-{
-fprintf(stderr, "do_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-long do_rt_sigreturn(CPUMIPSState *env)
-{
-fprintf(stderr, "do_rt_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-#elif defined(TARGET_ABI_MIPSN32)
-
-# warning signal handling not implemented
-
-static void setup_frame(int sig, struct target_sigaction *ka,
-target_sigset_t *set, CPUMIPSState *env)
-{
-fprintf(stderr, "setup_frame: not implemented\n");
-}
-
-static void setup_rt_frame(int sig, struct target_sigaction *ka,
- target_siginfo_t *info,
- target_sigset_t *set, CPUMIPSState *env)
-{
-fprintf(stderr, "setup_rt_frame: not implemented\n");
-}
-
-long do_sigreturn(CPUMIPSState *env)
-{
-fprintf(stderr, "do_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
-long do_rt_sigreturn(CPUMIPSState *env)
-{
-fprintf(stderr, "do_rt_sigreturn: not implemented\n");
-return -TARGET_ENOSYS;
-}
-
#elif defined(TARGET_ABI_MIPSO32)
struct target_sigcontext {
--
1.8.1.2
[Qemu-devel] [PATCH 06/10] mips64-linux-user: Enable 64-bit address mode and fpu
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 3b77b53..b3b8dc6 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -15972,6 +15972,14 @@ void cpu_state_reset(CPUMIPSState *env)
#if defined(CONFIG_USER_ONLY)
env->CP0_Status = (MIPS_HFLAG_UM << CP0St_KSU);
+# ifdef TARGET_MIPS64
+/* Enable 64-bit register mode. */
+env->CP0_Status |= (1 << CP0St_PX);
+# endif
+# ifdef TARGET_ABI_MIPSN64
+/* Enable 64-bit address mode. */
+env->CP0_Status |= (1 << CP0St_UX);
+# endif
/* Enable access to the CPUNum, SYNCI_Step, CC, and CCRes RDHWR
hardware registers. */
env->CP0_HWREna |= 0x000F;
@@ -15981,6 +15989,11 @@ void cpu_state_reset(CPUMIPSState *env)
if (env->CP0_Config3 & (1 << CP0C3_DSPP)) {
env->CP0_Status |= (1 << CP0St_MX);
}
+/* Enable 64-bit FPU if the target cpu supports it. */
+env->active_fpu.fcr0 = env->cpu_model->CP1_fcr0;
+if (env->active_fpu.fcr0 & (1 << FCR0_F64)) {
+env->CP0_Status |= (1 << CP0St_FR);
+}
#else
if (env->hflags & MIPS_HFLAG_BMASK) {
/* If the exception was raised from a delay slot,
--
1.8.1.2
[Qemu-devel] [PATCH 03/10] mips-linux-user: Enable mips64 and mipsn32 linux-user targets
Signed-off-by: Richard Henderson --- configure | 4 1 file changed, 4 insertions(+) diff --git a/configure b/configure index 8789324..f36acdd 100755 --- a/configure +++ b/configure @@ -978,6 +978,10 @@ microblaze-linux-user \ microblazeel-linux-user \ mips-linux-user \ mipsel-linux-user \ +mips64-linux-user \ +mips64el-linux-user \ +mipsn32-linux-user \ +mipsn32el-linux-user \ or32-linux-user \ ppc-linux-user \ ppc64-linux-user \ -- 1.8.1.2
[Qemu-devel] [PATCH 04/10] mips-linux-user: Save and restore fpu and dsp from sigcontext
Signed-off-by: Richard Henderson
---
linux-user/signal.c | 157 +--
target-mips/cpu.h| 3 +
target-mips/dsp_helper.c | 16 -
3 files changed, 58 insertions(+), 118 deletions(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 7da676f..a38eaa1 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2508,18 +2508,17 @@ struct target_rt_sigframe {
/* Install trampoline to jump back from signal handler */
static inline int install_sigtramp(unsigned int *tramp, unsigned int syscall)
{
-int err;
+int err = 0;
/*
-* Set up the return code ...
-*
-* li v0, __NR__foo_sigreturn
-* syscall
-*/
+ * Set up the return code ...
+ *
+ * li v0, __NR__foo_sigreturn
+ * syscall
+ */
-err = __put_user(0x2402 + syscall, tramp + 0);
+err |= __put_user(0x2402 + syscall, tramp + 0);
err |= __put_user(0x000c , tramp + 1);
-/* flush_cache_sigtramp((unsigned long) tramp); */
return err;
}
@@ -2527,74 +2526,37 @@ static inline int
setup_sigcontext(CPUMIPSState *regs, struct target_sigcontext *sc)
{
int err = 0;
+int i;
err |= __put_user(regs->active_tc.PC, &sc->sc_pc);
-#define save_gp_reg(i) do {\
-err |= __put_user(regs->active_tc.gpr[i], &sc->sc_regs[i]);\
-} while(0)
-__put_user(0, &sc->sc_regs[0]); save_gp_reg(1); save_gp_reg(2);
-save_gp_reg(3); save_gp_reg(4); save_gp_reg(5); save_gp_reg(6);
-save_gp_reg(7); save_gp_reg(8); save_gp_reg(9); save_gp_reg(10);
-save_gp_reg(11); save_gp_reg(12); save_gp_reg(13); save_gp_reg(14);
-save_gp_reg(15); save_gp_reg(16); save_gp_reg(17); save_gp_reg(18);
-save_gp_reg(19); save_gp_reg(20); save_gp_reg(21); save_gp_reg(22);
-save_gp_reg(23); save_gp_reg(24); save_gp_reg(25); save_gp_reg(26);
-save_gp_reg(27); save_gp_reg(28); save_gp_reg(29); save_gp_reg(30);
-save_gp_reg(31);
-#undef save_gp_reg
+__put_user(0, &sc->sc_regs[0]);
+for (i = 1; i < 32; ++i) {
+err |= __put_user(regs->active_tc.gpr[i], &sc->sc_regs[i]);
+}
err |= __put_user(regs->active_tc.HI[0], &sc->sc_mdhi);
err |= __put_user(regs->active_tc.LO[0], &sc->sc_mdlo);
-/* Not used yet, but might be useful if we ever have DSP suppport */
-#if 0
-if (cpu_has_dsp) {
- err |= __put_user(mfhi1(), &sc->sc_hi1);
- err |= __put_user(mflo1(), &sc->sc_lo1);
- err |= __put_user(mfhi2(), &sc->sc_hi2);
- err |= __put_user(mflo2(), &sc->sc_lo2);
- err |= __put_user(mfhi3(), &sc->sc_hi3);
- err |= __put_user(mflo3(), &sc->sc_lo3);
- err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp);
-}
-/* same with 64 bit */
-#ifdef CONFIG_64BIT
-err |= __put_user(regs->hi, &sc->sc_hi[0]);
-err |= __put_user(regs->lo, &sc->sc_lo[0]);
-if (cpu_has_dsp) {
- err |= __put_user(mfhi1(), &sc->sc_hi[1]);
- err |= __put_user(mflo1(), &sc->sc_lo[1]);
- err |= __put_user(mfhi2(), &sc->sc_hi[2]);
- err |= __put_user(mflo2(), &sc->sc_lo[2]);
- err |= __put_user(mfhi3(), &sc->sc_hi[3]);
- err |= __put_user(mflo3(), &sc->sc_lo[3]);
- err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp);
+/* Rather than checking for dsp existance, always copy. The storage
+ would just be garbage otherwise. */
+err |= __put_user(regs->active_tc.HI[1], &sc->sc_hi1);
+err |= __put_user(regs->active_tc.HI[2], &sc->sc_hi2);
+err |= __put_user(regs->active_tc.HI[3], &sc->sc_hi3);
+err |= __put_user(regs->active_tc.LO[1], &sc->sc_lo1);
+err |= __put_user(regs->active_tc.LO[2], &sc->sc_lo2);
+err |= __put_user(regs->active_tc.LO[3], &sc->sc_lo3);
+{
+uint32_t dsp = cpu_rddsp(0x3ff, regs);
+err |= __put_user(dsp, &sc->sc_dsp);
}
-#endif
-#endif
-
-#if 0
-err |= __put_user(!!used_math(), &sc->sc_used_math);
-if (!used_math())
- goto out;
+err |= __put_user(1, &sc->sc_used_math);
-/*
-* Save FPU state to signal context. Signal handler will "inherit"
-* current FPU state.
-*/
-preempt_disable();
-
-if (!is_fpu_owner()) {
- own_fpu();
- restore_fp(current);
+for (i = 0; i < 32; ++i) {
+err |= __put_user(regs->active_fpu.fpr[i].d, &sc->sc_fpregs[i]);
}
-err |= save_fp_context(sc);
-preempt_enable();
-out:
-#endif
return err;
}
@@ -2602,68 +2564,33 @@ static inline int
restore_sigcontext(CPUMIPSState *regs, struct target_sigcontext *sc)
{
int err = 0;
+int i;
err |= __get_user(regs->CP0_EPC, &sc->sc_pc);
err |= __get_user(regs->active_tc.HI[0], &sc->sc_mdhi);
err |= __get_user(regs->active_tc.LO[0], &sc->sc_mdlo);
-#define restore_gp_reg(i) do {
\
-err |= __get_user(regs->ac
[Qemu-devel] [PATCH 05/10] mips-linux-user: Fix n32 and n64 syscalls
Signed-off-by: Richard Henderson
---
linux-user/main.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index 3df8aa2..3a3be70 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -1783,8 +1783,8 @@ void cpu_loop(CPUPPCState *env)
#ifdef TARGET_MIPS
-#define MIPS_SYS(name, args) args,
-
+# ifdef TARGET_ABI_MIPSO32
+# define MIPS_SYS(name, args) args,
static const uint8_t mips_syscall_args[] = {
MIPS_SYS(sys_syscall, 8)/* 4000 */
MIPS_SYS(sys_exit , 1)
@@ -2130,8 +2130,8 @@ static const uint8_t mips_syscall_args[] = {
MIPS_SYS(sys_clock_adjtime, 2)
MIPS_SYS(sys_syncfs, 1)
};
-
-#undef MIPS_SYS
+# undef MIPS_SYS
+# endif /* O32 */
static int do_store_exclusive(CPUMIPSState *env)
{
@@ -2185,8 +2185,11 @@ static int do_store_exclusive(CPUMIPSState *env)
void cpu_loop(CPUMIPSState *env)
{
target_siginfo_t info;
-int trapnr, ret;
+int trapnr;
+abi_long ret;
+# ifdef TARGET_ABI_MIPSO32
unsigned int syscall_num;
+# endif
for(;;) {
cpu_exec_start(env);
@@ -2194,8 +2197,9 @@ void cpu_loop(CPUMIPSState *env)
cpu_exec_end(env);
switch(trapnr) {
case EXCP_SYSCALL:
-syscall_num = env->active_tc.gpr[2] - 4000;
env->active_tc.PC += 4;
+# ifdef TARGET_ABI_MIPSO32
+syscall_num = env->active_tc.gpr[2] - 4000;
if (syscall_num >= sizeof(mips_syscall_args)) {
ret = -TARGET_ENOSYS;
} else {
@@ -2234,12 +2238,19 @@ void cpu_loop(CPUMIPSState *env)
arg5, arg6, arg7, arg8);
}
done_syscall:
+# else
+ret = do_syscall(env, env->active_tc.gpr[2],
+ env->active_tc.gpr[4], env->active_tc.gpr[5],
+ env->active_tc.gpr[6], env->active_tc.gpr[7],
+ env->active_tc.gpr[8], env->active_tc.gpr[9],
+ env->active_tc.gpr[10], env->active_tc.gpr[11]);
+# endif /* O32 */
if (ret == -TARGET_QEMU_ESIGRETURN) {
/* Returning from a successful sigreturn syscall.
Avoid clobbering register state. */
break;
}
-if ((unsigned int)ret >= (unsigned int)(-1133)) {
+if ((abi_ulong)ret >= (abi_ulong)-1133) {
env->active_tc.gpr[7] = 1; /* error flag */
ret = -ret;
} else {
--
1.8.1.2
[Qemu-devel] [PATCH 07/10] mips64-linux-user: Use MIPS64R2-generic as default cpu.
Signed-off-by: Richard Henderson --- linux-user/main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) I don't actually recall why this patch was in my old tree. It might just have been that I wanted a mips64r2 part for testing and didn't want to keep specifying -cpu on the command-line. OTOH, I don't see any reason not to emulate as many ISA extensions as possible by default. r~ diff --git a/linux-user/main.c b/linux-user/main.c index 3a3be70..8c4dffd 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -3525,7 +3525,9 @@ int main(int argc, char **argv, char **envp) cpu_model = "Fujitsu MB86904"; #endif #elif defined(TARGET_MIPS) -#if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64) +#if defined(TARGET_ABI_MIPSN64) +cpu_model = "MIPS64R2-generic"; +#elif defined(TARGET_ABI_MIPSN32) cpu_model = "20Kc"; #else cpu_model = "24Kf"; -- 1.8.1.2
[Qemu-devel] [PATCH 09/10] mipsn32-linux-user: Restrict address space to 31-bits.
Signed-off-by: Richard Henderson --- linux-user/main.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/linux-user/main.c b/linux-user/main.c index 8c4dffd..25491ca 100644 --- a/linux-user/main.c +++ b/linux-user/main.c @@ -46,10 +46,10 @@ int gdbstub_port; envlist_t *envlist; const char *cpu_model; unsigned long mmap_min_addr; + #if defined(CONFIG_USE_GUEST_BASE) unsigned long guest_base; int have_guest_base; -#if (TARGET_LONG_BITS == 32) && (HOST_LONG_BITS == 64) /* * When running 32-on-64 we should make sure we can fit all of the possible * guest address space into a contiguous chunk of virtual host memory. @@ -57,16 +57,16 @@ int have_guest_base; * This way we will never overlap with our own libraries or binaries or stack * or anything else that QEMU maps. */ -# ifdef TARGET_MIPS +# if HOST_LONG_BITS == 64 \ + && (defined(TARGET_ABI_MIPSO32) || defined(TARGET_ABI_MIPSN32)) /* MIPS only supports 31 bits of virtual address space for user space */ -unsigned long reserved_va = 0x7700; -# else +unsigned long reserved_va = 0x7f00; +# elif (TARGET_LONG_BITS == 32) && (HOST_LONG_BITS == 64) unsigned long reserved_va = 0xf700; -# endif #else unsigned long reserved_va; #endif -#endif +#endif /* CONFIG_USE_GUEST_BASE */ static void usage(void); -- 1.8.1.2
[Qemu-devel] [PATCH 08/10] target-mips: Fix check_cp1_64bitmode
COP1X refers to the availability of indexed memory operations,
not whether the FPU has 64-bit registers.
Signed-off-by: Richard Henderson
---
target-mips/translate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target-mips/translate.c b/target-mips/translate.c
index b3b8dc6..a39e118 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -1366,8 +1366,9 @@ static inline void check_cop1x(DisasContext *ctx)
static inline void check_cp1_64bitmode(DisasContext *ctx)
{
-if (unlikely(~ctx->hflags & (MIPS_HFLAG_F64 | MIPS_HFLAG_COP1X)))
+if (unlikely(!(ctx->hflags & MIPS_HFLAG_F64))) {
generate_exception(ctx, EXCP_RI);
+}
}
/*
--
1.8.1.2
[Qemu-devel] [PATCH 02/10] mips-linux-user: Share o32 code for n32 and n64 signals
Signed-off-by: Richard Henderson
---
linux-user/signal.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index b2f1d29..7da676f 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -2438,8 +2438,9 @@ void sparc64_get_context(CPUSPARCState *env)
force_sig(TARGET_SIGSEGV);
}
#endif
-#elif defined(TARGET_ABI_MIPSO32)
+#elif defined(TARGET_MIPS) || defined(TARGET_MIPS64)
+# if defined(TARGET_ABI_MIPSO32)
struct target_sigcontext {
uint32_t sc_regmask; /* Unused */
uint32_t sc_status;
@@ -2461,6 +2462,25 @@ struct target_sigcontext {
target_ulong sc_hi3;
target_ulong sc_lo3;
};
+# else /* N32 || N64 */
+struct target_sigcontext {
+uint64_t sc_regs[32];
+uint64_t sc_fpregs[32];
+uint64_t sc_mdhi;
+uint64_t sc_hi1;
+uint64_t sc_hi2;
+uint64_t sc_hi3;
+uint64_t sc_mdlo;
+uint64_t sc_lo1;
+uint64_t sc_lo2;
+uint64_t sc_lo3;
+uint64_t sc_pc;
+uint32_t sc_fpc_csr;
+uint32_t sc_used_math;
+uint32_t sc_dsp;
+uint32_t sc_reserved;
+};
+# endif /* O32 */
struct sigframe {
uint32_t sf_ass[4];/* argument save space for o32
*/
@@ -2646,6 +2666,7 @@ restore_sigcontext(CPUMIPSState *regs, struct
target_sigcontext *sc)
#endif
return err;
}
+
/*
* Determine which stack to use..
*/
@@ -2672,6 +2693,7 @@ get_sigframe(struct target_sigaction *ka, CPUMIPSState
*regs, size_t frame_size)
return (sp - frame_size) & ~7;
}
+# if defined(TARGET_ABI_MIPSO32)
/* compare linux/arch/mips/kernel/signal.c:setup_frame() */
static void setup_frame(int sig, struct target_sigaction * ka,
target_sigset_t *set, CPUMIPSState *regs)
@@ -2769,6 +2791,7 @@ badframe:
force_sig(TARGET_SIGSEGV/*, current*/);
return 0;
}
+# endif /* O32 */
static void setup_rt_frame(int sig, struct target_sigaction *ka,
target_siginfo_t *info,
@@ -5499,10 +5522,15 @@ void process_pending_signals(CPUArchState *cpu_env)
}
#endif
/* prepare the stack frame of the virtual CPU */
+#if defined(TARGET_ABI_MIPSN32) || defined(TARGET_ABI_MIPSN64)
+/* These targets do not have traditional signals. */
+setup_rt_frame(sig, sa, &q->info, &target_old_set, cpu_env);
+#else
if (sa->sa_flags & TARGET_SA_SIGINFO)
setup_rt_frame(sig, sa, &q->info, &target_old_set, cpu_env);
else
setup_frame(sig, sa, &target_old_set, cpu_env);
+#endif
if (sa->sa_flags & TARGET_SA_RESETHAND)
sa->_sa_handler = TARGET_SIG_DFL;
}
--
1.8.1.2
[Qemu-devel] [PATCH 00/10] Support mips64/mipsn32-linux-user
Peter's recent userland syscall testing has encouraged me to clean up and re-submit some ages-old patches to enable userland testing of the other mips abis. Please review. r~ Richard Henderson (10): mips-linux-user: Delete n32 and n64 signal stubs mips-linux-user: Share o32 code for n32 and n64 signals mips-linux-user: Enable mips64 and mipsn32 linux-user targets mips-linux-user: Save and restore fpu and dsp from sigcontext mips-linux-user: Fix n32 and n64 syscalls mips64-linux-user: Enable 64-bit address mode and fpu mips64-linux-user: Use MIPS64R2-generic as default cpu. target-mips: Fix check_cp1_64bitmode mipsn32-linux-user: Restrict address space to 31-bits. mipsn32-linux-user: Configure the architecture properly configure | 7 +- linux-user/main.c | 41 +- linux-user/mips64/syscall.h| 14 +- linux-user/mips64/syscall_nr.h | 920 + linux-user/mipsn32/syscall.h | 224 - linux-user/mipsn32/syscall_nr.h| 311 - linux-user/mipsn32/target_signal.h | 29 -- linux-user/mipsn32/termbits.h | 245 -- linux-user/signal.c| 245 +++--- target-mips/cpu.h | 3 + target-mips/dsp_helper.c | 16 +- target-mips/translate.c| 16 +- 12 files changed, 759 insertions(+), 1312 deletions(-) delete mode 100644 linux-user/mipsn32/syscall.h delete mode 100644 linux-user/mipsn32/syscall_nr.h delete mode 100644 linux-user/mipsn32/target_signal.h delete mode 100644 linux-user/mipsn32/termbits.h -- 1.8.1.2
Re: [Qemu-devel] Headsup: windows virtio networking does not work on current git
On Fri, Feb 08, 2013 at 10:18:19PM +1100, Vadim Rozenfeld wrote: > On Thu, 2013-02-07 at 14:33 +0100, Laszlo Ersek wrote: > > Apologies in advance for asking a possibly exorbitantly lame question... > > > > On 02/06/13 10:47, Vadim Rozenfeld wrote: > > > On Tue, 2013-02-05 at 13:58 +0200, Michael S. Tsirkin wrote: > > >> On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote: > > >>> 05.02.2013 15:31, Vadim Rozenfeld wrote: > > On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote: > > > > > But adding feature bits an altering the config size doesn't > > > constitute a > > > change in the software interface IMHO. > > > > I agree, feature bits are good. The only one problem with them, is that > > driver usually doesn't have access to PCI space during the driver > > loading phase. > > >>> > > >>> Vadim, can you please describe in a bit more details what the actual > > >>> issue > > >>> here is, from the windows or windows driver point of view? > > > > > If a driver receives descriptor with memory type resources it needs to > > > map physical address to logical. This process requires the number of > > > bytes to be mapped, and it is the best place for sanity check to verify > > > that the resources are valid and not corrupted. We usually do it by > > > comparing the resource size with some predefined value, that we expect > > > to see. > > > > >>> Is it really > > >>> that bad that the config space size changed? Why it has this effect? > > > > > Because in this case it's hard to distinguish between resource's > > > corruption and HW update. > > > > In theory, would the following approach work? > > > > (1) insist on revision-id being 0, > > > > (2) only require a minimum size of VIRTIO_PCI_CONFIG_NOMSI == 20 bytes > > from the iomem BAR (= common virtio header, guaranteed by the virtio > > spec for revision-id==0) when loading the driver, > > > > (3) at first, only map this initial (guaranteed) part of the resource, > > > > (4) this should provide access to the feature bits, allowing > > verification of the full BAR size, including MSI-X fields and device > > type specific fields, > > > > (5a) remap the BAR with full size if there's a match, > I would try avoiding any remapping in virtio block and scsi drivers, > especially when they are operating in system installation, crash dump > and hibernation modes. > Best regards, > Vadim. Looks like there's some misunderstanding. It's an IO BAR, not a memory BAR. As such I don't think there is any remapping done on x86 before access. > > (5b) if there's a mismatch, set "permanent hardware failure" or some > > such in the loaded drier. > > > > It would be probably overkill; I'm just wondering if it made sense in > > theory. > > > > Thanks > > Laszlo >
Re: [Qemu-devel] qemu throws KVM internal error - Any ideas?
On Sat, Feb 09, 2013 at 02:56:01PM -0200, Lucas Meneghel Rodrigues wrote: > Hey Gleb, Marcelo: > > I was looking at the sanity jobs for qemu.git and found this error > that happened during RHEL 6.3 guest reboot test: > RIP==RAX. Probably emulation gone wrong. Can you verify if it reproducible? Please report kvm related problems on kvm mailing list too. -- Gleb.
Re: [Qemu-devel] [PATCH] pc-bios: build OpenBIOS if possible
On Sun, Feb 10, 2013 at 6:42 AM, Michael Tokarev wrote: > 09.02.2013 23:01, Blue Swirl wrote: >> >> Check if xsltproc and Sparc32, Sparc64 and PPC compilers >> are available. If found, rebuild OpenBIOS ROMs from submodule. >> >> Signed-off-by: Blue Swirl >> --- >> A patch to OpenBIOS is also needed to support out of tree build, >> just sent to the list. > > [] > >> +# OpenBIOS needs xsltproc, and Sparc32, Sparc64 and PPC cross compilers >> +if has xsltproc; then >> +if has_crossgcc "sparc" -a has_crossgcc "sparc64" -a \ >> +\( has_crossgcc "powerpc" -o has_crossgcc "ppc" \); then >> +roms="$roms openbios" >> +fi >> +fi > > > Do we need to be able to turn it off? Or maybe we should just > stop doing this by default (since binaries are already present > in the tarball), but instead suggest user to run `make -C roms' > if [s]he needs/wants these roms to be rebuilt? We also build optionroms and spapr-rtas automatically, not seabios though and there's no option to disable/enable those. I'm not sure why we build those either except to encourage using self built ROMs instead of the supplied binaries. I think it has more to do with keeping in line with the spirit of open source rather than any technical advantages. > > I guess this is not a question for this patch but a more general > question. > > I dislike rebuilding stuff this way, in particular because current > system may have some outdated (or too new) compiler for that stuff > to produce somehow broken binary, because this way, the resulting > blobs differs from ones in the tarball and comparing in attempt to > find what has changed shows these and makes some noize, -- stuff > like that. This could also apply to optionroms and spapr-rtas. Clang/LLVM assembler does not support 16 bit x86 code yet, so we already have a workaround for that. For OpenBIOS this is also a real concern since GCC 4.7.0 does not produce working binaries. > > >> +++ b/pc-bios/openbios/Makefile >> >> +config-timestamp: $(SRC_PATH)/roms/openbios/config/scripts/switch-arch >> + mkdir build || true > > > That's what `mkdir -p' if for. Thanks, will fix. The directory could be also made by configure. > > Thanks, > > /mjt
