Re: [Qemu-devel] kvm segfaulting
Hi Paolo,
sadly no luck. A VM crashed again.
[ ~]# addr2line -e /usr/lib/debug/usr/bin/kvm -f 24040c
virtio_scsi_command_complete
hw/virtio-scsi.c:429
Same point like last time:
static void virtio_scsi_command_complete(SCSIRequest *r, uint32_t status,
size_t resid)
{
VirtIOSCSIReq *req = r->hba_private;
uint32_t sense_len;
429 =>req->resp.cmd->response = VIRTIO_SCSI_S_OK;
req->resp.cmd->status = status;
if (req->resp.cmd->status == GOOD) {
req->resp.cmd->resid = tswap32(resid);
} else {
req->resp.cmd->resid = 0;
sense_len = scsi_req_get_sense(r, req->resp.cmd->sense,
VIRTIO_SCSI_SENSE_SIZE);
req->resp.cmd->sense_len = tswap32(sense_len);
}
virtio_scsi_complete_req(req);
Greets
Stefan
Am 12.02.2013 15:34, schrieb Paolo Bonzini:
> Il 12/02/2013 14:46, Stefan Priebe - Profihost AG ha scritto:
>> Hi,
>>
>> thanks - i applied the patch to the latest master. I hope that this will
>> solve my issue. Will this one get integrated in 1.4 final?
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.4] net: Avoid NULL function pointer dereference on cleanup
Am 13.02.2013 um 00:13 schrieb David Gibson : > On Tue, Feb 12, 2013 at 11:16:06PM +0100, Andreas Färber wrote: >> The pSeries machine and some other devices don't supply a cleanup >> callback. Revert part of 1ceef9f27359cbe92ef124bf74de6f792e71f6fb that >> started calling it unconditionally. > > Note that Alex Graf has now accepted a patch from me which adds a > cleanup callback to pseries. I expect this is still a good idea for > the other cases, though. But only for 1.5. 1.4 should simply get this one applied. Alex > > -- > 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
Re: [Qemu-devel] [Qemu-ppc] [PATCH] pseries: Implements h_read hcall
On Tue, Feb 12, 2013 at 11:07:10PM +0100, Alexander Graf wrote:
>
> On 07.02.2013, at 12:28, 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.
> >
> > 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)) {
> > +target_ulong v, r;
> > +target_ulong *pteh = &args[0];
> > +target_ulong *ptel = &args[1];
> > +
> > +hpte = env->external_htab + (pte_index * HASH_PTE_SIZE_64);
>
> You are not guaranteed that there is an external htab.
Actually in the case of spapr, you are - the existing hash table
management calls all assume the existence of an external htab.
> In fact, looking at the external_htab users, we should probably
> introduce a few helper read functions for the htab that abstract the
> glorious external_htab/htab_base details away from you.
That said, I actually wrote such helpers about 15 minutes ago as part
of my MMU cleanup series.
--
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] Fix guest OS hangs on boot when 64bit PCI BAR present
At the moment may_overlap flag of MemoryRegion structure
is ignored by the address range assignment process.
This may lead to guest OS hangs if critical qemu
resources are overlapped by PCI BARs. For example
ivshmem 64bit PCI BAR may overlap kvm-apic-msi under
certain conditions. This patch adds a rule that the
regions which should not be overlapped are added to the
view first (i.e. having highest priority). The patch
also corrects ivshmem bar resource to be overlapable
which is the default for PCI BARs
Signed-off-by: Alexey Korolev
---
hw/ivshmem.c |2 +-
memory.c | 15 ++-
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/hw/ivshmem.c b/hw/ivshmem.c
index afaf9b3..1770fa3 100644
--- a/hw/ivshmem.c
+++ b/hw/ivshmem.c
@@ -341,7 +341,7 @@ static void create_shared_memory_BAR(IVShmemState *s, int
fd) {
memory_region_init_ram_ptr(&s->ivshmem, "ivshmem.bar2",
s->ivshmem_size, ptr);
vmstate_register_ram(&s->ivshmem, &s->dev.qdev);
-memory_region_add_subregion(&s->bar, 0, &s->ivshmem);
+memory_region_add_subregion_overlap(&s->bar, 0, &s->ivshmem, 1);
/* region for shared memory */
pci_register_bar(&s->dev, 2, s->ivshmem_attr, &s->bar);
diff --git a/memory.c b/memory.c
index cd7d5e0..f1119e7 100644
--- a/memory.c
+++ b/memory.c
@@ -475,7 +475,8 @@ static void render_memory_region(FlatView *view,
MemoryRegion *mr,
Int128 base,
AddrRange clip,
- bool readonly)
+ bool readonly,
+ bool overlap)
{
MemoryRegion *subregion;
unsigned i;
@@ -503,16 +504,16 @@ static void render_memory_region(FlatView *view,
if (mr->alias) {
int128_subfrom(&base, int128_make64(mr->alias->addr));
int128_subfrom(&base, int128_make64(mr->alias_offset));
-render_memory_region(view, mr->alias, base, clip, readonly);
+render_memory_region(view, mr->alias, base, clip, readonly, overlap);
return;
}
/* Render subregions in priority order. */
QTAILQ_FOREACH(subregion, &mr->subregions, subregions_link) {
-render_memory_region(view, subregion, base, clip, readonly);
+render_memory_region(view, subregion, base, clip, readonly, overlap);
}
-if (!mr->terminates) {
+if (mr->may_overlap != overlap || !mr->terminates) {
return;
}
@@ -567,7 +568,11 @@ static FlatView generate_memory_topology(MemoryRegion *mr)
if (mr) {
render_memory_region(&view, mr, int128_zero(),
- addrrange_make(int128_zero(), int128_2_64()),
false);
+ addrrange_make(int128_zero(), int128_2_64()),
+ false, false);
+render_memory_region(&view, mr, int128_zero(),
+ addrrange_make(int128_zero(), int128_2_64()),
+ false, true);
}
flatview_simplify(&view);
--
1.7.9.5
[Qemu-devel] [BUG] Guest OS hangs on boot when 64bit BAR present (kvm-apic -msi resource conflict)
Sometime ago I reported an issue about guest OS hang when 64bit BAR present. http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg03189.html http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00413.html Some more investigation has been done, so in this post I'll try to explain why it happens and offer possible solutions: *When the issue happens* The issue occurs on Linux guest OS if kernel version <2.6.36 A Guest OS hangs on boot when a 64bit PCI BAR is present in a system (if we use ivshmem driver for example) and occupies range within first 4 GB. *How to reproduce* I used the following qemu command to reproduce the case: /usr/local/bin/qemu-system-x86_64 -M pc-1.3 -enable-kvm -m 2000 -smp 1,sockets=1,cores=1,threads=1 -name Rh5332 -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Rh5332.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot cd -drive file=/home/akorolev/rh5332.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -chardev file,id=charserial0,path=/home/akorolev/serial.log -device isa-serial,chardev=charserial0,id=serial0 -usb -vnc 127.0.0.1:0 -k en-us -vga cirrus -device ivshmem,shm,size=32M-device virtio-balloon-pci,id=balloon0 Tried different guests: Centos 5.8 64bit, RHEL 5.3 32bit, FC 12 64bit on all machines hang occurs in 100% cases *Why it happens* The issue basically comes from Linux PCI enumeration code. The OS enumerates 64BIT bars when device is enabled using the following procedure. 1. Write all FF's to lower half of 64bit BAR 2. Write address back to lower half of 64bit BAR 3. Write all FF's to higher half of 64bit BAR 4. Write address back to higher half of 64bit BAR For qemu it means that qemu pci_default_write_config() recevies all FFs for lower part of the 64bit BAR. Then it applies the mask and converts the value to "All FF's - size + 1" (FE00 if size is 32MB). So for short period of time the range [0xFE00 - 0x] will be occupied by ivshmem resource. For some reason it is lethal for further boot process. We have found that boot process screws up completely if kvm-apic-msi range is overlapped even for short period of time. (We still don't know why it happens, hope that the qemu maintainers can answer?) If we look at kvm-apic-msi memory region it is a non-overlapable memory region with hardcoded address range [0xFEE0 - 0xFEF0]. Here is a log we collected from render_memory_regions: system overlap 0 pri 0 [0x0 - 0x7fff] kvmvapic-rom overlap 1 pri 1000 [0xca000 - 0xcd000] pc.ram overlap 0 pri 0 [0xca000 - 0xcd000] ++ pc.ram [0xca000 - 0xcd000] is added to view smram-region overlap 1 pri 1 [0xa - 0xc] pci overlap 0 pri 0 [0xa - 0xc] cirrus-lowmem-container overlap 1 pri 1 [0xa - 0xc] cirrus-low-memory overlap 0 pri 0 [0xa - 0xc] ++cirrus-low-memory [0xa - 0xc] is added to view kvm-ioapic overlap 0 pri 0 [0xfec0 - 0xfec01000] ++kvm-ioapic [0xfec0 - 0xfec01000] is added to view pci-hole64 overlap 0 pri 0 [0x1 - 0x4001] pci overlap 0 pri 0 [0x1 - 0x4001] pci-hole overlap 0 pri 0 [0x7d00 - 0x1] pci overlap 0 pri 0 [0x7d00 - 0x1] ivshmem-bar2-container overlap 1 pri 1 [0xfe00 - 0x1] ivshmem.bar2 overlap 0 pri 0 [0xfe00 - 0x1] ++ivshmem.bar2 [0xfe00 - 0xfec0] is added to view ++ivshmem.bar2 [0xfec01000 - 0x1] is added to view ivshmem-mmio overlap 1 pri 1 [0xfebf1000 - 0xfebf1100] e1000-mmio overlap 1 pri 1 [0xfeba - 0xfebc] cirrus-mmio overlap 1 pri 1 [0xfebf - 0xfebf1000] cirrus-pci-bar0 overlap 1 pri 1 [0xfa00 - 0xfc00] vga.vram overlap 1 pri 1 [0xfa00 - 0xfa80] ++vga.vram [0xfa00 - 0xfa80] is added to view cirrus-bitblt-mmio overlap 0 pri 0 [0xfb00 - 0xfb40] ++cirrus-bitblt-mmio [0xfb00 - 0xfb40] is added to view cirrus-linear-io overlap 0 pri 0 [0xfa00 - 0xfa80] pc.bios overlap 0 pri 0 [0xfffe - 0x1] ram-below-4g overlap 0 pri 0 [0x0 - 0x7d00] pc.ram overlap 0 pri 0 [0x0 - 0x7d00] ++pc.ram [0x0 - 0xa] is added to view ++pc.ram [0x10 - 0x7d00] is added to view kvm-apic-msi overlap 0 pri 0 [0xfee0 - 0xfef0] As you can see from log the kvm-apic-msi is enumarated last when range [0xfee0 - 0xfef0] is already occupied by ivshmem.bar2 [0xfec01000 - 0x1]. *Possible solutions* Solution 1. Probably the best would be adding the rule that regions which may not be over
Re: [Qemu-devel] [Qemu-ppc] [PATCH for-1.4] net: Avoid NULL function pointer dereference on cleanup
On Tue, Feb 12, 2013 at 11:16:06PM +0100, Andreas Färber wrote: > The pSeries machine and some other devices don't supply a cleanup > callback. Revert part of 1ceef9f27359cbe92ef124bf74de6f792e71f6fb that > started calling it unconditionally. Note that Alex Graf has now accepted a patch from me which adds a cleanup callback to pseries. I expect this is still a good idea for the other cases, though. -- 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
Re: [Qemu-devel] [PATCH V18 08/10] libqblock: libqblock API implement
On Sat, Feb 9, 2013 at 7:42 AM, Wenchao Xia wrote:
This patch contains implemention for APIs. Basically it is a layer
above qemu block general layer now.
qb_image_new() will try do init for this library.
Signed-off-by: Wenchao Xia
---
libqblock/libqblock-error.c | 49 +++
libqblock/libqblock.c | 991 +++
2 files changed, 1040 insertions(+), 0 deletions(-)
diff --git a/libqblock/libqblock-error.c b/libqblock/libqblock-error.c
index e69de29..2367ab4 100644
--- a/libqblock/libqblock-error.c
+++ b/libqblock/libqblock-error.c
@@ -0,0 +1,49 @@
+
+typedef struct LibqbFormatStrMapping {
+const char *fmt_str;
+QBlockFormat fmt_type;
+} LibqbFormatStrMapping;
+
+LibqbFormatStrMapping libqb_formatstr_table[] = {
static const
OK.
+{"cow", QB_FORMAT_COW},
+{"qed", QB_FORMAT_QED},
+{"qcow", QB_FORMAT_QCOW},
+{"qcow2", QB_FORMAT_QCOW2},
+{"raw", QB_FORMAT_RAW},
+{"rbd", QB_FORMAT_RBD},
+{"sheepdog", QB_FORMAT_SHEEPDOG},
+{"vdi", QB_FORMAT_VDI},
+{"vmdk", QB_FORMAT_VMDK},
+{"vpc", QB_FORMAT_VPC},
+{NULL, 0},
You can avoid this NULL entry and save space by using ARRAY_SIZE() in
the loop. Compiler could also unroll the loop.
OK.
+};
+
+__attribute__((constructor))
+static void libqblock_init(void)
+{
+/* Todo: add an assertion about the ABI. */
+libqb_global_data.init_flag = 0;
+pthread_mutex_init(&libqb_global_data.mutex, NULL);
+}
+
+const char *qb_formattype2str(QBlockFormat fmt_type)
+{
+int i = 0;
+LibqbFormatStrMapping *tb = libqb_formatstr_table;
This does not seem to be useful, you could use libqb_formatstr_table directly.
OK.
+
+if ((fmt_type <= QB_FORMAT_NONE) || (fmt_type >= QB_FORMAT_MAX)) {
+return NULL;
+}
+while (tb[i].fmt_str != NULL) {
for (i = 0; i < ARRAY_SIZE(libqb_formatstr_table); i++) {
OK.
+if (tb[i].fmt_type == fmt_type) {
+return tb[i].fmt_str;
+}
+i++;
+}
+return NULL;
+}
+
+QBlockFormat qb_str2fmttype(const char *fmt_str)
+{
+int i = 0;
+LibqbFormatStrMapping *tb = libqb_formatstr_table;
+
+if (fmt_str == NULL) {
+return QB_FORMAT_NONE;
+}
+while (tb[i].fmt_str != NULL) {
+if ((strcmp(fmt_str, tb[i].fmt_str) == 0)) {
+return tb[i].fmt_type;
+}
+i++;
+}
+return QB_FORMAT_NONE;
+}
+
+static void set_context_err(QBlockContext *context, int err_ret,
+const char *fmt, ...)
GCC_FMT_ATTR()?
Do you mean this declaration is needed here?
+{
+va_list ap;
+
+if (context->g_error != NULL) {
+g_error_free(context->g_error);
+}
+
+va_start(ap, fmt);
+context->g_error = g_error_new_valist(qb_error_quark(), err_ret, fmt, ap);
+va_end(ap);
+
+context->err_ret = err_ret;
+if (err_ret == QB_ERR_INTERNAL_ERR) {
+context->err_no = -errno;
+} else {
+context->err_no = 0;
+}
+}
+
+static void delete_context(QBlockContext **p_context)
+{
+if ((*p_context)->g_error != NULL) {
+g_error_free((*p_context)->g_error);
+}
+g_free(*p_context);
+*p_context = NULL;
+return;
Useless return, please remove.
OK.
--
1.7.1
--
Best Regards
Wenchao Xia
Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Remove vestigial PowerPC 620 support (v2)
On Tue, Feb 12, 2013 at 11:18:06PM +0100, Alexander Graf wrote:
>
> On 12.02.2013, at 23:16, Alexander Graf wrote:
>
> >
> > On 12.02.2013, at 11:23, Andreas Färber wrote:
> >
> >> Am 12.02.2013 03:16, schrieb David Gibson:
> >>> 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
> >>> ---
> >>> v2: Don't remove the POWERPC_DEF()s from the table, just move them under
> >>> #ifdef(TODO) to document the CPU's existence and aliases.
> >> [...]
> >>> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> >>> index 6cebaa1..1d2e842 100644
> >>> --- a/target-ppc/translate_init.c
> >>> +++ b/target-ppc/translate_init.c
> >> [...]
> >>> @@ -9244,11 +9000,11 @@ static const ppc_def_t ppc_defs[] = {
> >>>POWERPC_DEF("7457A_v1.2",CPU_POWERPC_74x7A_v12, 7455),
> >>>/* 64 bits PowerPC
> >>> */
> >>> #if defined (TARGET_PPC64)
> >>> +#if defined (TODO)
> >>
> >> checkpatch.pl will surely complain about the space, and elsewhere the
> >> #ifs are repeated per model/family. I.e., I would've expected one new
> >> pair of #if defined(TODO) and #endif around the two 620 definitions. Or
> >> does the already-TODO 630 model depend on the 620 code despite type 630?
> >>
> >>>/* PowerPC 620
> >>> */
> >>>POWERPC_DEF("620", CPU_POWERPC_620,620),
> >>>/* Code name for PowerPC 620
> >>> */
> >>>POWERPC_DEF("Trident", CPU_POWERPC_620,620),
> >>> -#if defined (TODO)
> >>>/* PowerPC 630 (POWER3)
> >>> */
> >>>POWERPC_DEF("630", CPU_POWERPC_630,630),
> >>>POWERPC_DEF("POWER3",CPU_POWERPC_630,630),
> >> [snip]
> >>
> >> I've CC'ed you on the patchset that Alex and me had been preparing.
> >> Let's leave it to Alex how to proceed with the conflicting patches.
> >
> > I would like to get the QOM'ification through first, then declare 620 as
> > unsupported.
> >
> > David, I think the best way to proceed here would be to not touch anything
> > in translate_init.c in your MMU cleanup patch set :). Or wouldn't that work?
>
> Eh - you aren't touching anything there. It's all about this patch
> :). Oops.
> Then yes, QOM first.
Actually some future patches in my mmu cleanup series may touch
translate_init.c - in particular I'm thinking about making separate
spr callbacks for the 32-bit and 64-bit versions of SDR1.
But I'm happy to wait until after the qom stuff and rework things as
necessary for it.
--
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
Re: [Qemu-devel] [RFC PATCH RDMA support v2: 3/6] install new monitor commands and setup RDMA capabilities
Acknowledged. /* * Michael R. Hines * http://researcher.ibm.com/person/us-mrhines */ From: Eric Blake To: "Michael R. Hines" , Cc: qemu-devel@nongnu.org, Anthony Liguori/Austin/IBM@IBMUS, Bulent Abali/Watson/IBM@IBMUS, Michael R Hines/Watson/IBM@IBMUS, Gokul B Kandiraju/Watson/IBM@IBMUS Date: 02/12/2013 12:11 PM Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v2: 3/6] install new monitor commands and setup RDMA capabilities On 02/11/2013 08:06 PM, Michael R. Hines wrote: [no need to top-post on a technical list] > None of the other migration QMP commands use dashes. Then how do you explain 'query-migrate', 'migrate-set-capabilities', 'query-migrate-capabilities', 'migrate-set-cache-size', 'query-migrate-cache-size'? I argue that 'migrate_cancel' and 'migrate_set_downtime' are the odd ones out, and only because they were written before our current policy of preferring dash. > Shouldn't I stay consistent with the other commands? Yes, which is why I'm arguing for using dash. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org [attachment "signature.asc" deleted by Michael R Hines/Watson/IBM]
Re: [Qemu-devel] [PATCH for-1.4] libi2c-omap: Fix endianness dependency
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4 0/2] trace: fix trace/simple.c compiler warnings
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4 0/2] block-migration: fix pending() and iterate() return values
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] qemu-log: Remove qemu_log_try_set_file() and its users
Peter Maydell schrieb: >Remove the function qemu_log_try_set_file() and its users (which >are all in TCG code generation functions for various targets). >This function was added to abstract out code which was originally >written as "if (!logfile) logfile = stderr;" in order that BUG: >case code which did an unguarded "fprintf(logfile, ...)" would >not crash if debug logging was not enabled. Since those direct >uses of logfile have also been abstracted away into qemu_log() >calls which check for a NULL logfile, there is no need for the >target-* files to mess with the user's chosen logging settings. > >Signed-off-by: Peter Maydell Acked-by: Michael Walle
Re: [Qemu-devel] [PATCH v1 2/2] configure/Make: Build libfdt from submodule DTC
Hi Alex,
On Wed, Feb 13, 2013 at 7:55 AM, Alexander Graf wrote:
>
> On 07.02.2013, at 07:08, Peter Crosthwaite wrote:
>
>> Configure to use the DTC submodule to build libfdt when no system libfdt
>> is found. Prompt to install the DTC submodule if --enable-fdt is set but
>> no DTC can be found.
>>
>> DTC has no out-of-tree build capability, so the configure will symlink
>> the Makefile and scripts directory in the out of tree build directory
>> and pass in all the needed DTC arguments to make out of tree build happen.
>> Ideally we fix the DTC make to support out of tree, but did it this way to
>> avoid commits to DTC.
>>
>> Signed-off-by: Peter Crosthwaite
>> ---
>> Makefile | 10 ++
>> configure | 29 +
>> 2 files changed, 35 insertions(+), 4 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 0d9099a..cfa77c7 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -136,6 +136,15 @@ pixman/Makefile: $(SRC_PATH)/pixman/configure
>> $(SRC_PATH)/pixman/configure:
>> (cd $(SRC_PATH)/pixman; autoreconf -v --install)
>>
>> +DTC_MAKE_ARGS=-I$(SRC_PATH)/dtc VPATH=$(SRC_PATH)/dtc -C dtc V="$(V)"
>> LIBFDT_srcdir=$(SRC_PATH)/dtc/libfdt
>> +DTC_CFLAGS="$(CFLAGS) $(extra_cflags) -I$(BUILD_DIR)/dtc -I$(SRC_PATH)/dtc
>> -I$(SRC_PATH)/dtc/libfdt"
>> +
>> +subdir-dtc:dtc/libfdt dtc/tests
>> + $(call quiet-command,$(MAKE) $(DTC_MAKE_ARGS) CPPFLAGS=$(DTC_CFLAGS)
>> CC=$(CC) AR=$(AR) LD=$(LD) $(SUBDIR_MAKEFLAGS) libfdt,)
>
> I do remember that compiling pixman cross was having trouble. Have you
> verified that it works here?
>
Its a case of speak of the devil, as we are just today finishing our
own little cross compile flow and submodule pixman did fail for us. We
have a resolution and we should have patches to fix this (or at least
an RFC) shortly. Will fix this DTC make as well in V2 as some changes
were required here for cross along the same lines.
>> +
>> +dtc/%:
>> + mkdir -p $@
>> +
>> $(SUBDIR_RULES): libqemuutil.a libqemustub.a $(common-obj-y)
>>
>> ROMSUBDIR_RULES=$(patsubst %,romsubdir-%, $(ROMS))
>> @@ -253,6 +262,7 @@ distclean: clean
>> rm -rf $$d || exit 1 ; \
>> done
>> if test -f pixman/config.log; then make -C pixman distclean; fi
>> + if test -f dtc/version_gen.h; then make $(DTC_MAKE_ARGS) clean; fi
>>
>> KEYMAPS=da en-gb et fr fr-ch is lt modifiers no pt-br sv \
>> ar de en-us fi fr-be hr it lv nl pl ru th \
>> diff --git a/configure b/configure
>> index 8789324..a0b265a 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2375,11 +2375,28 @@ if test "$fdt" != "no" ; then
>> int main(void) { return 0; }
>> EOF
>> if compile_prog "" "$fdt_libs" ; then
>> +#system DTC is good - use it
>> fdt=yes
>> - else
>> -if test "$fdt" = "yes" ; then
>> - feature_not_found "fdt"
>> + elif test -d ${source_path}/dtc/libfdt ; then
>> +#have submodule DTC - use it
>> +fdt=yes
>> +dtc_internal="yes"
>> +mkdir -p dtc
>
> Where does this get created? We need to make sure we compile into the foreign
> object dir if the user provides one (I don't remember the details how that
> worked though).
>
In the out of tree build directory. This is where all the compiled
objects will be placed in out of tree build. For an in tree build its
a nop as that dir will already exist in source.
Regards,
Peter
>
> Alex
>
>> +if [ "$source_path" != `pwd` ]; then
>> + symlink "$source_path/dtc/Makefile" "dtc/Makefile"
>> + symlink "$source_path/dtc/scripts" "dtc/scripts"
>> fi
>> +fdt_cflags="-I\$(SRC_PATH)/dtc/libfdt"
>> +fdt_libs="-L\$(BUILD_DIR)/dtc/libfdt $fdt_libs"
>> + elif test "$fdt" = "yes" ; then
>> +#have neither and want - prompt for system/submodule install
>> +echo "ERROR: DTC not present. Your options:"
>> +echo " (1) Preferred: Install the DTC devel package"
>> +echo " (2) Fetch the DTC submodule, using:"
>> +echo " git submodule update --init dtc"
>> +exit 1
>> + else
>> +#dont have and dont want
>> fdt_libs=
>> fdt=no
>> fi
>> @@ -3242,7 +3259,7 @@ if test "$cpu" = "ppc64" -a "$targetos" != "Darwin" ;
>> then
>> fi
>>
>> # add pixman flags after all config tests are done
>> -QEMU_CFLAGS="$QEMU_CFLAGS $pixman_cflags"
>> +QEMU_CFLAGS="$QEMU_CFLAGS $pixman_cflags $fdt_cflags"
>> libs_softmmu="$libs_softmmu $pixman_libs"
>>
>> echo "Install prefix$prefix"
>> @@ -4278,6 +4295,10 @@ if [ "$pixman" = "internal" ]; then
>> echo "config-host.h: subdir-pixman" >> $config_host_mak
>> fi
>>
>> +if [ "$dtc_internal" = "yes" ]; then
>> + echo "config-host.h: subdir-dtc" >> $config_host_mak
>> +fi
>> +
>> # build tree in object directory in case the source is not in the current
>> directory
>> DIRS="tests tests/tcg tests/tcg/cris tests/tcg/lm32"
>> DIRS="$DIRS pc-bios/optionrom pc-bios/spapr-rtas"
>> --
>> 1.7.0.4
>>
>>
>
>
Re: [Qemu-devel] [PATCH RFC v2 0/5] qtest: tmp105-test BE fix for 1.4 and MMIO support
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4] migration: restrict scope of incoming fd read handler
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
mdroth writes:
> On Tue, Feb 12, 2013 at 05:56:00PM +0100, Markus Armbruster wrote:
>> Gerd Hoffmann writes:
>>
>> > Hi,
>> >
>> >> But why nested discriminators?
>> >>
>> >> regular files: type=file
>> >> serial : type=port, data.type=serial
>> >> parallel : type=port, data.type=parallel
>> >>
>> >> Simpler, and closer to existing -chardev:
>> >>
>> >> regular files: type=file
>> >> serial : type=serial
>> >> parallel : type=parallel
>> >
>> > Matter of taste IMHO.
>> > I can live with that too.
>> > Feel free to send patches.
>> >
>> >> I also dislike the pointless '"data" : {}' required by type pty and
>> >> null, but I can't figure out how to express 'void' in the schema.
>> >
>> > Someone mentioned it is possible to leave out empty data altogether.
>> > Didn't try whenever our marshaller actually accepts that though.
>>
>> Looks like it doesn't :(
>>
>> Empty objects work fine here:
>>
>> { 'type': 'ChardevDummy', 'data': { } }
>>
>> Generates the obvious
>>
>> struct ChardevDummy
>> {
>> };
>>
>> They don't work here:
>>
>> { 'union': 'ChardevBackend', 'data': { 'file' : 'ChardevFile',
>>'hostdev': 'ChardevHostdev',
>>'socket' : 'ChardevSocket',
>>'pty': 'ChardevDummy',
>>'null' : {} } }
>>
>> Generates
>>
>> struct ChardevBackend
>> {
>> ChardevBackendKind kind;
>> union {
>> void *data;
>> ChardevFile * file;
>> ChardevHostdev * hostdev;
>> ChardevSocket * socket;
>> ChardevDummy * pty;
>> void null;
>> };
>> };
>>
>> which is kind of cute, but the compiler doesn't like it.
>>
>> Anthony, Mike, is this a bug?
>
> Not exactly, but it's a relic that doesn't seem to be needed anymore.
> The code that does this is in scripts/qapi.py:
>
> def c_type(name):
> ...
> elif name == None or len(name) == 0:
> return 'void'
> ...
> else:
> return '%s *' % name
>
> The 'name' param being the value/type of a particular param/key in a
> QAPI dictionary that defines a schema-defined type.
>
> The reason '{}' maps to 'void' is so that in qapi-commands.py, where we
> generate
> stuff like the function signatures for qmp commands, we'd map something like:
>
> { 'command': 'my_cmd',
> 'data': { 'param1': 'Foo' },
> 'returns': {} }
>
> to:
>
> void my_cmd(Foo *param1);
>
> At some point in development we rightly decided that:
>
> { 'command': 'my_cmd',
> 'data': { 'param1': 'Foo' } }
>
> was more efficient, which triggers the 'name == None' case and has the same
> effect.
>
> So, as long as we stay consistent about defining commands in this fashion, we
> can map 'param_name': {} to something like 'struct {}', and use it in place of
> schema-defined dummy types.
>
> Though, as I mentioned on IRC, I think just defining a:
>
> { 'type': 'Dummy', 'data' {} }
>
> Somewhere in the schema and re-using that might actually be cleaner and have
> the same affect.
Yes. I don't think we really ought to support inline structures. It
keeps the declarations easier to read to make all structs top level
types.
Regards,
Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4 RESEND v2 0/2] qtest: tmp105-test BE fix for 1.4
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for-1.4] libqtest: Fix documentation copy&paste errors
Applied. Thanks. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] pseries: Add cleanup hook for PAPR virtual LAN device
Am 11.02.2013 05:59, schrieb David Gibson: > 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 Tested-by: Andreas Färber On Anthony's request I posted a patch that adds back the if surrounding the cleanup callback, fixing also the other affected nics. 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
Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
Hi,
> But why nested discriminators?
>
> regular files: type=file
> serial : type=port, data.type=serial
> parallel : type=port, data.type=parallel
>
> Simpler, and closer to existing -chardev:
>
> regular files: type=file
> serial : type=serial
> parallel : type=parallel
Matter of taste IMHO.
I can live with that too.
Feel free to send patches.
> I also dislike the pointless '"data" : {}' required by type pty and
> null, but I can't figure out how to express 'void' in the schema.
Someone mentioned it is possible to leave out empty data altogether.
Didn't try whenever our marshaller actually accepts that though.
cheers,
Gerd
[Qemu-devel] [PULL 1.4 0/3] s390 patch queue 2013-02-12
Hi Blue / Aurelien, This is my current fix queue for s390 on 1.4. Please pull. Alex The following changes since commit 03ec2f83087de34924489eeae0ea6fe7785cc050: Kuo-Jung Su (1): hw/m25p80.c: add WRSR(0x01) support are available in the git repository at: git://repo.or.cz/qemu/agraf.git s390-for-upstream-1.4 Christian Borntraeger (1): s390/sclpconsole: prevent char layer callback during initialization Cornelia Huck (2): s390: Keep I/O interrupts enabled for all iscs. s390: Fix handling of iscs. hw/s390x/css.c |4 ++-- hw/s390x/sclpconsole.c |5 + target-s390x/cpu.h |2 +- target-s390x/helper.c | 45 + target-s390x/ioinst.h |3 +++ 5 files changed, 32 insertions(+), 27 deletions(-)
[Qemu-devel] [PATCH 3/3] s390: Fix handling of iscs.
From: Cornelia Huck
There are two ways to express an interruption subclass:
- As a bitmask, as used in cr6.
- As a number, as used in the I/O interruption word.
Unfortunately, we have treated to I/O interruption word as if it
contained the bitmask as well, which went unnoticed so far as
- (queued-for-next) kvm made the same mistake, and
- Linux guest kernels don't check the isc value in the I/O interruption
word for subchannel interrupts.
Make sure that we treat the I/O interruption word correctly.
Signed-off-by: Cornelia Huck
Signed-off-by: Alexander Graf
---
hw/s390x/css.c|4 ++--
target-s390x/cpu.h|2 +-
target-s390x/helper.c |5 -
target-s390x/ioinst.h |3 +++
4 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/s390x/css.c b/hw/s390x/css.c
index 3244201..85f6f22 100644
--- a/hw/s390x/css.c
+++ b/hw/s390x/css.c
@@ -87,7 +87,7 @@ static void css_inject_io_interrupt(SubchDev *sch)
css_build_subchannel_id(sch),
sch->schid,
sch->curr_status.pmcw.intparm,
- (0x80 >> isc) << 24);
+ isc << 27);
}
void css_conditional_io_interrupt(SubchDev *sch)
@@ -111,7 +111,7 @@ void css_conditional_io_interrupt(SubchDev *sch)
css_build_subchannel_id(sch),
sch->schid,
sch->curr_status.pmcw.intparm,
- (0x80 >> isc) << 24);
+ isc << 27);
}
}
diff --git a/target-s390x/cpu.h b/target-s390x/cpu.h
index 01e59b9..fa8dfe0 100644
--- a/target-s390x/cpu.h
+++ b/target-s390x/cpu.h
@@ -1001,7 +1001,7 @@ static inline void cpu_inject_io(S390CPU *cpu, uint16_t
subchannel_id,
uint32_t io_int_parm, uint32_t io_int_word)
{
CPUS390XState *env = &cpu->env;
-int isc = ffs(io_int_word << 2) - 1;
+int isc = IO_INT_WORD_ISC(io_int_word);
if (env->io_index[isc] == MAX_IO_QUEUE - 1) {
/* ugh - can't queue anymore. Let's drop. */
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 9f9088b..7626831 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -628,6 +628,8 @@ static void do_io_interrupt(CPUS390XState *env)
}
for (isc = 0; isc < ARRAY_SIZE(env->io_index); isc++) {
+uint64_t isc_bits;
+
if (env->io_index[isc] < 0) {
continue;
}
@@ -637,7 +639,8 @@ static void do_io_interrupt(CPUS390XState *env)
}
q = &env->io_queue[env->io_index[isc]][isc];
-if (!(env->cregs[6] & q->word)) {
+isc_bits = ISC_TO_ISC_BITS(IO_INT_WORD_ISC(q->word));
+if (!(env->cregs[6] & isc_bits)) {
disable = 0;
continue;
}
diff --git a/target-s390x/ioinst.h b/target-s390x/ioinst.h
index d5a43f4..7bed291 100644
--- a/target-s390x/ioinst.h
+++ b/target-s390x/ioinst.h
@@ -209,6 +209,9 @@ typedef struct IOIntCode {
#define IOINST_SCHID_SSID(_schid) ((_schid & 0x0006) >> 17)
#define IOINST_SCHID_NR(_schid)(_schid & 0x)
+#define IO_INT_WORD_ISC(_int_word) ((_int_word & 0x3800) >> 24)
+#define ISC_TO_ISC_BITS(_isc) ((0x80 >> _isc) << 24)
+
int ioinst_disassemble_sch_ident(uint32_t value, int *m, int *cssid, int *ssid,
int *schid);
int ioinst_handle_xsch(CPUS390XState *env, uint64_t reg1);
--
1.6.0.2
[Qemu-devel] [PATCH 2/3] s390: Keep I/O interrupts enabled for all iscs.
From: Cornelia Huck
do_io_interrupt() would stop scanning further iscs if it found
an I/O interrupt it could inject. This might cause the pending
interrupt indication for I/O interrupts to be reset although there
might be queued I/O interrupts for subsequent iscs.
Fix this by reordering the logic: Inject the I/O interrupt immediately
and continue searching all iscs for queued interrupts.
Signed-off-by: Cornelia Huck
Signed-off-by: Alexander Graf
---
target-s390x/helper.c | 40 +---
1 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/target-s390x/helper.c b/target-s390x/helper.c
index 043feb2..9f9088b 100644
--- a/target-s390x/helper.c
+++ b/target-s390x/helper.c
@@ -617,7 +617,6 @@ static void do_ext_interrupt(CPUS390XState *env)
static void do_io_interrupt(CPUS390XState *env)
{
-uint64_t mask = 0, addr = 0;
LowCore *lowcore;
IOIntQueue *q;
uint8_t isc;
@@ -642,36 +641,39 @@ static void do_io_interrupt(CPUS390XState *env)
disable = 0;
continue;
}
-found = 1;
-lowcore = cpu_map_lowcore(env);
+if (!found) {
+uint64_t mask, addr;
-lowcore->subchannel_id = cpu_to_be16(q->id);
-lowcore->subchannel_nr = cpu_to_be16(q->nr);
-lowcore->io_int_parm = cpu_to_be32(q->parm);
-lowcore->io_int_word = cpu_to_be32(q->word);
-lowcore->io_old_psw.mask = cpu_to_be64(get_psw_mask(env));
-lowcore->io_old_psw.addr = cpu_to_be64(env->psw.addr);
-mask = be64_to_cpu(lowcore->io_new_psw.mask);
-addr = be64_to_cpu(lowcore->io_new_psw.addr);
+found = 1;
+lowcore = cpu_map_lowcore(env);
-cpu_unmap_lowcore(lowcore);
+lowcore->subchannel_id = cpu_to_be16(q->id);
+lowcore->subchannel_nr = cpu_to_be16(q->nr);
+lowcore->io_int_parm = cpu_to_be32(q->parm);
+lowcore->io_int_word = cpu_to_be32(q->word);
+lowcore->io_old_psw.mask = cpu_to_be64(get_psw_mask(env));
+lowcore->io_old_psw.addr = cpu_to_be64(env->psw.addr);
+mask = be64_to_cpu(lowcore->io_new_psw.mask);
+addr = be64_to_cpu(lowcore->io_new_psw.addr);
-env->io_index[isc]--;
+cpu_unmap_lowcore(lowcore);
+
+env->io_index[isc]--;
+
+DPRINTF("%s: %" PRIx64 " %" PRIx64 "\n", __func__,
+env->psw.mask, env->psw.addr);
+load_psw(env, mask, addr);
+}
if (env->io_index[isc] >= 0) {
disable = 0;
}
-break;
+continue;
}
if (disable) {
env->pending_int &= ~INTERRUPT_IO;
}
-if (found) {
-DPRINTF("%s: %" PRIx64 " %" PRIx64 "\n", __func__,
-env->psw.mask, env->psw.addr);
-load_psw(env, mask, addr);
-}
}
static void do_mchk_interrupt(CPUS390XState *env)
--
1.6.0.2
[Qemu-devel] [PATCH 1/3] s390/sclpconsole: prevent char layer callback during initialization
From: Christian Borntraeger
Starting a qemu with an sclp console and pressing a key very early
can result in
"qemu-system-s390x: hw/s390x/sclpconsole.c:60: receive_from_chr_layer:
Assertion `scon->iov' failed."
Lets make sure that the init process is finished, since the iov is
allocated after CHR_EVENT_OPENED by also checking for scon->iov.
Signed-off-by: Christian Borntraeger
Signed-off-by: Alexander Graf
---
hw/s390x/sclpconsole.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/hw/s390x/sclpconsole.c b/hw/s390x/sclpconsole.c
index adc0ee8..effe511 100644
--- a/hw/s390x/sclpconsole.c
+++ b/hw/s390x/sclpconsole.c
@@ -44,12 +44,9 @@ typedef struct SCLPConsole {
/* Return number of bytes that fit into iov buffer */
static int chr_can_read(void *opaque)
{
-int can_read;
SCLPConsole *scon = opaque;
-can_read = SIZE_BUFFER_VT220 - scon->iov_data_len;
-
-return can_read;
+return scon->iov ? SIZE_BUFFER_VT220 - scon->iov_data_len : 0;
}
/* Receive n bytes from character layer, save in iov buffer,
--
1.6.0.2
Re: [Qemu-devel] [PATCH] pseries: Implements h_read hcall
On 07.02.2013, at 12:28, 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.
>
> 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)) {
> +target_ulong v, r;
> +target_ulong *pteh = &args[0];
> +target_ulong *ptel = &args[1];
> +
> +hpte = env->external_htab + (pte_index * HASH_PTE_SIZE_64);
You are not guaranteed that there is an external htab.
In fact, looking at the external_htab users, we should probably introduce a few
helper read functions for the htab that abstract the glorious
external_htab/htab_base details away from you.
Alex
Re: [Qemu-devel] [PATCH v1 1/2] dtc: add submodule
On 07.02.2013, at 07:08, Peter Crosthwaite wrote: > Add dtc submodule as a fallback for old distros. > Picking version 1.3.0. as this is the most recently tagged stable version. > > Signed-off-by: Peter Crosthwaite > --- > .gitmodules |3 +++ > dtc |1 + > 2 files changed, 4 insertions(+), 0 deletions(-) > create mode 16 dtc > > diff --git a/.gitmodules b/.gitmodules > index cfa2af9..b426ea6 100644 > --- a/.gitmodules > +++ b/.gitmodules > @@ -22,3 +22,6 @@ > [submodule "pixman"] > path = pixman > url = git://anongit.freedesktop.org/pixman > +[submodule "dtc"] > + path = dtc > + url = git://git.qemu.org/dtc.git > diff --git a/dtc b/dtc > new file mode 16 > index 000..bc895d6 > --- /dev/null > +++ b/dtc Maybe we shouldn't clutter our top level directory too much. Is there any chance we could move pixman out into a build-deps directory and put dtc in there too? Alex > @@ -0,0 +1 @@ > +Subproject commit bc895d6d09695d05ceb8b52486ffe861d6cfbdde > -- > 1.7.0.4 > >
Re: [Qemu-devel] [Qemu-ppc] [PATCH] target-ppc: Remove vestigial PowerPC 620 support (v2)
On 12.02.2013, at 23:16, Alexander Graf wrote:
>
> On 12.02.2013, at 11:23, Andreas Färber wrote:
>
>> Am 12.02.2013 03:16, schrieb David Gibson:
>>> 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
>>> ---
>>> v2: Don't remove the POWERPC_DEF()s from the table, just move them under
>>> #ifdef(TODO) to document the CPU's existence and aliases.
>> [...]
>>> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
>>> index 6cebaa1..1d2e842 100644
>>> --- a/target-ppc/translate_init.c
>>> +++ b/target-ppc/translate_init.c
>> [...]
>>> @@ -9244,11 +9000,11 @@ static const ppc_def_t ppc_defs[] = {
>>>POWERPC_DEF("7457A_v1.2",CPU_POWERPC_74x7A_v12, 7455),
>>>/* 64 bits PowerPC
>>> */
>>> #if defined (TARGET_PPC64)
>>> +#if defined (TODO)
>>
>> checkpatch.pl will surely complain about the space, and elsewhere the
>> #ifs are repeated per model/family. I.e., I would've expected one new
>> pair of #if defined(TODO) and #endif around the two 620 definitions. Or
>> does the already-TODO 630 model depend on the 620 code despite type 630?
>>
>>>/* PowerPC 620
>>> */
>>>POWERPC_DEF("620", CPU_POWERPC_620,620),
>>>/* Code name for PowerPC 620
>>> */
>>>POWERPC_DEF("Trident", CPU_POWERPC_620,620),
>>> -#if defined (TODO)
>>>/* PowerPC 630 (POWER3)
>>> */
>>>POWERPC_DEF("630", CPU_POWERPC_630,630),
>>>POWERPC_DEF("POWER3",CPU_POWERPC_630,630),
>> [snip]
>>
>> I've CC'ed you on the patchset that Alex and me had been preparing.
>> Let's leave it to Alex how to proceed with the conflicting patches.
>
> I would like to get the QOM'ification through first, then declare 620 as
> unsupported.
>
> David, I think the best way to proceed here would be to not touch anything in
> translate_init.c in your MMU cleanup patch set :). Or wouldn't that work?
Eh - you aren't touching anything there. It's all about this patch :). Oops.
Then yes, QOM first.
Alex
Re: [Qemu-devel] [PATCH] target-ppc: Remove vestigial PowerPC 620 support (v2)
On 12.02.2013, at 11:23, Andreas Färber wrote:
> Am 12.02.2013 03:16, schrieb David Gibson:
>> 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
>> ---
>> v2: Don't remove the POWERPC_DEF()s from the table, just move them under
>> #ifdef(TODO) to document the CPU's existence and aliases.
> [...]
>> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
>> index 6cebaa1..1d2e842 100644
>> --- a/target-ppc/translate_init.c
>> +++ b/target-ppc/translate_init.c
> [...]
>> @@ -9244,11 +9000,11 @@ static const ppc_def_t ppc_defs[] = {
>> POWERPC_DEF("7457A_v1.2",CPU_POWERPC_74x7A_v12, 7455),
>> /* 64 bits PowerPC
>> */
>> #if defined (TARGET_PPC64)
>> +#if defined (TODO)
>
> checkpatch.pl will surely complain about the space, and elsewhere the
> #ifs are repeated per model/family. I.e., I would've expected one new
> pair of #if defined(TODO) and #endif around the two 620 definitions. Or
> does the already-TODO 630 model depend on the 620 code despite type 630?
>
>> /* PowerPC 620
>> */
>> POWERPC_DEF("620", CPU_POWERPC_620,620),
>> /* Code name for PowerPC 620
>> */
>> POWERPC_DEF("Trident", CPU_POWERPC_620,620),
>> -#if defined (TODO)
>> /* PowerPC 630 (POWER3)
>> */
>> POWERPC_DEF("630", CPU_POWERPC_630,630),
>> POWERPC_DEF("POWER3",CPU_POWERPC_630,630),
> [snip]
>
> I've CC'ed you on the patchset that Alex and me had been preparing.
> Let's leave it to Alex how to proceed with the conflicting patches.
I would like to get the QOM'ification through first, then declare 620 as
unsupported.
David, I think the best way to proceed here would be to not touch anything in
translate_init.c in your MMU cleanup patch set :). Or wouldn't that work?
Alex
[Qemu-devel] [PATCH for-1.4] net: Avoid NULL function pointer dereference on cleanup
The pSeries machine and some other devices don't supply a cleanup
callback. Revert part of 1ceef9f27359cbe92ef124bf74de6f792e71f6fb that
started calling it unconditionally.
Cc: Jason Wang
Signed-off-by: Andreas Färber
---
net/net.c |4 +++-
1 Datei geändert, 3 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/net/net.c b/net/net.c
index f9e7136..be03a8d 100644
--- a/net/net.c
+++ b/net/net.c
@@ -287,7 +287,9 @@ static void qemu_cleanup_net_client(NetClientState *nc)
{
QTAILQ_REMOVE(&net_clients, nc, next);
-nc->info->cleanup(nc);
+if (nc->info->cleanup) {
+nc->info->cleanup(nc);
+}
}
static void qemu_free_net_client(NetClientState *nc)
--
1.7.10.4
[Qemu-devel] [Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()
Marking incomplete pending more information about the origin of u-boot.bin per comment #8. ** Changed in: qemu (Ubuntu) Status: Confirmed => Incomplete ** Changed in: qemu-linaro (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1062220 Title: qemu-system-arm crashed with SIGABRT in cpu_abort() Status in QEMU: New Status in “qemu” package in Ubuntu: Incomplete Status in “qemu-linaro” package in Ubuntu: Incomplete Bug description: -kernel u-boot.bin ProblemType: Crash DistroRelease: Ubuntu 12.10 Package: qemu-system 1.2.0-2012.09-0ubuntu1 ProcVersionSignature: Ubuntu 3.5.0-10.10-generic 3.5.1 Uname: Linux 3.5.0-10-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.6.1-0ubuntu1 Architecture: amd64 CrashCounter: 1 Date: Fri Oct 5 19:30:23 2012 ExecutablePath: /usr/bin/qemu-system-arm InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110804) ProcCmdline: qemu-system-arm -M versatilepb -kernel u-boot.bin Signal: 6 SourcePackage: qemu-linaro StacktraceTop: raise () from /lib/x86_64-linux-gnu/libc.so.6 abort () from /lib/x86_64-linux-gnu/libc.so.6 ?? () ?? () ?? () Title: qemu-system-arm crashed with SIGABRT in raise() UpgradeStatus: Upgraded to quantal on 2012-08-11 (54 days ago) UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare vboxusers To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1062220/+subscriptions
Re: [Qemu-devel] [PATCH for-1.4] target-ppc: Fix "G2leGP3" PVR
On 11.02.2013, at 21:54, Andreas Färber wrote:
> Unlike derived PVR constants mapped to CPU_POWERPC_G2LEgp3, the
> "G2leGP3" model definition itself used the CPU_POWERPC_G2LEgp1 PVR.
>
> Fixing this will allow to alias CPU_POWERPC_G2LEgp3-using types to
> "G2leGP3".
>
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Andreas Färber
Thanks, applied to ppc-next. This is not 1.4 material.
Alex
> ---
> target-ppc/translate_init.c |2 +-
> 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
>
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index 4a1e5a6..a05bb7b 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -8243,7 +8243,7 @@ static const ppc_def_t ppc_defs[] = {
> /* PowerPC G2LE GP1 core
> */
> POWERPC_DEF("G2leGP1", CPU_POWERPC_G2LEgp1,G2LE),
> /* PowerPC G2LE GP3 core
> */
> -POWERPC_DEF("G2leGP3", CPU_POWERPC_G2LEgp1,G2LE),
> +POWERPC_DEF("G2leGP3", CPU_POWERPC_G2LEgp3,G2LE),
> /* PowerPC MPC603 microcontrollers
> */
> /* MPC8240
> */
> POWERPC_DEF("MPC8240", CPU_POWERPC_MPC8240,603E),
> --
> 1.7.10.4
>
Re: [Qemu-devel] [PATCH for-1.4?] target-ppc: Fix CPU_POWERPC_MPC8547E
On 11.02.2013, at 21:53, Andreas Färber wrote:
> It was defined to ..._MPC8545E_v21 rather than ..._MPC8547E_v21.
> Due to both resolving to CPU_POWERPC_e500v2_v21 this did not show.
>
> Fixing this nontheless helps with QOM'ifying CPU aliases.
>
> Signed-off-by: Andreas Färber
Thanks, applied to ppc-next. This is not 1.4 material.
Alex
> ---
> target-ppc/translate_init.c |2 +-
> 1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
>
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index 6cebaa1..4a1e5a6 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -7282,7 +7282,7 @@ enum {
> #define CPU_POWERPC_MPC8545E_v10 CPU_POWERPC_e500v2_v10
> #define CPU_POWERPC_MPC8545E_v20 CPU_POWERPC_e500v2_v20
> #define CPU_POWERPC_MPC8545E_v21 CPU_POWERPC_e500v2_v21
> -#define CPU_POWERPC_MPC8547E CPU_POWERPC_MPC8545E_v21
> +#define CPU_POWERPC_MPC8547E CPU_POWERPC_MPC8547E_v21
> #define CPU_POWERPC_MPC8547E_v10 CPU_POWERPC_e500v2_v10
> #define CPU_POWERPC_MPC8547E_v20 CPU_POWERPC_e500v2_v20
> #define CPU_POWERPC_MPC8547E_v21 CPU_POWERPC_e500v2_v21
> --
> 1.7.10.4
>
Re: [Qemu-devel] [PATCH] pseries: Add cleanup hook for PAPR virtual LAN device
On 11.02.2013, at 05:59, David Gibson wrote:
> 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
The offending patch breaks more than just spapr. We need to revert the bit that
checks for the existence of a cleanup function.
However, I'll still apply this to ppc-next. It's a good idea to make the
cleanup function mandatory. In fact, couldn't we add a runtime check that
mandatory callback functions actually exist when registering a NetClientInfo?
Alex
> ---
> 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
>
Re: [Qemu-devel] uhci: cancel delay for unregistered queues
Hi, On 02/12/2013 05:46 PM, Gerd Hoffmann wrote: On 02/12/13 15:38, Jan Kiszka wrote: Hi, was just debugging a memory corruption of my USB driver inside QEMU - and so far only there: I have a queue registered with the UHCI controller on an input endpoint that continuously generates data. At some point my driver decides to stop reading and removes the QH (with a lot of TDs attached) from the schedule. The driver waits for the next frame, then releases the QH and its TDs. QEMU apparently takes a "few" more frames to consider this queue dead. In the meantime, it seems to happily fill the TD buffers with data. But those buffers are long returned to the guest pool of free memory, causing corruptions there. Try setting QH_VALID to 1. That should fix it, but has a high chance to break iso transfers. I guess we'll need different QH_VALID values depending on transfer type. Hans? Agree?n Er, this is tricky. The biggest problem here is that Linux unlinks and then *relinks* bulk-transfers on UHCI in some cases, and we should not cancel those, so as much I would like to set QH_VALID to 1, that is not really an option, as it *will* break Linux guests. OTOH guests may indeed assume that we stop processing a queue after 1 frame. The only fix I can think of is allocating a receive buffer inside the UHCI code for read transfers, and copy the result over to the guest memory when we are re-scanning the schedule, encounter the completed td and are going to signal its completion to the guest. Since we then do the write to guest mem from the schedule scan, that means we won't do it if the qh got unlinked, but we did not cancel the queue yet, avoiding the memory corruption. The extra memcpy this introduces should not be a big deal given the low speed of USB-1, The memory allocations / frees may have some measurable performance impact, but I think we can live with that. I'm wondering now if I'm (again) using the UHCI in an unorthodox way (at least I stopped doing multi-queues per endpoint), still must have a subtle bug in the guest, or if this is a fundamental problem of QEMU's UHCI model. Unorthodox probably as this didn't pop up before with any other guest. But I think uhci emulation is at fault this time. Agreed. How to you wait for the next frame? I hope using the frame number register? Regards, Hans
Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
Gerd Hoffmann writes:
> Hi,
>
>> Now let's take another step back: a character device is just a file.
>> Why can't we use plain ChardevFile for it?
>
> It's not.
A Unix character device is a special file.
> First, the file backend allows input and output being different files,
> and the input file is optional. That doesn't make sense for the
> parallel/serial port case.
>
> Second, it's actually more than a file. The guest can change device
> parameters such as the baudrate on the virtual device and qemu will
> apply those changes to the host device.
>
> IMO it is different enough to have its own type.
Special files support some special operations. I didn't propose to drop
support for the special operations and treat special files exactly like
regular files. I asked whether we really need a completely separate way
to configure them.
The argument for separate configuration is file's capability to split
input and output. Okay.
But why nested discriminators?
regular files: type=file
serial : type=port, data.type=serial
parallel : type=port, data.type=parallel
Simpler, and closer to existing -chardev:
regular files: type=file
serial : type=serial
parallel : type=parallel
I also dislike the pointless '"data" : {}' required by type pty and
null, but I can't figure out how to express 'void' in the schema.
[...]
Re: [Qemu-devel] [PATCH v1 2/2] configure/Make: Build libfdt from submodule DTC
On 07.02.2013, at 07:08, Peter Crosthwaite wrote:
> Configure to use the DTC submodule to build libfdt when no system libfdt
> is found. Prompt to install the DTC submodule if --enable-fdt is set but
> no DTC can be found.
>
> DTC has no out-of-tree build capability, so the configure will symlink
> the Makefile and scripts directory in the out of tree build directory
> and pass in all the needed DTC arguments to make out of tree build happen.
> Ideally we fix the DTC make to support out of tree, but did it this way to
> avoid commits to DTC.
>
> Signed-off-by: Peter Crosthwaite
> ---
> Makefile | 10 ++
> configure | 29 +
> 2 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 0d9099a..cfa77c7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -136,6 +136,15 @@ pixman/Makefile: $(SRC_PATH)/pixman/configure
> $(SRC_PATH)/pixman/configure:
> (cd $(SRC_PATH)/pixman; autoreconf -v --install)
>
> +DTC_MAKE_ARGS=-I$(SRC_PATH)/dtc VPATH=$(SRC_PATH)/dtc -C dtc V="$(V)"
> LIBFDT_srcdir=$(SRC_PATH)/dtc/libfdt
> +DTC_CFLAGS="$(CFLAGS) $(extra_cflags) -I$(BUILD_DIR)/dtc -I$(SRC_PATH)/dtc
> -I$(SRC_PATH)/dtc/libfdt"
> +
> +subdir-dtc:dtc/libfdt dtc/tests
> + $(call quiet-command,$(MAKE) $(DTC_MAKE_ARGS) CPPFLAGS=$(DTC_CFLAGS)
> CC=$(CC) AR=$(AR) LD=$(LD) $(SUBDIR_MAKEFLAGS) libfdt,)
I do remember that compiling pixman cross was having trouble. Have you verified
that it works here?
> +
> +dtc/%:
> + mkdir -p $@
> +
> $(SUBDIR_RULES): libqemuutil.a libqemustub.a $(common-obj-y)
>
> ROMSUBDIR_RULES=$(patsubst %,romsubdir-%, $(ROMS))
> @@ -253,6 +262,7 @@ distclean: clean
> rm -rf $$d || exit 1 ; \
> done
> if test -f pixman/config.log; then make -C pixman distclean; fi
> + if test -f dtc/version_gen.h; then make $(DTC_MAKE_ARGS) clean; fi
>
> KEYMAPS=da en-gb et fr fr-ch is lt modifiers no pt-br sv \
> ar de en-us fi fr-be hr it lv nl pl ru th \
> diff --git a/configure b/configure
> index 8789324..a0b265a 100755
> --- a/configure
> +++ b/configure
> @@ -2375,11 +2375,28 @@ if test "$fdt" != "no" ; then
> int main(void) { return 0; }
> EOF
> if compile_prog "" "$fdt_libs" ; then
> +#system DTC is good - use it
> fdt=yes
> - else
> -if test "$fdt" = "yes" ; then
> - feature_not_found "fdt"
> + elif test -d ${source_path}/dtc/libfdt ; then
> +#have submodule DTC - use it
> +fdt=yes
> +dtc_internal="yes"
> +mkdir -p dtc
Where does this get created? We need to make sure we compile into the foreign
object dir if the user provides one (I don't remember the details how that
worked though).
Alex
> +if [ "$source_path" != `pwd` ]; then
> + symlink "$source_path/dtc/Makefile" "dtc/Makefile"
> + symlink "$source_path/dtc/scripts" "dtc/scripts"
> fi
> +fdt_cflags="-I\$(SRC_PATH)/dtc/libfdt"
> +fdt_libs="-L\$(BUILD_DIR)/dtc/libfdt $fdt_libs"
> + elif test "$fdt" = "yes" ; then
> +#have neither and want - prompt for system/submodule install
> +echo "ERROR: DTC not present. Your options:"
> +echo " (1) Preferred: Install the DTC devel package"
> +echo " (2) Fetch the DTC submodule, using:"
> +echo " git submodule update --init dtc"
> +exit 1
> + else
> +#dont have and dont want
> fdt_libs=
> fdt=no
> fi
> @@ -3242,7 +3259,7 @@ if test "$cpu" = "ppc64" -a "$targetos" != "Darwin" ;
> then
> fi
>
> # add pixman flags after all config tests are done
> -QEMU_CFLAGS="$QEMU_CFLAGS $pixman_cflags"
> +QEMU_CFLAGS="$QEMU_CFLAGS $pixman_cflags $fdt_cflags"
> libs_softmmu="$libs_softmmu $pixman_libs"
>
> echo "Install prefix$prefix"
> @@ -4278,6 +4295,10 @@ if [ "$pixman" = "internal" ]; then
> echo "config-host.h: subdir-pixman" >> $config_host_mak
> fi
>
> +if [ "$dtc_internal" = "yes" ]; then
> + echo "config-host.h: subdir-dtc" >> $config_host_mak
> +fi
> +
> # build tree in object directory in case the source is not in the current
> directory
> DIRS="tests tests/tcg tests/tcg/cris tests/tcg/lm32"
> DIRS="$DIRS pc-bios/optionrom pc-bios/spapr-rtas"
> --
> 1.7.0.4
>
>
Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
On Tue, Feb 12, 2013 at 05:56:00PM +0100, Markus Armbruster wrote:
> Gerd Hoffmann writes:
>
> > Hi,
> >
> >> But why nested discriminators?
> >>
> >> regular files: type=file
> >> serial : type=port, data.type=serial
> >> parallel : type=port, data.type=parallel
> >>
> >> Simpler, and closer to existing -chardev:
> >>
> >> regular files: type=file
> >> serial : type=serial
> >> parallel : type=parallel
> >
> > Matter of taste IMHO.
> > I can live with that too.
> > Feel free to send patches.
> >
> >> I also dislike the pointless '"data" : {}' required by type pty and
> >> null, but I can't figure out how to express 'void' in the schema.
> >
> > Someone mentioned it is possible to leave out empty data altogether.
> > Didn't try whenever our marshaller actually accepts that though.
>
> Looks like it doesn't :(
>
> Empty objects work fine here:
>
> { 'type': 'ChardevDummy', 'data': { } }
>
> Generates the obvious
>
> struct ChardevDummy
> {
> };
>
> They don't work here:
>
> { 'union': 'ChardevBackend', 'data': { 'file' : 'ChardevFile',
>'hostdev': 'ChardevHostdev',
>'socket' : 'ChardevSocket',
>'pty': 'ChardevDummy',
>'null' : {} } }
>
> Generates
>
> struct ChardevBackend
> {
> ChardevBackendKind kind;
> union {
> void *data;
> ChardevFile * file;
> ChardevHostdev * hostdev;
> ChardevSocket * socket;
> ChardevDummy * pty;
> void null;
> };
> };
>
> which is kind of cute, but the compiler doesn't like it.
>
> Anthony, Mike, is this a bug?
Not exactly, but it's a relic that doesn't seem to be needed anymore.
The code that does this is in scripts/qapi.py:
def c_type(name):
...
elif name == None or len(name) == 0:
return 'void'
...
else:
return '%s *' % name
The 'name' param being the value/type of a particular param/key in a
QAPI dictionary that defines a schema-defined type.
The reason '{}' maps to 'void' is so that in qapi-commands.py, where we generate
stuff like the function signatures for qmp commands, we'd map something like:
{ 'command': 'my_cmd',
'data': { 'param1': 'Foo' },
'returns': {} }
to:
void my_cmd(Foo *param1);
At some point in development we rightly decided that:
{ 'command': 'my_cmd',
'data': { 'param1': 'Foo' } }
was more efficient, which triggers the 'name == None' case and has the same
effect.
So, as long as we stay consistent about defining commands in this fashion, we
can map 'param_name': {} to something like 'struct {}', and use it in place of
schema-defined dummy types.
Though, as I mentioned on IRC, I think just defining a:
{ 'type': 'Dummy', 'data' {} }
Somewhere in the schema and re-using that might actually be cleaner and have
the same affect.
Re: [Qemu-devel] [PATCH 0/2] small fixes for s390x
On 05.02.2013, at 09:53, Christian Borntraeger wrote:
> Alex,
>
> The following changes since commit 1143df5c72fd1f88b4b2b0774d11bf0ba6eb44d6:
>
> target-s390x: Pass S390CPU to s390_{add, del}_running_cpu() (2013-02-01
> 01:58:50 +0100)
>
> are available in the git repository at:
>
> g...@github.com:borntraeger/qemu.git for-s390-next
>
> for you to fetch changes up to 228ad1e8d81cd1444ab7a72d4edae7295898052b:
>
> s390: simplify kvm cpu init (2013-02-05 09:17:17 +0100)
Thanks, applied both to s390-next. The first one is a 1.4 candidate I suppose.
Alex
Re: [Qemu-devel] [PATCH V4 RESEND 09/22] net: multiqueue support
Am 01.02.2013 08:39, schrieb Jason Wang:
> diff --git a/net/net.c b/net/net.c
> index 98a1934..9806862 100644
> --- a/net/net.c
> +++ b/net/net.c
[...]
> @@ -271,9 +287,7 @@ static void qemu_cleanup_net_client(NetClientState *nc)
> {
> QTAILQ_REMOVE(&net_clients, nc, next);
>
> -if (nc->info->cleanup) {
> -nc->info->cleanup(nc);
> -}
> +nc->info->cleanup(nc);
> }
This change broke qemu-system-ppc64 -M pseries.
Why was the NULL guard dropped?
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 V4 RESEND 09/22] net: multiqueue support
On 01.02.2013, at 08:39, Jason Wang wrote:
> This patch adds basic multiqueue support for qemu. The idea is simple, an
> array
> of NetClientStates were introduced in NICState, parse_netdev() were extended
> to
> find and match all NetClientStates belongs to the backend and place their
> pointers in NICConf. Then qemu_new_nic can setup a N:N mapping between
> NICStates
> that belongs to a nic and NICStates belongs to the netdev. And a queue_index
> were introduced in NetClientState to track its index. After this, each peers
> of
> a NICState were abstracted as a queue.
>
> After this change, all NetClientState that belongs to the same backend/nic has
> the same id. When use want to change the link status, all NetClientStates that
> belongs to the same backend/nic will be also changed. When user want to delete
> a device or netdev, all NetClientStates that belongs to the same backend/nic
> will be deleted also. Changing or deleting an specific queue is not allowed.
>
> Signed-off-by: Jason Wang
> Signed-off-by: Michael S. Tsirkin
> ---
> hw/dp8393x.c|2 +-
> hw/mcf_fec.c|2 +-
> hw/qdev-properties-system.c | 46 +++---
> hw/qdev-properties.h|6 +-
> include/net/net.h | 18 +--
> net/net.c | 113 +++
> 6 files changed, 139 insertions(+), 48 deletions(-)
>
> diff --git a/hw/dp8393x.c b/hw/dp8393x.c
> index 0273fad..808157b 100644
> --- a/hw/dp8393x.c
> +++ b/hw/dp8393x.c
> @@ -900,7 +900,7 @@ void dp83932_init(NICInfo *nd, hwaddr base, int it_shift,
> s->regs[SONIC_SR] = 0x0004; /* only revision recognized by Linux */
>
> s->conf.macaddr = nd->macaddr;
> -s->conf.peer = nd->netdev;
> +s->conf.peers.ncs[0] = nd->netdev;
>
> s->nic = qemu_new_nic(&net_dp83932_info, &s->conf, nd->model, nd->name,
> s);
>
> diff --git a/hw/mcf_fec.c b/hw/mcf_fec.c
> index 909e32b..8e60f09 100644
> --- a/hw/mcf_fec.c
> +++ b/hw/mcf_fec.c
> @@ -472,7 +472,7 @@ void mcf_fec_init(MemoryRegion *sysmem, NICInfo *nd,
> memory_region_add_subregion(sysmem, base, &s->iomem);
>
> s->conf.macaddr = nd->macaddr;
> -s->conf.peer = nd->netdev;
> +s->conf.peers.ncs[0] = nd->netdev;
>
> s->nic = qemu_new_nic(&net_mcf_fec_info, &s->conf, nd->model, nd->name,
> s);
>
> diff --git a/hw/qdev-properties-system.c b/hw/qdev-properties-system.c
> index ce0f793..ce3af22 100644
> --- a/hw/qdev-properties-system.c
> +++ b/hw/qdev-properties-system.c
> @@ -173,16 +173,47 @@ PropertyInfo qdev_prop_chr = {
>
> static int parse_netdev(DeviceState *dev, const char *str, void **ptr)
> {
> -NetClientState *netdev = qemu_find_netdev(str);
> +NICPeers *peers_ptr = (NICPeers *)ptr;
> +NICConf *conf = container_of(peers_ptr, NICConf, peers);
> +NetClientState **ncs = peers_ptr->ncs;
> +NetClientState *peers[MAX_QUEUE_NUM];
> +int queues, i = 0;
> +int ret;
>
> -if (netdev == NULL) {
> -return -ENOENT;
> +queues = qemu_find_net_clients_except(str, peers,
> + NET_CLIENT_OPTIONS_KIND_NIC,
> + MAX_QUEUE_NUM);
> +if (queues == 0) {
> +ret = -ENOENT;
> +goto err;
> }
> -if (netdev->peer) {
> -return -EEXIST;
> +
> +if (queues > MAX_QUEUE_NUM) {
> +ret = -E2BIG;
> +goto err;
> +}
> +
> +for (i = 0; i < queues; i++) {
> +if (peers[i] == NULL) {
> +ret = -ENOENT;
> +goto err;
> +}
> +
> +if (peers[i]->peer) {
> +ret = -EEXIST;
> +goto err;
> +}
> +
> +ncs[i] = peers[i];
> +ncs[i]->queue_index = i;
> }
> -*ptr = netdev;
> +
> +conf->queues = queues;
> +
> return 0;
> +
> +err:
> +return ret;
> }
>
> static const char *print_netdev(void *ptr)
> @@ -249,7 +280,8 @@ static void set_vlan(Object *obj, Visitor *v, void
> *opaque,
> {
> DeviceState *dev = DEVICE(obj);
> Property *prop = opaque;
> -NetClientState **ptr = qdev_get_prop_ptr(dev, prop);
> +NICPeers *peers_ptr = qdev_get_prop_ptr(dev, prop);
> +NetClientState **ptr = &peers_ptr->ncs[0];
> Error *local_err = NULL;
> int32_t id;
> NetClientState *hubport;
> diff --git a/hw/qdev-properties.h b/hw/qdev-properties.h
> index ddcf774..20c67f3 100644
> --- a/hw/qdev-properties.h
> +++ b/hw/qdev-properties.h
> @@ -31,7 +31,7 @@ extern PropertyInfo qdev_prop_pci_host_devaddr;
> .name = (_name),\
> .info = &(_prop), \
> .offset= offsetof(_state, _field)\
> -+ type_check(_type,typeof_field(_state, _field)),\
> ++ type_check(_type, typeof_field(_state, _field)), \
> }
> #define DEFINE_PROP_DEFAULT(_name, _state, _field, _defval, _prop, _type) { \
Re: [Qemu-devel] [PATCH for-1.4 stable] block/curl: disable extra protocols to prevent CVE-2013-0249
Am 08.02.2013 08:49, schrieb Stefan Hajnoczi:
> There is a buffer overflow in libcurl POP3/SMTP/IMAP. The workaround is
> simple: disable extra protocols so that they cannot be exploited. Full
> details here:
>
> http://curl.haxx.se/docs/adv_20130206.html
>
> QEMU only cares about HTTP, HTTPS, FTP, FTPS, and TFTP. I have tested
> that this fix prevents the exploit on my host with
> libcurl-7.27.0-5.fc18.
>
> Signed-off-by: Stefan Hajnoczi
> ---
> The vulnerability public and is in libcurl, not QEMU. We can work around
> it in order to protect users whose machines have libcurl <7.29.
>
> Please add to QEMU 1.4-rc2.
Stefan, this seems to have broken my setup on Mac OS X. You seem to
require a newer version of cURL than configure checks...
Andreas
>
> Please add to stable.
> block/curl.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/block/curl.c b/block/curl.c
> index 47df952..f6226b3 100644
> --- a/block/curl.c
> +++ b/block/curl.c
> @@ -34,6 +34,10 @@
> #define DPRINTF(fmt, ...) do { } while (0)
> #endif
>
> +#define PROTOCOLS (CURLPROTO_HTTP | CURLPROTO_HTTPS | \
> + CURLPROTO_FTP | CURLPROTO_FTPS | \
> + CURLPROTO_TFTP)
> +
> #define CURL_NUM_STATES 8
> #define CURL_NUM_ACB8
> #define SECTOR_SIZE 512
> @@ -302,6 +306,13 @@ static CURLState *curl_init_state(BDRVCURLState *s)
> curl_easy_setopt(state->curl, CURLOPT_ERRORBUFFER, state->errmsg);
> curl_easy_setopt(state->curl, CURLOPT_FAILONERROR, 1);
>
> +/* Restrict supported protocols to avoid security issues in the more
> + * obscure protocols. For example, do not allow POP3/SMTP/IMAP see
> + * CVE-2013-0249.
> + */
> +curl_easy_setopt(state->curl, CURLOPT_PROTOCOLS, PROTOCOLS);
> +curl_easy_setopt(state->curl, CURLOPT_REDIR_PROTOCOLS, PROTOCOLS);
> +
> #ifdef DEBUG_VERBOSE
> curl_easy_setopt(state->curl, CURLOPT_VERBOSE, 1);
> #endif
>
--
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] [RFC PATCH RDMA support v2: 3/6] install new monitor commands and setup RDMA capabilities
Eric Blake writes: > On 02/11/2013 08:06 PM, Michael R. Hines wrote: > > [no need to top-post on a technical list] > >> None of the other migration QMP commands use dashes. > > Then how do you explain 'query-migrate', 'migrate-set-capabilities', > 'query-migrate-capabilities', 'migrate-set-cache-size', > 'query-migrate-cache-size'? I argue that 'migrate_cancel' and > 'migrate_set_downtime' are the odd ones out, and only because they were > written before our current policy of preferring dash. > >> Shouldn't I stay consistent with the other commands? > > Yes, which is why I'm arguing for using dash. Correct. Use dash instead of underscore for new commands and JSON object member names.
Re: [Qemu-devel] [PATCH] qemu-log: default to stderr for logging output
On 12 February 2013 18:16, Andreas Färber wrote: > Am 12.02.2013 18:58, schrieb Peter Maydell: >> Debug output will only appear on stderr if you asked for it by >> passing -d something. > I was thinking of default options, so if nothing gets printed by default > that's okay with me. Yep. If we ever add a -d logcategory which we want to have enabled by default we'll have to rejig things, because at the moment there are some users of the API which log things with no category [relying on the fact that unless the user specifies some -d option then no logging happens at all and so uncategorised log messages aren't printed either], and we'd need to move them all to some kind of "misc rubbish" category so they didn't appear by default. But I can't actually think of a log category we'd want to have defaulting to enabled anyway... -- PMM
Re: [Qemu-devel] [PATCH] qemu-log: default to stderr for logging output
Am 12.02.2013 18:58, schrieb Peter Maydell: > On 12 February 2013 17:50, Andreas Färber wrote: >> Am 12.02.2013 18:33, schrieb Peter Maydell: >>> Stefan suggested that qemu_log should default to stderr, and I >>> agree that it makes more sense than a random file in /tmp/. >>> As noted in the commit message, this is technically an incompatible >>> change. >> >> I don't think this change is okay, it should be limited to the softmmus. >> Having random debug output appear on stderr may well break linux-user >> test suites or use cases. > > Debug output will only appear on stderr if you asked for it by > passing -d something. This isn't any different to the softmmu > case (where it is also the case that random debug output might > break things, and also that you won't get it unless you ask). > > I agree that it might break weird use cases (where you're running > some existing scripted usecase with debug logging enabled for some > reason); the tradeoff for those people having to tweak their script > to add "-D /tmp/qemu.log" is that we make things better for the > common user who mostly doesn't run with debug but who can now run > with '-d unimp,guest_errors' and get those messages usefully > interspersed with guest output. I was thinking of default options, so if nothing gets printed by default that's okay with me. 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 V3 2/2] virtio-block: support auto-sensing of block sizes
On 08/02/13 15:52, Einar Lueck wrote:
> Virtio-blk does not impose fixed block sizes for access to
> backing devices. This patch introduces support for auto
> lookup of the block sizes of the backing block device. This
> automatic lookup needs to be enabled explicitly. Users may
> do this by specifying (physical|logical)_block_size=0.
> Machine types may do this for their defaults, too.
> To achieve this, a new function blkconf_blocksizes is
> implemented. If physical or logical block size are zero
> a corresponding ioctl tries to find an appropriate value.
> If this does not work, 512 is used. blkconf_blocksizes
> is therefore only called w/in the virtio-blk context.
> For s390-virtio, this patch configures auto lookup as
> default. For virtio-ccw, this is already a default in
> the existing upstream implementation.
>
> Signed-off-by: Einar Lueck
together with the patch below:
Reviewed-by: Christian Borntraeger
s390: enable block size auto-sensing also for virtio-ccw
The ccw transport for s390 should also enable block size
sensing.
Signed-off-by: Christian Borntraeger
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index d92e427..f6a08b2 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -731,7 +731,7 @@ static const TypeInfo virtio_ccw_net = {
static Property virtio_ccw_blk_properties[] = {
DEFINE_PROP_STRING("devno", VirtioCcwDevice, bus_id),
-DEFINE_BLOCK_PROPERTIES(VirtioCcwDevice, blk.conf),
+DEFINE_BLOCK_PROPERTIES_EXTENDED(VirtioCcwDevice, blk.conf, 0),
DEFINE_PROP_STRING("serial", VirtioCcwDevice, blk.serial),
#ifdef __linux__
DEFINE_PROP_BIT("scsi", VirtioCcwDevice, blk.scsi, 0, true),
Re: [Qemu-devel] [PATCH] qemu-log: default to stderr for logging output
On 12 February 2013 17:50, Andreas Färber wrote: > Am 12.02.2013 18:33, schrieb Peter Maydell: >> Stefan suggested that qemu_log should default to stderr, and I >> agree that it makes more sense than a random file in /tmp/. >> As noted in the commit message, this is technically an incompatible >> change. > > I don't think this change is okay, it should be limited to the softmmus. > Having random debug output appear on stderr may well break linux-user > test suites or use cases. Debug output will only appear on stderr if you asked for it by passing -d something. This isn't any different to the softmmu case (where it is also the case that random debug output might break things, and also that you won't get it unless you ask). I agree that it might break weird use cases (where you're running some existing scripted usecase with debug logging enabled for some reason); the tradeoff for those people having to tweak their script to add "-D /tmp/qemu.log" is that we make things better for the common user who mostly doesn't run with debug but who can now run with '-d unimp,guest_errors' and get those messages usefully interspersed with guest output. -- PMM
Re: [Qemu-devel] [PATCH] qemu-log: default to stderr for logging output
Am 12.02.2013 um 18:50 schrieb Andreas Färber : > Am 12.02.2013 18:33, schrieb Peter Maydell: >> Switch the default for qemu_log logging output from "/tmp/qemu.log" >> to stderr. This is an incompatible change in some sense, but logging >> is mostly used for debugging purposes so it shouldn't affect production >> use. The previous behaviour can be obtained by adding "-D /tmp/qemu.log" >> to the command line. >> >> This change requires us to: >> * update all the documentation/help text >> * make linux-user and bsd-user defer to qemu-log for the default >> logging destination rather than overriding it themselves >> * ensure that all logfile closing is done via qemu_log_close() >> and that that function doesn't close stderr >> as well as the obvious change to the behaviour of do_qemu_set_log() >> when no logfile name has been specified. >> >> Signed-off-by: Peter Maydell >> --- >> Stefan suggested that qemu_log should default to stderr, and I >> agree that it makes more sense than a random file in /tmp/. >> As noted in the commit message, this is technically an incompatible >> change. > > I don't think this change is okay, it should be limited to the softmmus. > Having random debug output appear on stderr may well break linux-user > test suites or use cases. But only when you pass in -d, no? Alex > > 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
Re: [Qemu-devel] [PATCH] qemu-log: default to stderr for logging output
Am 12.02.2013 18:33, schrieb Peter Maydell: > Switch the default for qemu_log logging output from "/tmp/qemu.log" > to stderr. This is an incompatible change in some sense, but logging > is mostly used for debugging purposes so it shouldn't affect production > use. The previous behaviour can be obtained by adding "-D /tmp/qemu.log" > to the command line. > > This change requires us to: > * update all the documentation/help text > * make linux-user and bsd-user defer to qemu-log for the default >logging destination rather than overriding it themselves > * ensure that all logfile closing is done via qemu_log_close() >and that that function doesn't close stderr > as well as the obvious change to the behaviour of do_qemu_set_log() > when no logfile name has been specified. > > Signed-off-by: Peter Maydell > --- > Stefan suggested that qemu_log should default to stderr, and I > agree that it makes more sense than a random file in /tmp/. > As noted in the commit message, this is technically an incompatible > change. I don't think this change is okay, it should be limited to the softmmus. Having random debug output appear on stderr may well break linux-user test suites or use cases. 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
Re: [Qemu-devel] [PATCH] qemu-log: Remove qemu_log_try_set_file() and its users
Am 12.02.2013 17:13, schrieb Peter Maydell: > Remove the function qemu_log_try_set_file() and its users (which > are all in TCG code generation functions for various targets). > This function was added to abstract out code which was originally > written as "if (!logfile) logfile = stderr;" in order that BUG: > case code which did an unguarded "fprintf(logfile, ...)" would > not crash if debug logging was not enabled. Since those direct > uses of logfile have also been abstracted away into qemu_log() > calls which check for a NULL logfile, there is no need for the > target-* files to mess with the user's chosen logging settings. > > Signed-off-by: Peter Maydell Reviewed-by: Andreas Färber 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] qemu-log: default to stderr for logging output
Switch the default for qemu_log logging output from "/tmp/qemu.log"
to stderr. This is an incompatible change in some sense, but logging
is mostly used for debugging purposes so it shouldn't affect production
use. The previous behaviour can be obtained by adding "-D /tmp/qemu.log"
to the command line.
This change requires us to:
* update all the documentation/help text
* make linux-user and bsd-user defer to qemu-log for the default
logging destination rather than overriding it themselves
* ensure that all logfile closing is done via qemu_log_close()
and that that function doesn't close stderr
as well as the obvious change to the behaviour of do_qemu_set_log()
when no logfile name has been specified.
Signed-off-by: Peter Maydell
---
Stefan suggested that qemu_log should default to stderr, and I
agree that it makes more sense than a random file in /tmp/.
As noted in the commit message, this is technically an incompatible
change.
This patchset sits on top of my recent 6 patch qemu_log
cleanup series.
bsd-user/main.c| 15 +++
hmp-commands.hx|4 ++--
include/qemu/log.h |8 ++--
linux-user/main.c | 14 --
qemu-doc.texi |8
qemu-log.c | 29 +++--
qemu-options.hx| 10 +-
tcg/tci/README |2 +-
8 files changed, 40 insertions(+), 50 deletions(-)
diff --git a/bsd-user/main.c b/bsd-user/main.c
index 097fbfe..1ec8636 100644
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -34,8 +34,6 @@
#include "qemu/timer.h"
#include "qemu/envlist.h"
-#define DEBUG_LOGFILE "/tmp/qemu.log"
-
int singlestep;
#if defined(CONFIG_USE_GUEST_BASE)
unsigned long mmap_min_addr;
@@ -691,8 +689,8 @@ static void usage(void)
"-bsd type select emulated BSD type FreeBSD/NetBSD/OpenBSD
(default)\n"
"\n"
"Debug options:\n"
- "-d options activate log (default logfile=%s)\n"
- "-D logfile override default logfile location\n"
+ "-d options activate log (default is to log to stderr)\n"
+ "-D logfile write logs to 'logfile' rather than stderr\n"
"-p pagesize set the host page size to 'pagesize'\n"
"-singlestep always run in singlestep mode\n"
"-strace log system calls\n"
@@ -709,8 +707,7 @@ static void usage(void)
,
TARGET_ARCH,
interp_prefix,
- x86_stack_size,
- DEBUG_LOGFILE);
+ x86_stack_size);
exit(1);
}
@@ -733,7 +730,7 @@ int main(int argc, char **argv)
{
const char *filename;
const char *cpu_model;
-const char *log_file = DEBUG_LOGFILE;
+const char *log_file = NULL;
const char *log_mask = NULL;
struct target_pt_regs regs1, *regs = ®s1;
struct image_info info1, *info = &info1;
@@ -861,7 +858,9 @@ int main(int argc, char **argv)
}
/* init debug */
-qemu_set_log_filename(log_file);
+if (log_file) {
+qemu_set_log_filename(log_file);
+}
if (log_mask) {
int mask;
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 64008a9..cef7708 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -295,14 +295,14 @@ ETEXI
.name = "log",
.args_type = "items:s",
.params = "item1[,...]",
-.help = "activate logging of the specified items to
'/tmp/qemu.log'",
+.help = "activate logging of the specified items",
.mhandler.cmd = do_log,
},
STEXI
@item log @var{item1}[,...]
@findex log
-Activate logging of the specified items to @file{/tmp/qemu.log}.
+Activate logging of the specified items.
ETEXI
{
diff --git a/include/qemu/log.h b/include/qemu/log.h
index 4527003..6b0db02 100644
--- a/include/qemu/log.h
+++ b/include/qemu/log.h
@@ -116,8 +116,12 @@ static inline void qemu_log_flush(void)
/* Close the log file */
static inline void qemu_log_close(void)
{
-fclose(qemu_logfile);
-qemu_logfile = NULL;
+if (qemu_logfile) {
+if (qemu_logfile != stderr) {
+fclose(qemu_logfile);
+}
+qemu_logfile = NULL;
+}
}
/* Set up a new log file */
diff --git a/linux-user/main.c b/linux-user/main.c
index 8a61ea4..55e8326 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -35,8 +35,6 @@
#include "qemu/envlist.h"
#include "elf.h"
-#define DEBUG_LOGFILE "/tmp/qemu.log"
-
char *exec_path;
int singlestep;
@@ -3289,9 +3287,9 @@ static const struct qemu_argument arg_table[] = {
"size", "reserve 'size' bytes for guest virtual address space"},
#endif
{"d", "QEMU_LOG", true, handle_arg_log,
- "options","activate log"},
+ "options","activate log (default is to log to stderr)"},
{"D", "QEMU_LOG_FILENAME", true, handle_arg_log_filename,
- "logfile", "override default logfile location"},
+ "logfile", "log to specified file rather than
[Qemu-devel] [PATCH V2 for-1.5] virtio: make virtio device's structures public.
From: KONRAD Frederic
These structures must be made public to avoid two memory allocations for
refactored virtio devices.
Changes V2 <- V1:
* Move the dataplane include into the header (virtio-blk).
Signed-off-by: KONRAD Frederic
---
hw/virtio-balloon.c| 15 ---
hw/virtio-balloon.h| 14 ++
hw/virtio-blk.c| 19 ---
hw/virtio-blk.h| 18 ++
hw/virtio-net.c| 50 -
hw/virtio-net.h| 51 ++
hw/virtio-rng.c| 19 ---
hw/virtio-rng.h| 19 +++
hw/virtio-scsi.c | 15 ---
hw/virtio-scsi.h | 16
hw/virtio-serial-bus.c | 41
hw/virtio-serial.h | 41
12 files changed, 159 insertions(+), 159 deletions(-)
diff --git a/hw/virtio-balloon.c b/hw/virtio-balloon.c
index c0a7902..c2ad249 100644
--- a/hw/virtio-balloon.c
+++ b/hw/virtio-balloon.c
@@ -29,21 +29,6 @@
#include
#endif
-typedef struct VirtIOBalloon
-{
-VirtIODevice vdev;
-VirtQueue *ivq, *dvq, *svq;
-uint32_t num_pages;
-uint32_t actual;
-uint64_t stats[VIRTIO_BALLOON_S_NR];
-VirtQueueElement stats_vq_elem;
-size_t stats_vq_offset;
-QEMUTimer *stats_timer;
-int64_t stats_last_update;
-int64_t stats_poll_interval;
-DeviceState *qdev;
-} VirtIOBalloon;
-
static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
{
return (VirtIOBalloon *)vdev;
diff --git a/hw/virtio-balloon.h b/hw/virtio-balloon.h
index b1828f4..579a1e5 100644
--- a/hw/virtio-balloon.h
+++ b/hw/virtio-balloon.h
@@ -52,4 +52,18 @@ typedef struct VirtIOBalloonStat {
uint64_t val;
} QEMU_PACKED VirtIOBalloonStat;
+typedef struct VirtIOBalloon {
+VirtIODevice vdev;
+VirtQueue *ivq, *dvq, *svq;
+uint32_t num_pages;
+uint32_t actual;
+uint64_t stats[VIRTIO_BALLOON_S_NR];
+VirtQueueElement stats_vq_elem;
+size_t stats_vq_offset;
+QEMUTimer *stats_timer;
+int64_t stats_last_update;
+int64_t stats_poll_interval;
+DeviceState *qdev;
+} VirtIOBalloon;
+
#endif
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 34913ee..dc8f5a2 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -17,30 +17,11 @@
#include "hw/block-common.h"
#include "sysemu/blockdev.h"
#include "virtio-blk.h"
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-#include "hw/dataplane/virtio-blk.h"
-#endif
#include "scsi-defs.h"
#ifdef __linux__
# include
#endif
-typedef struct VirtIOBlock
-{
-VirtIODevice vdev;
-BlockDriverState *bs;
-VirtQueue *vq;
-void *rq;
-QEMUBH *bh;
-BlockConf *conf;
-VirtIOBlkConf *blk;
-unsigned short sector_mask;
-DeviceState *qdev;
-#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
-VirtIOBlockDataPlane *dataplane;
-#endif
-} VirtIOBlock;
-
static VirtIOBlock *to_virtio_blk(VirtIODevice *vdev)
{
return (VirtIOBlock *)vdev;
diff --git a/hw/virtio-blk.h b/hw/virtio-blk.h
index 43ca492..fc6765b 100644
--- a/hw/virtio-blk.h
+++ b/hw/virtio-blk.h
@@ -16,6 +16,9 @@
#include "virtio.h"
#include "hw/block-common.h"
+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+#include "hw/dataplane/virtio-blk.h"
+#endif
/* from Linux's linux/virtio_blk.h */
@@ -108,6 +111,21 @@ struct VirtIOBlkConf
uint32_t data_plane;
};
+typedef struct VirtIOBlock {
+VirtIODevice vdev;
+BlockDriverState *bs;
+VirtQueue *vq;
+void *rq;
+QEMUBH *bh;
+BlockConf *conf;
+VirtIOBlkConf *blk;
+unsigned short sector_mask;
+DeviceState *qdev;
+#ifdef CONFIG_VIRTIO_BLK_DATA_PLANE
+VirtIOBlockDataPlane *dataplane;
+#endif
+} VirtIOBlock;
+
#define DEFINE_VIRTIO_BLK_FEATURES(_state, _field) \
DEFINE_VIRTIO_COMMON_FEATURES(_state, _field)
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 573c669..32fc8fe 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -26,56 +26,6 @@
#define MAC_TABLE_ENTRIES64
#define MAX_VLAN(1 << 12) /* Per 802.1Q definition */
-typedef struct VirtIONetQueue {
-VirtQueue *rx_vq;
-VirtQueue *tx_vq;
-QEMUTimer *tx_timer;
-QEMUBH *tx_bh;
-int tx_waiting;
-struct {
-VirtQueueElement elem;
-ssize_t len;
-} async_tx;
-struct VirtIONet *n;
-} VirtIONetQueue;
-
-typedef struct VirtIONet
-{
-VirtIODevice vdev;
-uint8_t mac[ETH_ALEN];
-uint16_t status;
-VirtIONetQueue vqs[MAX_QUEUE_NUM];
-VirtQueue *ctrl_vq;
-NICState *nic;
-uint32_t tx_timeout;
-int32_t tx_burst;
-uint32_t has_vnet_hdr;
-size_t host_hdr_len;
-size_t guest_hdr_len;
-uint8_t has_ufo;
-int mergeable_rx_bufs;
-uint8_t promisc;
-uint8_t allmulti;
-uint8_t alluni;
-uint8_t nomulti;
-uint8_t nouni;
-uint8_t nobcast;
-uint8_t vhost_started;
-struct {
-int in_use;
-i
[Qemu-devel] [Bug 1110531] Re: regression booting pxa kernels
** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1110531 Title: regression booting pxa kernels Status in QEMU: Fix Committed Bug description: Somewhere between qemu 1.1.2 and 1.2.0 OpenBSD zaurus kernels and ramdisk images stopped booting properly and instead end up in the kernel debugger. This behaviour is still present in the latest git and appears to have been introduced in: commit e2f8a44d0d425a22cca5855702f534536f5e8c90 Author: Peter Maydell Date: Wed Jun 20 11:57:07 2012 + hw/pxa2xx.c: Convert CLKCFG and PWRMODE cp14 regs Convert the PXA2xx CLKCFG and PWRMODE cp14 registers to the new arm_cp_reginfo scheme. Signed-off-by: Peter Maydell To duplicate this behaviour: http://ftp.openbsd.org/pub/OpenBSD/5.2/zaurus/bsd.rd $ qemu-system-arm -M spitz -serial stdio -kernel bsd.rd -portrait should boot to an install prompt. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1110531/+subscriptions
[Qemu-devel] [Bug 986241] Re: Misspelling of env parameter in deregister_dtl() [hw/spapr_hcall.c]
Fixed upstream as of this patch: http://git.qemu.org/?p=qemu-stable-1.2.git;a=commitdiff;h=73f7821baca8ec063ace277539bedeb286663965;hp=7fb0bd3473dfb2bb1768072ebbfa5771e8c8af4a -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/986241 Title: Misspelling of env parameter in deregister_dtl() [hw/spapr_hcall.c] Status in QEMU: New Bug description: Looks like there is a simple misspelling of the env parameter, as "emv", in hw/spapr_hcall.c:485: static target_ulong deregister_dtl(CPUPPCState *emv, target_ulong addr) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/986241/+subscriptions
Re: [Qemu-devel] [RFC PATCH RDMA support v2: 3/6] install new monitor commands and setup RDMA capabilities
On 02/11/2013 08:06 PM, Michael R. Hines wrote: [no need to top-post on a technical list] > None of the other migration QMP commands use dashes. Then how do you explain 'query-migrate', 'migrate-set-capabilities', 'query-migrate-capabilities', 'migrate-set-cache-size', 'query-migrate-cache-size'? I argue that 'migrate_cancel' and 'migrate_set_downtime' are the odd ones out, and only because they were written before our current policy of preferring dash. > Shouldn't I stay consistent with the other commands? Yes, which is why I'm arguing for using dash. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2] bswap: Fix width of swap in leul_to_cpu
On 2013-02-12 04:33, Jay Foad wrote: The comment's wrong, isn't it? The reason we're not using HOST_LONG_BITS is because it's the wrong thing, not because of any include loops. Err, well, yes. But there *was* an include loop when we were using that symbol. Feel free to push a comment fix through trivial... r~
Re: [Qemu-devel] [PATCH for-1.4] qapi: Improve chardev-add documentation
Gerd Hoffmann writes:
> Hi,
>
>> But why nested discriminators?
>>
>> regular files: type=file
>> serial : type=port, data.type=serial
>> parallel : type=port, data.type=parallel
>>
>> Simpler, and closer to existing -chardev:
>>
>> regular files: type=file
>> serial : type=serial
>> parallel : type=parallel
>
> Matter of taste IMHO.
> I can live with that too.
> Feel free to send patches.
>
>> I also dislike the pointless '"data" : {}' required by type pty and
>> null, but I can't figure out how to express 'void' in the schema.
>
> Someone mentioned it is possible to leave out empty data altogether.
> Didn't try whenever our marshaller actually accepts that though.
Looks like it doesn't :(
Empty objects work fine here:
{ 'type': 'ChardevDummy', 'data': { } }
Generates the obvious
struct ChardevDummy
{
};
They don't work here:
{ 'union': 'ChardevBackend', 'data': { 'file' : 'ChardevFile',
'hostdev': 'ChardevHostdev',
'socket' : 'ChardevSocket',
'pty': 'ChardevDummy',
'null' : {} } }
Generates
struct ChardevBackend
{
ChardevBackendKind kind;
union {
void *data;
ChardevFile * file;
ChardevHostdev * hostdev;
ChardevSocket * socket;
ChardevDummy * pty;
void null;
};
};
which is kind of cute, but the compiler doesn't like it.
Anthony, Mike, is this a bug?
Re: [Qemu-devel] [RFC ppc-next 39/39] target-ppc: Convert CPU definitions
Am 12.02.2013 11:13, schrieb Andreas Färber:
> Turn the array of model definitions into a set of self-registering QOM
> types with their own class_init. Unique identifiers are obtained from
> the combination of PVR, SVR and family identifiers; this requires all
> alias #defines to be removed from the list. Possibly there are some more
> left after this commit that are not currently being compiled.
>
> Prepares for introducing abstract intermediate CPU types for families.
>
> Keep the right-aligned macro line breaks within 78 chars to aid
> three-way merges.
>
> Signed-off-by: Andreas Färber
> ---
> target-ppc/cpu-qom.h| 17 -
> target-ppc/cpu.h| 20 --
> target-ppc/translate_init.c | 152
> ---
> 3 Dateien geändert, 85 Zeilen hinzugefügt(+), 104 Zeilen entfernt(-)
[...]
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index fd8bf00..93e38ba 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
[...]
> @@ -10316,20 +10317,7 @@ static const TypeInfo ppc_cpu_type_info = {
>
> static void ppc_cpu_register_types(void)
> {
> -int i;
> -
> type_register_static(&ppc_cpu_type_info);
> -
> -for (i = 0; i < ARRAY_SIZE(ppc_defs); i++) {
> -const ppc_def_t *def = &ppc_defs[i];
> -#if defined(TARGET_PPCEMB)
> -/* When using the ppcemb target, we only support 440 style cores */
> -if (def->mmu_model != POWERPC_MMU_BOOKE) {
> -continue;
> -}
> -#endif
> -ppc_cpu_register_model(def);
> -}
> }
>
> type_init(ppc_cpu_register_types)
Sorry, I forgot to re-add the TARGET_PPCEMB check above.
Still need to think about how to do that inside POWERPC_DEF_SVR() macro.
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] uhci: cancel delay for unregistered queues
On 02/12/13 15:38, Jan Kiszka wrote: > Hi, > > was just debugging a memory corruption of my USB driver inside QEMU - > and so far only there: > > I have a queue registered with the UHCI controller on an input endpoint > that continuously generates data. At some point my driver decides to > stop reading and removes the QH (with a lot of TDs attached) from the > schedule. The driver waits for the next frame, then releases the QH and > its TDs. > > QEMU apparently takes a "few" more frames to consider this queue dead. > In the meantime, it seems to happily fill the TD buffers with data. But > those buffers are long returned to the guest pool of free memory, > causing corruptions there. Try setting QH_VALID to 1. That should fix it, but has a high chance to break iso transfers. I guess we'll need different QH_VALID values depending on transfer type. Hans? Agree? > I'm wondering now if I'm (again) using the UHCI in an unorthodox way (at > least I stopped doing multi-queues per endpoint), still must have a > subtle bug in the guest, or if this is a fundamental problem of QEMU's > UHCI model. Unorthodox probably as this didn't pop up before with any other guest. But I think uhci emulation is at fault this time. How to you wait for the next frame? I hope using the frame number register? I guess this is with usb-host? cheers, Gerd
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Stefan Weil writes: > Hi Jeff, > > the scenario which you describe here is not one which I'd call > "realistic". Why should a user create a VHD image with VPC [...] Maybe, but why run a risk for 1.4? Let's delay your fix to 1.5. Gives us plenty of time to hash out the issues.
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Am 12.02.2013 16:18, schrieb Jeff Cody: > On Tue, Feb 12, 2013 at 03:47:38PM +0100, Stefan Weil wrote: >> Am 11.02.2013 22:20, schrieb Jeff Cody: >>> On Mon, Feb 11, 2013 at 03:14:36PM -0600, Anthony Liguori wrote: Paolo Bonzini writes: > Il 11/02/2013 21:13, Anthony Liguori ha scritto: >> Applied. Thanks. >> >> Regards, >> >> Anthony Liguori > I guess this was a mistake, please revert. No, it wasn't. The patch was reviewed and tested. What's the problem. It's proposed for 1.4 so it's now or never. I saw some discussion about improving the detection for the different varients of VHD... I don't mind reverting it, but just want to understand what the issue is. >>> Hi Anthony, >>> >>> It was tested, the problem is that this will break existing support >>> for Virtual PC VHD files under certain conditions (most likely >>> exporting from qemu to VPC, but I don't know if we could guarantee >>> that is the only way). >>> >>> >>> Jeff >> Hi Jeff, >> >> exporting from QEMU to VPCwill work because QEMU uses >> images where real size = CHS size, so those images work >> no matter whether the patch was applied or not. >> >> See my separate mail for more reasoning. >> >> I see no way how the patch could break a realistic test scenario, >> but I know such scenarios which are broken without the patch. >> >> >> Stefan >> > Hi Stefan, > > I should have been clearer when I said export - I am talking about > qemu modifying an existing VHD image created by VPC, and then trying > to use image in VPC again. > > Here is a simple way to see how the proposed patch breaks current VHD > compatibility: > > 1.) Under VPC, define a new VM that boots from a live dvd iso (I used > a puppy linux iso because it was small and quick to test: > http://puppylinux.org). For the hard drive for the machine, define a > 128GB dynamic drive. (test.vhd). You don't need to boot this VM yet. > > 2.) Now, under QEMU, boot again to a live iso or existing linux image, > and use the newly created test.vhd. Create a single partition, using > the fdisk defaults for the maximum size. Shutdown. > > 3.) Use that same VHD image and boot the live iso with your VPC > machine. Try to mount the partition you created under qemu with the > guest in VPC. It will fail to detect the partition, and complain > about invalid geometry. > > I think your patch is definitely needed, don't get me wrong, and I can > verify that it works - for the bug report, I even came to the same > conclusion. I just think it needs to be done such that we don't break > something that used to work, and testing shows that it does, > unfortunately. > > Thanks, > Jeff Hi Jeff, the scenario which you describe here is not one which I'd call "realistic". Why should a user create a VHD image with VPC and then create the partitions using QEMU?Yes, if this is done, the image is no longer compatible with VPC as soon as blocks after the CHS size are used. The same kind of problem would occur if Hyper-V or VirtualBox were use instead of QEMU. I expect that the common use case is a user who creates and uses a VHD image with VPC (this includes partitioning). This kind of image can later be used with QEMU, VirtualBox or Hyper-V without problems as long as the partitions are not modified to use the additional blocks which are available after the CHS size. This restriction seems acceptable for me. I see no way to avoid it. The same kind of restriction exists for real hardware since the introduction of LBA as soon as software (BIOS, bootloaders, DOS, ...) tried using CHS. Regards, Stefan
[Qemu-devel] [PATCH] qemu-log: Remove qemu_log_try_set_file() and its users
Remove the function qemu_log_try_set_file() and its users (which
are all in TCG code generation functions for various targets).
This function was added to abstract out code which was originally
written as "if (!logfile) logfile = stderr;" in order that BUG:
case code which did an unguarded "fprintf(logfile, ...)" would
not crash if debug logging was not enabled. Since those direct
uses of logfile have also been abstracted away into qemu_log()
calls which check for a NULL logfile, there is no need for the
target-* files to mess with the user's chosen logging settings.
Signed-off-by: Peter Maydell
---
include/qemu/log.h|8
target-cris/translate.c |2 --
target-lm32/translate.c |2 --
target-microblaze/translate.c |2 --
target-openrisc/translate.c |2 --
5 files changed, 16 deletions(-)
diff --git a/include/qemu/log.h b/include/qemu/log.h
index 5a46555..4527003 100644
--- a/include/qemu/log.h
+++ b/include/qemu/log.h
@@ -126,14 +126,6 @@ static inline void qemu_log_set_file(FILE *f)
qemu_logfile = f;
}
-/* Set up a new log file, only if none is set */
-static inline void qemu_log_try_set_file(FILE *f)
-{
-if (!qemu_logfile) {
-qemu_logfile = f;
-}
-}
-
/* define log items */
typedef struct QEMULogItem {
int mask;
diff --git a/target-cris/translate.c b/target-cris/translate.c
index 09e6011..2964a21 100644
--- a/target-cris/translate.c
+++ b/target-cris/translate.c
@@ -3215,8 +3215,6 @@ gen_intermediate_code_internal(CPUCRISState *env,
TranslationBlock *tb,
int num_insns;
int max_insns;
-qemu_log_try_set_file(stderr);
-
if (env->pregs[PR_VR] == 32) {
dc->decoder = crisv32_decoder;
dc->clear_locked_irq = 0;
diff --git a/target-lm32/translate.c b/target-lm32/translate.c
index 6b87340..ccaf838 100644
--- a/target-lm32/translate.c
+++ b/target-lm32/translate.c
@@ -1012,8 +1012,6 @@ static void gen_intermediate_code_internal(CPULM32State
*env,
int num_insns;
int max_insns;
-qemu_log_try_set_file(stderr);
-
pc_start = tb->pc;
dc->env = env;
dc->tb = tb;
diff --git a/target-microblaze/translate.c b/target-microblaze/translate.c
index 58ce712..0b05264 100644
--- a/target-microblaze/translate.c
+++ b/target-microblaze/translate.c
@@ -1734,8 +1734,6 @@ gen_intermediate_code_internal(CPUMBState *env,
TranslationBlock *tb,
int num_insns;
int max_insns;
-qemu_log_try_set_file(stderr);
-
pc_start = tb->pc;
dc->env = env;
dc->tb = tb;
diff --git a/target-openrisc/translate.c b/target-openrisc/translate.c
index 1e1b30c..23e853e 100644
--- a/target-openrisc/translate.c
+++ b/target-openrisc/translate.c
@@ -1670,8 +1670,6 @@ static inline void
gen_intermediate_code_internal(OpenRISCCPU *cpu,
int num_insns;
int max_insns;
-qemu_log_try_set_file(stderr);
-
pc_start = tb->pc;
dc->tb = tb;
--
1.7.9.5
Re: [Qemu-devel] [PATCH v2] bswap: Fix width of swap in leul_to_cpu
Am 12.02.2013 13:33, schrieb Jay Foad: >> +#if ULONG_MAX == UINT32_MAX >> +return le_bswap(v, 32); >> +#elif ULONG_MAX == UINT64_MAX >> +return le_bswap(v, 64); >> +#else >> +# error Unknown sizeof long >> +#endif > > Is there any reason this can't be simplified to something like: > > return le_bswap(v, 8 * sizeof v); > > ? Yes, le_bswap() is a macro that uses glue() to get bswap64 / bswap32. 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 V3 2/2] virtio-block: support auto-sensing of block sizes
On Fri, Feb 08, 2013 at 03:52:35PM +0100, Einar Lueck wrote:
> @@ -22,6 +25,26 @@ void blkconf_serial(BlockConf *conf, char **serial)
> }
> }
>
> +void blkconf_blocksizes(BlockConf *conf)
> +{
> +int block_size;
> +
> +if (!conf->physical_block_size) {
> +if (bdrv_ioctl(conf->bs, BLKPBSZGET, &block_size) == 0) {
#ifdef __linux__
> + conf->physical_block_size = (uint16_t) block_size;
4 spaces for indentation.
> +} else {
> +conf->physical_block_size = BLOCK_PROPERTY_STD_BLKSIZE;
> +}
> +}
> +if (!conf->logical_block_size) {
> +if (bdrv_ioctl(conf->bs, BLKSSZGET, &block_size) == 0) {
> +conf->logical_block_size = (uint16_t) block_size;
> +} else {
> +conf->logical_block_size = BLOCK_PROPERTY_STD_BLKSIZE;
> +}
> +}
> +}
> +
> int blkconf_geometry(BlockConf *conf, int *ptrans,
> unsigned cyls_max, unsigned heads_max, unsigned
> secs_max)
> {
> diff --git a/hw/block-common.h b/hw/block-common.h
> index bb808f7..d593128 100644
> --- a/hw/block-common.h
> +++ b/hw/block-common.h
> @@ -40,18 +40,23 @@ static inline unsigned int
> get_physical_block_exp(BlockConf *conf)
> return exp;
> }
>
> -#define DEFINE_BLOCK_PROPERTIES(_state, _conf) \
> +#define BLOCK_PROPERTY_STD_BLKSIZE 512
> +#define DEFINE_BLOCK_PROPERTIES_EXTENDED(_state, _conf, _blksize) \
Detecting the underlying block size is a generally useful configuration
option. This should not be s390-specific, so no need to rename
DEFINE_BLOCK_PROPERTIES().
If you set the default to 0 then QEMU will do extra ioctls. Perhaps
BlockDriverState needs a function to probe block sizes. This way
block/raw-posix.c could do the probing only on hdev (host block
devices).
> diff --git a/hw/qdev-properties.c b/hw/qdev-properties.c
> index a8a31f5..73b6da0 100644
> --- a/hw/qdev-properties.c
> +++ b/hw/qdev-properties.c
> @@ -650,7 +650,9 @@ static void set_blocksize(Object *obj, Visitor *v, void
> *opaque,
> error_propagate(errp, local_err);
> return;
> }
> -if (value < min || value > max) {
> +
> +/* value == 0 indicates that block size should be sensed later on */
> +if ((value < min || value > max) && value > 0) {
> error_set(errp, QERR_PROPERTY_VALUE_OUT_OF_RANGE,
>dev->id?:"", name, (int64_t)value, min, max);
> return;
In the current patch this allows through the 0 value. Since the patch
only adds a blkconf_blocksizes() call to hw/virtio-blk.c, who knows what
will happen to ide/scsi/etc -drives that are configured with 0.
We need to make sure that 0 is really handled for all emulated storage
controllers.
> diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
> index 34913ee..cd25712 100644
> --- a/hw/virtio-blk.c
> +++ b/hw/virtio-blk.c
> @@ -654,6 +654,7 @@ VirtIODevice *virtio_blk_init(DeviceState *dev,
> VirtIOBlkConf *blk)
> }
>
> blkconf_serial(&blk->conf, &blk->serial);
> +blkconf_blocksizes(&blk->conf);
Shouldn't be virtio-specific, all -drives should be able to autodetect
block size.
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Kevin Wolf writes: > Am 11.02.2013 22:14, schrieb Anthony Liguori: >> Paolo Bonzini writes: >> >>> Il 11/02/2013 21:13, Anthony Liguori ha scritto: Applied. Thanks. Regards, Anthony Liguori >>> >>> I guess this was a mistake, please revert. >> >> No, it wasn't. The patch was reviewed and tested. What's the problem. >> It's proposed for 1.4 so it's now or never. (Note, I already have a revert queued, tested over night, and will push this morning) > The problem is that the test failed. Why do we even test things if we > commit anyway when the test fails? That wasn't at all clear to me. Besides, by the time Jeff's note came, the commit was already pushed. The 'Thanks' note was delayed compared to the actual push. > And why do we have subsystem trees when a committer comes (without even > having taken part in the discussion) and applies patches that the > subsystem maintainers are very obviously not happy with? There are two block maintainers. One of the block maintainers, Stefan, offered a Reviewed-by. > If you like, > you can have the block subsystem back, just send - or better just apply > - a patch against MAINTAINERS. The real problem here was that it was not clear to me whether to expect a pull request for -rc2 or not and from whom. I received very few pull requests during this -rc cycle and most submaintainers have asked me to apply patches directly because of the short cycle. In fact, I reached out twice on IRC attempting to clarify whether I was going to get a block pull request for -rc2 and got no response from you or Stefan. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
On Tue, Feb 12, 2013 at 03:47:38PM +0100, Stefan Weil wrote: > Am 11.02.2013 22:20, schrieb Jeff Cody: > > On Mon, Feb 11, 2013 at 03:14:36PM -0600, Anthony Liguori wrote: > >> Paolo Bonzini writes: > >> > >>> Il 11/02/2013 21:13, Anthony Liguori ha scritto: > Applied. Thanks. > > Regards, > > Anthony Liguori > >>> I guess this was a mistake, please revert. > >> No, it wasn't. The patch was reviewed and tested. What's the problem. > >> It's proposed for 1.4 so it's now or never. > >> > >> I saw some discussion about improving the detection for the different > >> varients of VHD... > >> > >> I don't mind reverting it, but just want to understand what the issue > >> is. > >> > > Hi Anthony, > > > > It was tested, the problem is that this will break existing support > > for Virtual PC VHD files under certain conditions (most likely > > exporting from qemu to VPC, but I don't know if we could guarantee > > that is the only way). > > > > > > Jeff > > Hi Jeff, > > exporting from QEMU to VPCwill work because QEMU uses > images where real size = CHS size, so those images work > no matter whether the patch was applied or not. > > See my separate mail for more reasoning. > > I see no way how the patch could break a realistic test scenario, > but I know such scenarios which are broken without the patch. > > > Stefan > Hi Stefan, I should have been clearer when I said export - I am talking about qemu modifying an existing VHD image created by VPC, and then trying to use image in VPC again. Here is a simple way to see how the proposed patch breaks current VHD compatibility: 1.) Under VPC, define a new VM that boots from a live dvd iso (I used a puppy linux iso because it was small and quick to test: http://puppylinux.org). For the hard drive for the machine, define a 128GB dynamic drive. (test.vhd). You don't need to boot this VM yet. 2.) Now, under QEMU, boot again to a live iso or existing linux image, and use the newly created test.vhd. Create a single partition, using the fdisk defaults for the maximum size. Shutdown. 3.) Use that same VHD image and boot the live iso with your VPC machine. Try to mount the partition you created under qemu with the guest in VPC. It will fail to detect the partition, and complain about invalid geometry. I think your patch is definitely needed, don't get me wrong, and I can verify that it works - for the bug report, I even came to the same conclusion. I just think it needs to be done such that we don't break something that used to work, and testing shows that it does, unfortunately. Thanks, Jeff
Re: [Qemu-devel] [PATCH for-1.4 1/2] trace: use glib atomic int types
Stefan Hajnoczi writes:
> Juan reported that RHEL 6.4 hosts give compiler warnings because we use
> unsigned int while glib prototypes use volatile gint in trace/simple.c.
>
> trace/simple.c:223: error: pointer targets in passing argument 1 of
> 'g_atomic_int_compare_and_exchange' differ in signedness
Meh. Contrary to documentation and how current GLib versions behave, in
other words a bug in need of a workaround.
> These variables are only accessed with glib atomic int functions so
> let's play it by the book and use volatile gint.
gint is a silly alias for int, and used completely interchangeably, even
within GLib APIs. Any pretentions of treating it as something more
abstract break down at the first printf(), if not earlier. But if you
think it helps...
I doubt volatile has any effect here.
> Reported-by: Juan Quintela
> Signed-off-by: Stefan Hajnoczi
> ---
> trace/simple.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/trace/simple.c b/trace/simple.c
> index 74701e3..1d5d8e4 100644
> --- a/trace/simple.c
> +++ b/trace/simple.c
> @@ -51,9 +51,9 @@ enum {
> };
>
> uint8_t trace_buf[TRACE_BUF_LEN];
> -static unsigned int trace_idx;
> +static volatile gint trace_idx;
> static unsigned int writeout_idx;
> -static int dropped_events;
> +static volatile gint dropped_events;
> static FILE *trace_fp;
> static char *trace_file_name;
>
> @@ -267,7 +267,7 @@ void trace_record_finish(TraceBufferRecord *rec)
> record.event |= TRACE_RECORD_VALID;
> write_to_buffer(rec->tbuf_idx, &record, sizeof(TraceRecord));
>
> -if ((g_atomic_int_get(&trace_idx) - writeout_idx)
> +if (((unsigned int)g_atomic_int_get(&trace_idx) - writeout_idx)
> > TRACE_BUF_FLUSH_THRESHOLD) {
> flush_trace_file(false);
> }
Unchanged:
int trace_record_start(TraceBufferRecord *rec, TraceEventID event, size_t
datasize)
{
unsigned int idx, rec_off, old_idx, new_idx;
uint32_t rec_len = sizeof(TraceRecord) + datasize;
uint64_t timestamp_ns = get_clock();
do {
old_idx = g_atomic_int_get(&trace_idx);
smp_rmb();
new_idx = old_idx + rec_len;
if (new_idx - writeout_idx > TRACE_BUF_LEN) {
/* Trace Buffer Full, Event dropped ! */
g_atomic_int_inc(&dropped_events);
return -ENOSPC;
}
} while (!g_atomic_int_compare_and_exchange(&trace_idx, old_idx, new_idx));
[...]
}
Now mixes int trace_idx with unsigned old_idx, new_idx. No biggie, but
you might want to clean it up anyway.
Re: [Qemu-devel] KVM call agenda for 2013-02-12
Juan Quintela wrote: > Hi > > Please send in any agenda topics you are interested in. As there is no topics, call gets canceled. Happy hacking, Juan.
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Am 12.02.2013 12:24, schrieb Stefan Hajnoczi: > On Tue, Feb 12, 2013 at 10:12:59AM +0100, Markus Armbruster wrote: >> Paolo Bonzini writes: >> >>> Il 12/02/2013 09:42, Kevin Wolf ha scritto: >> No, it wasn't. The patch was reviewed and tested. What's the problem. >> It's proposed for 1.4 so it's now or never. The problem is that the test failed. Why do we even test things if we commit anyway when the test fails? And why do we have subsystem trees when a committer comes (without even having taken part in the discussion) and applies patches that the subsystem maintainers are very obviously not happy with? If you like, you can have the block subsystem back, just send - or better just apply - a patch against MAINTAINERS. >>> I think this is just a problem with the new tools, that didn't make it >>> clear that you were not happy with the patch. (It was clear from the >>> mailing list). >>> >>> In general, the new tools sound like an improvement, but it's normal to >>> have a misunderstanding or two in the initial period. >> Yup. No need to get excited. >> >> Let's revert this patch for 1.4, keeping QEMU exactly as working and as >> broken as it has always been. Then figure out which additional cases we >> can make work for 1.5, and which ones we have to break for that, if any. > I'll send a block pull request that includes a revert. > > Stefan I'm not convinced that this would be a good idea. See my other mail for the reason. Stefan
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Am 11.02.2013 22:20, schrieb Jeff Cody: > On Mon, Feb 11, 2013 at 03:14:36PM -0600, Anthony Liguori wrote: >> Paolo Bonzini writes: >> >>> Il 11/02/2013 21:13, Anthony Liguori ha scritto: Applied. Thanks. Regards, Anthony Liguori >>> I guess this was a mistake, please revert. >> No, it wasn't. The patch was reviewed and tested. What's the problem. >> It's proposed for 1.4 so it's now or never. >> >> I saw some discussion about improving the detection for the different >> varients of VHD... >> >> I don't mind reverting it, but just want to understand what the issue >> is. >> > Hi Anthony, > > It was tested, the problem is that this will break existing support > for Virtual PC VHD files under certain conditions (most likely > exporting from qemu to VPC, but I don't know if we could guarantee > that is the only way). > > > Jeff Hi Jeff, exporting from QEMU to VPCwill work because QEMU uses images where real size = CHS size, so those images work no matter whether the patch was applied or not. See my separate mail for more reasoning. I see no way how the patch could break a realistic test scenario, but I know such scenarios which are broken without the patch. Stefan
Re: [Qemu-devel] [PATCH 3/5] target-i386: Slim conversion to X86CPU subclasses
On Mon, Feb 11, 2013 at 02:52:49AM +0100, Igor Mammedov wrote:
> 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
Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Am 12.02.2013 09:42, schrieb Kevin Wolf: > It makes qemu use the wrong size for VHD images created by Virtual PC > that used to work with qemu. This is a regression that can result in > images appearing corrupted in Virtual PC, and we need very good > justification to apply such a patch. > > At the same time the patch enables the use of the correct size for > Hyper-V images, but that has never worked with qemu, so if we can't get > it to work with both for 1.4, I'd rather compromise on this one and not > apply the patch. > > Please revert. > > Kevin I'd appreciate if we could use a more precise description of the results and the problems with or without the patch. QEMU does _not_ use a wrong size for any VHD images with the patch. It passes the correct real image size to the guest. This is compatible with the behaviour of Hyper-V, Virtual Box and maybe other emulators which implement the VHD specification as published by Microsoft. According to the tests run, it is incompatible with VPC which passes a calculated CHS size. For images created with QEMU, the calculated CHS size and the real size are always be the same, so these images work in any case. It should also be possible to create such images with any other tool by specifying an image size which is an exact CHS size, but in most cases VHD images will have a size which is larger than the calculated CHS size. As far as we currently know, VPC (and no other tool) passes the calculated CHS size to its guest. Copying such images to any other format using qemu-img works both with and without the patch because all valid data is below the CHS size. Copying any kind of non VHD image to VHD also works with and without the patch because QEMU always calculates an image size based on the CHS size for newly created images. Copying a VHD image which was written beyond the CHS size to VHD needs the patch because otherwise the data behind the CHS size would get lost. The resulting image should work with any emulator, also with VPC, because it again has a real size which is equal to the CHS size. This all means that the patch is still correct, does not introduce a regression and should be in QEMU 1.4. The only problem I see with the patch is my wrong mail address. Anthony's semi-automated commit did not fix the wrong address which I had supplied. Cheers, Stefan W.
[Qemu-devel] uhci: cancel delay for unregistered queues
Hi, was just debugging a memory corruption of my USB driver inside QEMU - and so far only there: I have a queue registered with the UHCI controller on an input endpoint that continuously generates data. At some point my driver decides to stop reading and removes the QH (with a lot of TDs attached) from the schedule. The driver waits for the next frame, then releases the QH and its TDs. QEMU apparently takes a "few" more frames to consider this queue dead. In the meantime, it seems to happily fill the TD buffers with data. But those buffers are long returned to the guest pool of free memory, causing corruptions there. I'm wondering now if I'm (again) using the UHCI in an unorthodox way (at least I stopped doing multi-queues per endpoint), still must have a subtle bug in the guest, or if this is a fundamental problem of QEMU's UHCI model. Thanks, Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux
Re: [Qemu-devel] kvm segfaulting
Il 12/02/2013 14:46, Stefan Priebe - Profihost AG ha scritto: > Hi, > > thanks - i applied the patch to the latest master. I hope that this will > solve my issue. Will this one get integrated in 1.4 final? No, only 1.4.1 and 1.5 unfortunately. Let's give it a week for you to test it. Paolo
Re: [Qemu-devel] [PATCH for-1.4 0/2] block-migration: fix pending() and iterate() return values
Stefan Hajnoczi wrote: > This series finally ensures that we never complete block migration before the > entire disk image has been transferred. > > Juan explained to me on IRC yesterday what the .save_live_pending() and > .save_live_iterate() are supposed to return. I had misunderstood them when > reading outdated code in savevm.c and 2c5a7f20112615ce13a3434ab90bee1ed8d44ebd > does not prevent block migration from completing too early. > > See the patch descriptions for an explanation of what the .save_live_pending() > and .save_live_iterate() return values mean. > > Stefan Hajnoczi (2): > migration: make qemu_ftell() public and support writable files > block-migration: fix pending() and iterate() return values Reviewed-by: Juan Quintela
Re: [Qemu-devel] [PATCH v10 0/4] Add subcommand compare for qemu-img
On Tue, Feb 12, 2013 at 08:00:21AM +0100, Miroslav Rezanina wrote: > This is 10th version of patch adding compare subcommand that > compares two images. Compare has following criteria: > - only data part is compared > - unallocated sectors are not read > to be zeroed/unallocated to compare rest > - qemu-img returns: > - 0 if images are identical > - 1 if images differ > - >2 error on execution > > v10: > - rebased to kwolf's block-next branch due to conflict patch (patch 2) > - exit status updates (patch 3) > - minor non-functional fixes > > v9: > - Merged patch 3 and 4 (subcommmand implementation and documentation) of v8 > - Added basic test for qemu-img compare > - Fixed incorrect indentation > - add bdrv_is_allocated_above() return value check > - Add description of exit codes into the documentation > - minor non-functional changes > > v8: > - minor grammar fixes (no behavior change) > > v7: > - split patch into pieces > - Quiet mode added for all relevant subcommands > - check non-shared part of disk after shared one > - minor docummentation and naming fixes > > v6: > - added handling -?, -h options for compare subcommand > > v5 (only minor changes): > - removed redundant comment > - removed dead code (goto after help()) > - set final total_sectors on first assignment > > v4: > - Fixed various typos > - Added functions for empty sector check and sector-to-bytes offset > conversion > - Fixed command-line parameters processing > > v3: > - options -f/-F are orthogonal > - documentation updated to new syntax and behavior > - used byte offset instead of sector number for output > > v2: > - changed option for second image format to -F > - changed handling of -f and -F [1] > - added strict mode (-s) > - added quiet mode (-q) > - improved output messages [2] > - rename variables for larger image handling > - added man page content > > Signed-off-by: Miroslav Rezanina > > Miroslav Rezanina (4): > block: Add synchronous wrapper for bdrv_co_is_allocated_above > qemu-img: Add "Quiet mode" option > This patch adds new qemu-img subcommand that compares content of two > disk images. > qemu-iotests: Add qemu-img compare test > > block.c| 51 +- > blockdev.c |6 +- > include/block/block.h |5 +- > qemu-img-cmds.hx | 34 ++-- > qemu-img.c | 441 > +++- > qemu-img.texi | 56 ++ > tests/qemu-iotests/048 | 77 > tests/qemu-iotests/048.out | 25 +++ > tests/qemu-iotests/group |1 + > 9 files changed, 626 insertions(+), 70 deletions(-) > create mode 100755 tests/qemu-iotests/048 > create mode 100644 tests/qemu-iotests/048.out > Thanks, applied to my block-next tree: https://github.com/stefanha/qemu/commits/block-next Please address the qemu-iotests fixes that Kevin suggested in a follow-up series. Thanks, Stefan
Re: [Qemu-devel] kvm segfaulting
Hi,
thanks - i applied the patch to the latest master. I hope that this will
solve my issue. Will this one get integrated in 1.4 final?
Greets,
Stefan
Am 11.02.2013 15:42, schrieb Paolo Bonzini:
> Il 11/02/2013 15:18, Stefan Priebe - Profihost AG ha scritto:
Some trace that a request was actually cancelled, but I think I
believe
>> Ah but that must be in guest not on host right? How to grab that from
>> client when it is crashing?
>
> Serial console could have something like "sda: aborting command". It is
> actually interesting to see what is causing commands to be aborted (typically
> a timeout, but what causes the timeout? :).
>
that. This seems to be the same issue as commits
1bd075f29ea6d11853475c7c42734595720c3ac6 (iSCSI) and
473c7f0255920bcaf37411990a3725898772817f (rbd), where the "cancelled"
callback is called before the "complete" callback.
>> If there is the same code in virtio-scsi it might be.
>
> No, virtio-scsi is relying on the backends (including scsi-disk)
> doing it correctly. The RBD code looks okay, so it's still my
> fault :) but not virtio-scsi's.
>
> I think this happens when a request is split into multiple parts,
> and one of them is canceled. Then the next part is fired, but
> virtio-scsi's cancellation callbacks have fired already.
>
> You can test this patch:
>
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index 07220e4..1d8289c 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -221,6 +221,10 @@ static void scsi_write_do_fua(SCSIDiskReq *r)
> {
> SCSIDiskState *s = DO_UPCAST(SCSIDiskState, qdev, r->req.dev);
>
> +if (r->req.io_canceled) {
> +return;
> +}
> +
> if (scsi_is_cmd_fua(&r->req.cmd)) {
> bdrv_acct_start(s->qdev.conf.bs, &r->acct, 0, BDRV_ACCT_FLUSH);
> r->req.aiocb = bdrv_aio_flush(s->qdev.conf.bs, scsi_aio_complete, r);
> @@ -352,6 +356,10 @@ static void scsi_read_data(SCSIRequest *req)
> /* No data transfer may already be in progress */
> assert(r->req.aiocb == NULL);
>
> +if (r->req.io_canceled) {
> +return;
> +}
> +
> /* The request is used as the AIO opaque value, so add a ref. */
> scsi_req_ref(&r->req);
> if (r->req.cmd.mode == SCSI_XFER_TO_DEV) {
> @@ -455,6 +463,10 @@ static void scsi_write_data(SCSIRequest *req)
> /* No data transfer may already be in progress */
> assert(r->req.aiocb == NULL);
>
> +if (r->req.io_canceled) {
> +return;
> +}
> +
> /* The request is used as the AIO opaque value, so add a ref. */
> scsi_req_ref(&r->req);
> if (r->req.cmd.mode != SCSI_XFER_TO_DEV) {
>
> Paolo
>
Re: [Qemu-devel] [PATCH v3 0/5] qcow2: add fragmentation and compression info support
On Thu, Feb 07, 2013 at 05:15:00PM +0100, Stefan Hajnoczi wrote: > Applies on kevin/block-next (2700d627e4d73bb2aacb832a93ffac8fec78b1fd). > > This series adds fragmentation info support to qcow2 and then adds compression > info. Previously only QED supported fragmentation info. Note that > fragmentation info only covers the current image, internal snapshots are not > included. > > The new BlockFragInfo.compressed field contains the number of compressed > clusters. qemu-img check now reports the percentage of compressed clusters > out > of all allocated clusters. This can be used to decide when to recompress an > image or to double-check that an image is indeed compressed. > > qemu-iotests was to handle the new qemu-img check output. > > I have tested qcow2 images both compressed and uncompressed. > > v3: > * Add space before '=' in qemu-img check output [kwolf] > * Count compressed clusters as fragmented, explained in comment [kwolf] > > v2: > * Fix indentation on modified block/qcow2-refcount.c lines [eblake] > * Change qemu-img check output from just "compressed" to "compressed > clusters" [eblake] > * Improve grep and sed usage in common.rc [eblake] > * Introduce sector_offset local variable for & ~511 [eblake] > * Improve nb_csectors rounding down explanation in comment [eblake] > > Stefan Hajnoczi (5): > qcow2: introduce check_refcounts_l1/l2() flags > qcow2: record fragmentation statistics during check > qemu-img: fix missing space in qemu-img check output > qemu-img: add compressed clusters to BlockFragInfo > qcow2: support compressed clusters in BlockFragInfo > > block/qcow2-refcount.c | 42 -- > include/block/block.h| 1 + > qapi-schema.json | 6 +- > qemu-img.c | 12 > tests/qemu-iotests/044.out | 1 + > tests/qemu-iotests/common.rc | 2 +- > 6 files changed, 52 insertions(+), 12 deletions(-) > > -- > 1.8.1 > Applied to my block-next tree: https://github.com/stefanha/qemu/commits/block-next Stefan
[Qemu-devel] [PATCH for-1.4 2/2] trace: deal with deprecated glib thread functions
g_thread_create() was deprecated in favor of g_thread_new() and
g_cond_new() was deprecated in favor of GCond initialization. If the
host has glib 2.31 or newer, avoid using the deprecated functions.
This patch solves compiler warnings that are generated when glib's
deprecated functions are used.
Signed-off-by: Stefan Hajnoczi
---
trace/simple.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/trace/simple.c b/trace/simple.c
index 1d5d8e4..375d98f 100644
--- a/trace/simple.c
+++ b/trace/simple.c
@@ -40,8 +40,18 @@
* records to become available, writes them out, and then waits again.
*/
static GStaticMutex trace_lock = G_STATIC_MUTEX_INIT;
+
+/* g_cond_new() was deprecated in glib 2.31 but we still need to support it */
+#if GLIB_CHECK_VERSION(2, 31, 0)
+static GCond the_trace_available_cond;
+static GCond the_trace_empty_cond;
+static GCond *trace_available_cond = &the_trace_available_cond;
+static GCond *trace_empty_cond = &the_trace_empty_cond;
+#else
static GCond *trace_available_cond;
static GCond *trace_empty_cond;
+#endif
+
static bool trace_available;
static bool trace_writeout_enabled;
@@ -397,7 +407,13 @@ static GThread *trace_thread_create(GThreadFunc fn)
sigfillset(&set);
pthread_sigmask(SIG_SETMASK, &set, &oldset);
#endif
+
+#if GLIB_CHECK_VERSION(2, 31, 0)
+thread = g_thread_new("trace-thread", fn, NULL);
+#else
thread = g_thread_create(fn, NULL, FALSE, NULL);
+#endif
+
#ifndef _WIN32
pthread_sigmask(SIG_SETMASK, &oldset, NULL);
#endif
@@ -418,8 +434,10 @@ bool trace_backend_init(const char *events, const char
*file)
#endif
}
+#if !GLIB_CHECK_VERSION(2, 31, 0)
trace_available_cond = g_cond_new();
trace_empty_cond = g_cond_new();
+#endif
thread = trace_thread_create(writeout_thread);
if (!thread) {
--
1.8.1.2
[Qemu-devel] [PATCH for-1.4 1/2] trace: use glib atomic int types
Juan reported that RHEL 6.4 hosts give compiler warnings because we use
unsigned int while glib prototypes use volatile gint in trace/simple.c.
trace/simple.c:223: error: pointer targets in passing argument 1 of
'g_atomic_int_compare_and_exchange' differ in signedness
These variables are only accessed with glib atomic int functions so
let's play it by the book and use volatile gint.
Reported-by: Juan Quintela
Signed-off-by: Stefan Hajnoczi
---
trace/simple.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/trace/simple.c b/trace/simple.c
index 74701e3..1d5d8e4 100644
--- a/trace/simple.c
+++ b/trace/simple.c
@@ -51,9 +51,9 @@ enum {
};
uint8_t trace_buf[TRACE_BUF_LEN];
-static unsigned int trace_idx;
+static volatile gint trace_idx;
static unsigned int writeout_idx;
-static int dropped_events;
+static volatile gint dropped_events;
static FILE *trace_fp;
static char *trace_file_name;
@@ -267,7 +267,7 @@ void trace_record_finish(TraceBufferRecord *rec)
record.event |= TRACE_RECORD_VALID;
write_to_buffer(rec->tbuf_idx, &record, sizeof(TraceRecord));
-if ((g_atomic_int_get(&trace_idx) - writeout_idx)
+if (((unsigned int)g_atomic_int_get(&trace_idx) - writeout_idx)
> TRACE_BUF_FLUSH_THRESHOLD) {
flush_trace_file(false);
}
--
1.8.1.2
[Qemu-devel] [PATCH for-1.4 0/2] trace: fix trace/simple.c compiler warnings
I hope these patches can still be merged for QEMU 1.4. They allow ./configure --enable-trace-backend=simple compilation to succeed without compiler warnings. The 'simple' backend was using deprecated g_thread_create() and g_cond_new() functions. A signed/unsigned pointer mismatch when using the glib atomic int APIs was also fixed. Stefan Hajnoczi (2): trace: use glib atomic int types trace: deal with deprecated glib thread functions trace/simple.c | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) -- 1.8.1.2
[Qemu-devel] Advice on some configuration parameters
I'm making patches to enable some qemu upstream features in xen that are missing in libxl. I'm trying to do it just by giving arguments to qemu, and I want them to be dynamic (e.g. without physical addresses if possible) and concise. I'm confused about usb configuration. Looking at what virt-manager does, it seems that you set the usbredirection in channels like this: -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0 At the moment I'm defining the physical usb devices like this: -readconfig /etc/qemu/ich9-ehci-uhci.cfg If I try to set up virt-manager so that it doesn't point to a file, it uses this configuration: -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 This seems to differ from the configuration file, e.g. you have multifunzion=on only on the first uhci, besides I can't understand how many physical ports are defined. I tried setting 9 usbredirection channels in virt-manager but that configuration doesn't change and no errors are reported, but I doubt that physical ports are being define dynamically. Can you omit physical addresses? I searched the web but I can't find detailed informations about it. Can someone explain in detail how you are supposed to configure usb physical ports? I want to enable both usb redirection and usb passthrough in a dynamic and concise manner. About spice vdagent at the moment I'm using this configuration that seems to work: -device virtio-serial -chardev spicevmc,id=vdagent,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 But I noticed that virt-manager use this slightly different one: -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 Are there any problem with the more concise one I'm using? Thanks for any reply. smime.p7s Description: Firma crittografica S/MIME
Re: [Qemu-devel] [PATCH v3 0/5] qcow2: add fragmentation and compression info support
Am 07.02.2013 17:15, schrieb Stefan Hajnoczi: > Applies on kevin/block-next (2700d627e4d73bb2aacb832a93ffac8fec78b1fd). > > This series adds fragmentation info support to qcow2 and then adds compression > info. Previously only QED supported fragmentation info. Note that > fragmentation info only covers the current image, internal snapshots are not > included. > > The new BlockFragInfo.compressed field contains the number of compressed > clusters. qemu-img check now reports the percentage of compressed clusters > out > of all allocated clusters. This can be used to decide when to recompress an > image or to double-check that an image is indeed compressed. > > qemu-iotests was to handle the new qemu-img check output. > > I have tested qcow2 images both compressed and uncompressed. > > v3: > * Add space before '=' in qemu-img check output [kwolf] > * Count compressed clusters as fragmented, explained in comment [kwolf] > > v2: > * Fix indentation on modified block/qcow2-refcount.c lines [eblake] > * Change qemu-img check output from just "compressed" to "compressed > clusters" [eblake] > * Improve grep and sed usage in common.rc [eblake] > * Introduce sector_offset local variable for & ~511 [eblake] > * Improve nb_csectors rounding down explanation in comment [eblake] > > Stefan Hajnoczi (5): > qcow2: introduce check_refcounts_l1/l2() flags > qcow2: record fragmentation statistics during check > qemu-img: fix missing space in qemu-img check output > qemu-img: add compressed clusters to BlockFragInfo > qcow2: support compressed clusters in BlockFragInfo > > block/qcow2-refcount.c | 42 -- > include/block/block.h| 1 + > qapi-schema.json | 6 +- > qemu-img.c | 12 > tests/qemu-iotests/044.out | 1 + > tests/qemu-iotests/common.rc | 2 +- > 6 files changed, 52 insertions(+), 12 deletions(-) Reviewed-by: Kevin Wolf
[Qemu-devel] [PATCH 2/2] Revert "block/vpc: Fix size calculation"
This reverts commit f880defbb06708d30a38ce9f2667067626acdd38.
Jeff Cody's testing revealed that the interpretation of size differs
even between VirtualPC and HyperV. Revert this so there is time to
consider the impact of any backwards incompatible behavior this change
creates.
Signed-off-by: Stefan Hajnoczi
---
block/vpc.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/block/vpc.c b/block/vpc.c
index b4ff564..82229ef 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -34,8 +34,6 @@
#define HEADER_SIZE 512
-#define VHD_SECTOR_SIZE 512
-
//#define CACHE
enum vhd_type {
@@ -206,13 +204,11 @@ static int vpc_open(BlockDriverState *bs, int flags)
/* Write 'checksum' back to footer, or else will leave it with zero. */
footer->checksum = be32_to_cpu(checksum);
-/* The visible size of a image in Virtual PC depends on the guest:
- * QEMU and other emulators report the real size (here in sectors).
- * All modern operating systems use this real size.
- * Very old operating systems use CHS values to calculate the total size.
- * This calculated size is usually smaller than the real size.
- */
-bs->total_sectors = be64_to_cpu(footer->size) / VHD_SECTOR_SIZE;
+// The visible size of a image in Virtual PC depends on the geometry
+// rather than on the size stored in the footer (the size in the footer
+// is too large usually)
+bs->total_sectors = (int64_t)
+be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;
/* Allow a maximum disk size of approximately 2 TB */
if (bs->total_sectors >= 65535LL * 255 * 255) {
--
1.8.1.2
[Qemu-devel] [PATCH 1/2] block/raw-posix: detect readonly Linux block devices using BLKROGET
Linux block devices can be set read-only with "blockdev --setro
". The same thing can be done for LVM volumes using "lvchange
--permission r ". This read-only setting is independent of
device node permissions. Therefore the device can still be opened
O_RDWR but actual writes will fail.
This results in odd behavior for QEMU. bdrv_open() is supposed to fail
if a read-only image is being opened with BDRV_O_RDWR. By not failing
for Linux block devices, the guest boots up but every write produces an
I/O error.
This patch checks whether the block device is read-only so that Linux
block devices behave like regular files.
Reported-by: Sibiao Luo
Suggested-by: Paolo Bonzini
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Markus Armbruster
Signed-off-by: Kevin Wolf
---
block/raw-posix.c | 49 -
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/block/raw-posix.c b/block/raw-posix.c
index 8b6b926..4dfdf98 100644
--- a/block/raw-posix.c
+++ b/block/raw-posix.c
@@ -1257,9 +1257,43 @@ static int hdev_probe_device(const char *filename)
return 0;
}
+static int check_hdev_writable(BDRVRawState *s)
+{
+#if defined(BLKROGET)
+/* Linux block devices can be configured "read-only" using blockdev(8).
+ * This is independent of device node permissions and therefore open(2)
+ * with O_RDWR succeeds. Actual writes fail with EPERM.
+ *
+ * bdrv_open() is supposed to fail if the disk is read-only. Explicitly
+ * check for read-only block devices so that Linux block devices behave
+ * properly.
+ */
+struct stat st;
+int readonly = 0;
+
+if (fstat(s->fd, &st)) {
+return -errno;
+}
+
+if (!S_ISBLK(st.st_mode)) {
+return 0;
+}
+
+if (ioctl(s->fd, BLKROGET, &readonly) < 0) {
+return -errno;
+}
+
+if (readonly) {
+return -EACCES;
+}
+#endif /* defined(BLKROGET) */
+return 0;
+}
+
static int hdev_open(BlockDriverState *bs, const char *filename, int flags)
{
BDRVRawState *s = bs->opaque;
+int ret;
#if defined(__APPLE__) && defined(__MACH__)
if (strstart(filename, "/dev/cdrom", NULL)) {
@@ -1300,7 +1334,20 @@ static int hdev_open(BlockDriverState *bs, const char
*filename, int flags)
}
#endif
-return raw_open_common(bs, filename, flags, 0);
+ret = raw_open_common(bs, filename, flags, 0);
+if (ret < 0) {
+return ret;
+}
+
+if (flags & BDRV_O_RDWR) {
+ret = check_hdev_writable(s);
+if (ret < 0) {
+raw_close(bs);
+return ret;
+}
+}
+
+return ret;
}
#if defined(__linux__)
--
1.8.1.2
[Qemu-devel] [PULL for-1.4 0/2] Block patches
Revert the vpc size fix which breaks compatibility with VirtualPC. Also error out on startup when a read-only block device is configured as a read-write -drive. This makes Linux read-only block devices behave like read-only regular files, and the error is reported immediately on startup instead of raising EIO once the guest is running. The following changes since commit 58fa4325228f61d58317f48364259b31e9b92d15: qapi: Improve chardev-add documentation (2013-02-11 13:22:52 -0600) are available in the git repository at: git://github.com/stefanha/qemu.git block for you to fetch changes up to 33ccf6675faa3c56f30399e184064fd126904515: Revert "block/vpc: Fix size calculation" (2013-02-12 12:25:15 +0100) Stefan Hajnoczi (2): block/raw-posix: detect readonly Linux block devices using BLKROGET Revert "block/vpc: Fix size calculation" block/raw-posix.c | 49 - block/vpc.c | 14 +- 2 files changed, 53 insertions(+), 10 deletions(-) -- 1.8.1.2
Re: [Qemu-devel] [PATCH v2] bswap: Fix width of swap in leul_to_cpu
> @@ -458,7 +458,15 @@ static inline void cpu_to_32wu(uint32_t *p, uint32_t v)
>
> static inline unsigned long leul_to_cpu(unsigned long v)
> {
> -return le_bswap(v, HOST_LONG_BITS);
> +/* In order to break an include loop between here and
> + qemu-common.h, don't rely on HOST_LONG_BITS. */
The comment's wrong, isn't it? The reason we're not using
HOST_LONG_BITS is because it's the wrong thing, not because of any
include loops.
> +#if ULONG_MAX == UINT32_MAX
> +return le_bswap(v, 32);
> +#elif ULONG_MAX == UINT64_MAX
> +return le_bswap(v, 64);
> +#else
> +# error Unknown sizeof long
> +#endif
Is there any reason this can't be simplified to something like:
return le_bswap(v, 8 * sizeof v);
?
Jay.
[Qemu-devel] [PATCH ppc-next 13/39] target-ppc: Extract 7448 alias
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c |5 ++---
1 Datei geändert, 2 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index c0c7579..edd6ee0 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7348,7 +7348,6 @@ enum {
CPU_POWERPC_7410_v12 = 0x800C1102, /* aka C */
CPU_POWERPC_7410_v13 = 0x800C1103, /* aka D */
CPU_POWERPC_7410_v14 = 0x800C1104, /* aka E */
-#define CPU_POWERPC_7448 CPU_POWERPC_7448_v21
CPU_POWERPC_7448_v10 = 0x80040100,
CPU_POWERPC_7448_v11 = 0x80040101,
CPU_POWERPC_7448_v20 = 0x80040200,
@@ -8866,8 +8865,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("7410_v1.3", CPU_POWERPC_7410_v13, 7410)
/* PowerPC 7410 v1.4 (G4)*/
POWERPC_DEF("7410_v1.4", CPU_POWERPC_7410_v14, 7410)
-/* PowerPC 7448 (G4) */
-POWERPC_DEF("7448", CPU_POWERPC_7448, 7400)
/* PowerPC 7448 v1.0 (G4)*/
POWERPC_DEF("7448_v1.0", CPU_POWERPC_7448_v10, 7400)
/* PowerPC 7448 v1.1 (G4)*/
@@ -9185,6 +9182,8 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "G4", "7400" },
/* Code name for PowerPC 7410 */
{ "Nitro", "7410" },
+/* PowerPC 7448 (G4) */
+{ "7448", "7448_v2.1" },
/* PowerPC 7450 (G4) */
{ "7450", "7450_v2.1" },
/* Code name for PowerPC 7450 */
--
1.7.10.4
Re: [Qemu-devel] [PATCH for-1.4 0/2] block-migration: fix pending() and iterate() return values
Il 12/02/2013 10:37, Stefan Hajnoczi ha scritto: > This series finally ensures that we never complete block migration before the > entire disk image has been transferred. > > Juan explained to me on IRC yesterday what the .save_live_pending() and > .save_live_iterate() are supposed to return. I had misunderstood them when > reading outdated code in savevm.c and 2c5a7f20112615ce13a3434ab90bee1ed8d44ebd > does not prevent block migration from completing too early. > > See the patch descriptions for an explanation of what the .save_live_pending() > and .save_live_iterate() return values mean. > > Stefan Hajnoczi (2): > migration: make qemu_ftell() public and support writable files > block-migration: fix pending() and iterate() return values > > block-migration.c | 22 +- > include/migration/qemu-file.h | 1 + > savevm.c | 9 +++-- > 3 files changed, 21 insertions(+), 11 deletions(-) > Looks good, thanks! Paolo
Re: [Qemu-devel] [PATCH v10 3/4] This patch adds new qemu-img subcommand that compares content of two disk images.
- Original Message - > From: "Kevin Wolf" > To: "Miroslav Rezanina" > Cc: qemu-devel@nongnu.org, pbonz...@redhat.com, stefa...@redhat.com, > ebl...@redhat.com > Sent: Tuesday, February 12, 2013 10:36:07 AM > Subject: Re: [PATCH v10 3/4] This patch adds new qemu-img subcommand that > compares content of two disk images. > > Am 12.02.2013 08:00, schrieb Miroslav Rezanina: > > Signed-off-by: Miroslav Rezanina > > What happened to the commit message here? Previous versions had > "qemu-img: Add compare subcommand" as their subject and what is now > the > subject was the body. Made much more sense. > > Stefan, if you apply the series, can you fix this up? > > Kevin > Ups...I had to accidentally delete the line when handling the cherry-pick (from v9 to v10). Subject and commit message from v9 are valid and should be used. Sorry for the mistake. -- Miroslav Rezanina Software Engineer - Virtualization Team
[Qemu-devel] [PATCH ppc-next 30/39] target-ppc: Extract MPC82xx aliases to *_HiP4
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c | 24 ++--
1 Datei geändert, 6 Zeilen hinzugefügt(+), 18 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index ea512bd..42e1f2d 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7051,22 +7051,16 @@ enum {
#define CPU_POWERPC_MPC8240 CPU_POWERPC_MPC603
#define CPU_POWERPC_MPC8241 CPU_POWERPC_G2_HIP4
#define CPU_POWERPC_MPC8245 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8250 CPU_POWERPC_MPC8250_HiP4
#define CPU_POWERPC_MPC8250_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8250_HiP4 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8255 CPU_POWERPC_MPC8255_HiP4
#define CPU_POWERPC_MPC8255_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8255_HiP4 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8260 CPU_POWERPC_MPC8260_HiP4
#define CPU_POWERPC_MPC8260_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8260_HiP4 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8264 CPU_POWERPC_MPC8264_HiP4
#define CPU_POWERPC_MPC8264_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8264_HiP4 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8265 CPU_POWERPC_MPC8265_HiP4
#define CPU_POWERPC_MPC8265_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8265_HiP4 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8266 CPU_POWERPC_MPC8266_HiP4
#define CPU_POWERPC_MPC8266_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8266_HiP4 CPU_POWERPC_G2_HIP4
/* e200 family */
@@ -7964,38 +7958,26 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("MPC8241", CPU_POWERPC_MPC8241,G2)
/* MPC8245 */
POWERPC_DEF("MPC8245", CPU_POWERPC_MPC8245,G2)
-/* MPC8250 */
-POWERPC_DEF("MPC8250", CPU_POWERPC_MPC8250,G2)
/* MPC8250 HiP3 */
POWERPC_DEF("MPC8250_HiP3", CPU_POWERPC_MPC8250_HiP3, G2)
/* MPC8250 HiP4 */
POWERPC_DEF("MPC8250_HiP4", CPU_POWERPC_MPC8250_HiP4, G2)
-/* MPC8255 */
-POWERPC_DEF("MPC8255", CPU_POWERPC_MPC8255,G2)
/* MPC8255 HiP3 */
POWERPC_DEF("MPC8255_HiP3", CPU_POWERPC_MPC8255_HiP3, G2)
/* MPC8255 HiP4 */
POWERPC_DEF("MPC8255_HiP4", CPU_POWERPC_MPC8255_HiP4, G2)
-/* MPC8260 */
-POWERPC_DEF("MPC8260", CPU_POWERPC_MPC8260,G2)
/* MPC8260 HiP3 */
POWERPC_DEF("MPC8260_HiP3", CPU_POWERPC_MPC8260_HiP3, G2)
/* MPC8260 HiP4 */
POWERPC_DEF("MPC8260_HiP4", CPU_POWERPC_MPC8260_HiP4, G2)
-/* MPC8264 */
-POWERPC_DEF("MPC8264", CPU_POWERPC_MPC8264,G2)
/* MPC8264 HiP3 */
POWERPC_DEF("MPC8264_HiP3", CPU_POWERPC_MPC8264_HiP3, G2)
/* MPC8264 HiP4 */
POWERPC_DEF("MPC8264_HiP4", CPU_POWERPC_MPC8264_HiP4, G2)
-/* MPC8265 */
-POWERPC_DEF("MPC8265", CPU_POWERPC_MPC8265,G2)
/* MPC8265 HiP3 */
POWERPC_DEF("MPC8265_HiP3", CPU_POWERPC_MPC8265_HiP3, G2)
/* MPC8265 HiP4 */
POWERPC_DEF("MPC8265_HiP4", CPU_POWERPC_MPC8265_HiP4, G2)
-/* MPC8266 */
-POWERPC_DEF("MPC8266", CPU_POWERPC_MPC8266,G2)
/* MPC8266 HiP3 */
POWERPC_DEF("MPC8266_HiP3", CPU_POWERPC_MPC8266_HiP3, G2)
/* MPC8266 HiP4 */
@@ -8968,6 +8950,12 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "PowerQUICC-II", "MPC82xx" },
{ "MPC8247", "G2leGP3" },
{ "MPC8248", "G2leGP3" },
+{ "MPC8250", "MPC8250_HiP4" },
+{ "MPC8255", "MPC8255_HiP4" },
+{ "MPC8260", "MPC8260_HiP4" },
+{ "MPC8264", "MPC8264_HiP4" },
+{ "MPC8265", "MPC8265_HiP4" },
+{
[Qemu-devel] [PATCH ppc-next 03/39] target-ppc: Make -cpu "ppc" an alias to "ppc32"
Drop the #if 0'ed alternative to make it "ppc64" for TARGET_PPC64.
If we ever want to change it, we can more easily do so now.
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c | 30 ++
1 Datei geändert, 2 Zeilen hinzugefügt(+), 28 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 4708c96..5cf2c97 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6826,33 +6826,6 @@ static void init_proc_620 (CPUPPCState *env)
#define check_pow_PPC64 check_pow_970FX
#define init_proc_PPC64 init_proc_970FX
-/* Default PowerPC target will be PowerPC 32 */
-#if defined (TARGET_PPC64) && 0 // XXX: TODO
-#define CPU_POWERPC_DEFAULTCPU_POWERPC_PPC64
-#define POWERPC_INSNS_DEFAULT POWERPC_INSNS_PPC64
-#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS2_PPC64
-#define POWERPC_MSRM_DEFAULT POWERPC_MSRM_PPC64
-#define POWERPC_MMU_DEFAULTPOWERPC_MMU_PPC64
-#define POWERPC_EXCP_DEFAULT POWERPC_EXCP_PPC64
-#define POWERPC_INPUT_DEFAULT POWERPC_INPUT_PPC64
-#define POWERPC_BFDM_DEFAULT POWERPC_BFDM_PPC64
-#define POWERPC_FLAG_DEFAULT POWERPC_FLAG_PPC64
-#define check_pow_DEFAULT check_pow_PPC64
-#define init_proc_DEFAULT init_proc_PPC64
-#else
-#define CPU_POWERPC_DEFAULTCPU_POWERPC_PPC32
-#define POWERPC_INSNS_DEFAULT POWERPC_INSNS_PPC32
-#define POWERPC_INSNS2_DEFAULT POWERPC_INSNS2_PPC32
-#define POWERPC_MSRM_DEFAULT POWERPC_MSRM_PPC32
-#define POWERPC_MMU_DEFAULTPOWERPC_MMU_PPC32
-#define POWERPC_EXCP_DEFAULT POWERPC_EXCP_PPC32
-#define POWERPC_INPUT_DEFAULT POWERPC_INPUT_PPC32
-#define POWERPC_BFDM_DEFAULT POWERPC_BFDM_PPC32
-#define POWERPC_FLAG_DEFAULT POWERPC_FLAG_PPC32
-#define check_pow_DEFAULT check_pow_PPC32
-#define init_proc_DEFAULT init_proc_PPC32
-#endif
-
/*/
/* PVR definitions for most known PowerPC*/
enum {
@@ -9323,7 +9296,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("ppc64", CPU_POWERPC_PPC64, PPC64)
#endif
POWERPC_DEF("ppc32", CPU_POWERPC_PPC32, PPC32)
-POWERPC_DEF("ppc", CPU_POWERPC_DEFAULT,DEFAULT)
};
typedef struct PowerPCCPUAlias {
@@ -9401,6 +9373,8 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "RSC4608", "POWER" },
{ "RSC2", "POWER2" },
{ "P2SC", "POWER2" },
+
+{ "ppc", "ppc32" },
/* Fallback */
{ "default", "ppc" },
};
--
1.7.10.4
[Qemu-devel] [PATCH ppc-next 23/39] target-ppc: Extract MPC85xx aliases
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c | 119 +--
1 Datei geändert, 34 Zeilen hinzugefügt(+), 85 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 8434e9e..a2f1030 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7149,67 +7149,50 @@ enum {
CPU_POWERPC_e500mc = 0x80230020,
CPU_POWERPC_e5500 = 0x80240020,
/* MPC85xx microcontrollers */
-#define CPU_POWERPC_MPC8533 CPU_POWERPC_MPC8533_v11
#define CPU_POWERPC_MPC8533_v10 CPU_POWERPC_e500v2_v21
#define CPU_POWERPC_MPC8533_v11 CPU_POWERPC_e500v2_v22
-#define CPU_POWERPC_MPC8533E CPU_POWERPC_MPC8533E_v11
#define CPU_POWERPC_MPC8533E_v10 CPU_POWERPC_e500v2_v21
#define CPU_POWERPC_MPC8533E_v11 CPU_POWERPC_e500v2_v22
-#define CPU_POWERPC_MPC8540 CPU_POWERPC_MPC8540_v21
#define CPU_POWERPC_MPC8540_v10 CPU_POWERPC_e500v1_v10
#define CPU_POWERPC_MPC8540_v20 CPU_POWERPC_e500v1_v20
#define CPU_POWERPC_MPC8540_v21 CPU_POWERPC_e500v1_v20
-#define CPU_POWERPC_MPC8541 CPU_POWERPC_MPC8541_v11
#define CPU_POWERPC_MPC8541_v10 CPU_POWERPC_e500v1_v20
#define CPU_POWERPC_MPC8541_v11 CPU_POWERPC_e500v1_v20
-#define CPU_POWERPC_MPC8541E CPU_POWERPC_MPC8541E_v11
#define CPU_POWERPC_MPC8541E_v10 CPU_POWERPC_e500v1_v20
#define CPU_POWERPC_MPC8541E_v11 CPU_POWERPC_e500v1_v20
-#define CPU_POWERPC_MPC8543 CPU_POWERPC_MPC8543_v21
#define CPU_POWERPC_MPC8543_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8543_v11 CPU_POWERPC_e500v2_v11
#define CPU_POWERPC_MPC8543_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8543_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8543E CPU_POWERPC_MPC8543E_v21
#define CPU_POWERPC_MPC8543E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8543E_v11 CPU_POWERPC_e500v2_v11
#define CPU_POWERPC_MPC8543E_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8543E_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8544 CPU_POWERPC_MPC8544_v11
#define CPU_POWERPC_MPC8544_v10 CPU_POWERPC_e500v2_v21
#define CPU_POWERPC_MPC8544_v11 CPU_POWERPC_e500v2_v22
#define CPU_POWERPC_MPC8544E_v11 CPU_POWERPC_e500v2_v22
-#define CPU_POWERPC_MPC8544E CPU_POWERPC_MPC8544E_v11
#define CPU_POWERPC_MPC8544E_v10 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8545 CPU_POWERPC_MPC8545_v21
#define CPU_POWERPC_MPC8545_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8545_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8545_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8545E CPU_POWERPC_MPC8545E_v21
#define CPU_POWERPC_MPC8545E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8545E_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8545E_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8547E CPU_POWERPC_MPC8547E_v21
#define CPU_POWERPC_MPC8547E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8547E_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8547E_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8548 CPU_POWERPC_MPC8548_v21
#define CPU_POWERPC_MPC8548_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8548_v11 CPU_POWERPC_e500v2_v11
#define CPU_POWERPC_MPC8548_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8548_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8548E CPU_POWERPC_MPC8548E_v21
#define CPU_POWERPC_MPC8548E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8548E_v11 CPU_POWERPC_e500v2_v11
#define CPU_POWERPC_MPC8548E_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8548E_v21 CPU_POWERPC_e500v2_v21
-#define CPU_POWERPC_MPC8555 CPU_POWERPC_MPC8555_v11
#define CPU_POWERPC_MPC8555_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8555_v11 CPU_POWERPC_e500v2_v11
-#define CPU_POWERPC_MPC8555E CPU_POWERPC_MPC8555E_v11
#define CPU_POWERPC_MPC8555E_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8555E_v11 CPU_POWERPC_e500v2_v11
-#define CPU_POWERPC_MPC8560 CPU_POWERPC_MPC8560_v21
#define CPU_POWERPC_MPC8560_v10 CPU_POWERPC_e500v2_v10
#define CPU_POWERPC_MPC8560_v20 CPU_POWERPC_e500v2_v20
#define CPU_POWERPC_MPC8560_v21 CPU_POWERPC_e500v2_v21
@@ -7511,64 +7494,47 @@ enum {
POWERPC_SVR_8378E = 0x80C40010 | POWERPC_SVR_E500,
POWERPC_SVR_8379 = 0x80C30010 | POWERPC_SVR_E500,
POWERPC_SVR_8379E = 0x80C00010 | POWERPC_SVR_E500,
-#define POWERPC_SVR_8533 POWERPC_SVR_8533_v11
POWERPC_SVR_8533_v10 = 0x80340010 | POWERPC_SVR_E500,
POWERPC_SVR_8533_v11 = 0x80340011 | POWERPC_SVR_E500,
-#define POWERPC_SVR_8533EPOWERPC_SVR_8533E_v11
POWERPC_SVR_8533E_v10 = 0x803C0010 | POWER
[Qemu-devel] [PATCH ppc-next 21/39] target-ppc: Extract 603r alias
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c |5 ++---
1 Datei geändert, 2 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index c1619a4..3bbce1b 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7248,7 +7248,6 @@ enum {
CPU_POWERPC_603E7v2= 0x00070201,
CPU_POWERPC_603E7 = 0x00070200,
CPU_POWERPC_603P = 0x0007,
-#define CPU_POWERPC_603R CPU_POWERPC_603E7t
/* XXX: missing 0x00040303 (604) */
CPU_POWERPC_604= 0x00040103,
/* XXX: missing 0x00091203 */
@@ -8637,8 +8636,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("603e7v2", CPU_POWERPC_603E7v2,603E)
/* PowerPC 603p (aka PID7v) */
POWERPC_DEF("603p", CPU_POWERPC_603P, 603E)
-/* PowerPC 603r (aka PID7t) */
-POWERPC_DEF("603r", CPU_POWERPC_603R, 603E)
/* PowerPC 604 */
POWERPC_DEF("604", CPU_POWERPC_604,604)
/* PowerPC 604e v1.0 */
@@ -9120,6 +9117,8 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "Stretch", "603e" },
/* Code name for PowerPC 603ev */
{ "Vaillant", "603e7v" },
+/* PowerPC 603r (aka PID7t) */
+{ "603r", "603e7t" },
/* Code name for PowerPC 603r */
{ "Goldeneye", "603r" },
/* PowerPC 604e (aka PID9) */
--
1.7.10.4
[Qemu-devel] [PATCH ppc-next 05/39] target-ppc: Extract MGT823/MPC8xx as aliases
They used different PVRs but were defined to MPC8xx.
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c | 107 +--
1 Datei geändert, 31 Zeilen hinzugefügt(+), 76 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index e7605e3..7b0c21e 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7061,21 +7061,6 @@ enum {
CPU_POWERPC_MPC5xx = 0x00020020,
/* PowerPC MPC 8xx cores (aka PowerQUICC) */
CPU_POWERPC_MPC8xx = 0x0050,
-#define CPU_POWERPC_MGT823 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC821 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC823 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC850 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC852T CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC855T CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC857 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC859 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC860 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC862 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC866 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC870 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC875 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC880 CPU_POWERPC_MPC8xx
-#define CPU_POWERPC_MPC885 CPU_POWERPC_MPC8xx
/* G2 cores (aka PowerQUICC-II) */
CPU_POWERPC_G2 = 0x00810011,
CPU_POWERPC_G2H4 = 0x80811010,
@@ -8050,67 +8035,6 @@ static const ppc_def_t ppc_defs[] = {
/* Generic MPC8xx core */
POWERPC_DEF("MPC8xx",CPU_POWERPC_MPC8xx, MPC8xx)
#endif
-/* MPC8xx microcontrollers */
-#if defined(TODO_USER_ONLY)
-/* MGT823*/
-POWERPC_DEF("MGT823",CPU_POWERPC_MGT823, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC821*/
-POWERPC_DEF("MPC821",CPU_POWERPC_MPC821, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC823*/
-POWERPC_DEF("MPC823",CPU_POWERPC_MPC823, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC850*/
-POWERPC_DEF("MPC850",CPU_POWERPC_MPC850, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC852T */
-POWERPC_DEF("MPC852T", CPU_POWERPC_MPC852T,MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC855T */
-POWERPC_DEF("MPC855T", CPU_POWERPC_MPC855T,MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC857*/
-POWERPC_DEF("MPC857",CPU_POWERPC_MPC857, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC859*/
-POWERPC_DEF("MPC859",CPU_POWERPC_MPC859, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC860*/
-POWERPC_DEF("MPC860",CPU_POWERPC_MPC860, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC862*/
-POWERPC_DEF("MPC862",CPU_POWERPC_MPC862, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC866*/
-POWERPC_DEF("MPC866",CPU_POWERPC_MPC866, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC870*/
-POWERPC_DEF("MPC870",CPU_POWERPC_MPC870, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC875*/
-POWERPC_DEF("MPC875",CPU_POWERPC_MPC875, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC880*/
-POWERPC_DEF("MPC880",CPU_POWERPC_MPC880, MPC8xx)
-#endif
-#if defined(TODO_USER_ONLY)
-/* MPC885*/
-POWERPC_DEF("MPC885",CPU_POWERPC_MPC885, MPC8xx)
-#endif
/* MPC82xx family (aka PowerQUICC-II)*/
/* Generic MPC52xx core */
PO
[Qemu-devel] [PATCH ppc-next 27/39] target-ppc: Extract e200 alias
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c |5 ++---
1 Datei geändert, 2 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index cf4f286..929ecba 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7079,7 +7079,6 @@ enum {
#define CPU_POWERPC_MPC8280 CPU_POWERPC_G2LEgp3
/* e200 family */
/* e200 cores */
-#define CPU_POWERPC_e200 CPU_POWERPC_e200z6
#if 0
CPU_POWERPC_e200z0 = xxx,
#endif
@@ -8026,8 +8025,6 @@ static const ppc_def_t ppc_defs[] = {
/* MPC8280 */
POWERPC_DEF("MPC8280", CPU_POWERPC_MPC8280,G2LE)
/* e200 family */
-/* Generic PowerPC e200 core */
-POWERPC_DEF("e200", CPU_POWERPC_e200, e200)
/* Generic MPC55xx core */
#if defined (TODO)
POWERPC_DEF_SVR("MPC55xx",
@@ -8991,6 +8988,8 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "MPC885", "MPC8xx" },
/* Codename for MPC82xx */
{ "PowerQUICC-II", "MPC82xx" },
+/* Generic PowerPC e200 core */
+{ "e200", "e200z6" },
/* Generic PowerPC e300 core */
{ "e300", "e300c3" },
/* MPC8347 */
--
1.7.10.4
[Qemu-devel] [PATCH ppc-next 29/39] target-ppc: Extract MPC8247/MPC8248/MPC8270-80 aliases
This depends on the fix for "G2leGP3" PVR.
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c | 33 -
1 Datei geändert, 12 Zeilen hinzugefügt(+), 21 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index ca42150..ea512bd 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7051,8 +7051,6 @@ enum {
#define CPU_POWERPC_MPC8240 CPU_POWERPC_MPC603
#define CPU_POWERPC_MPC8241 CPU_POWERPC_G2_HIP4
#define CPU_POWERPC_MPC8245 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8247 CPU_POWERPC_G2LEgp3
-#define CPU_POWERPC_MPC8248 CPU_POWERPC_G2LEgp3
#define CPU_POWERPC_MPC8250 CPU_POWERPC_MPC8250_HiP4
#define CPU_POWERPC_MPC8250_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8250_HiP4 CPU_POWERPC_G2_HIP4
@@ -7071,11 +7069,6 @@ enum {
#define CPU_POWERPC_MPC8266 CPU_POWERPC_MPC8266_HiP4
#define CPU_POWERPC_MPC8266_HiP3 CPU_POWERPC_G2_HIP3
#define CPU_POWERPC_MPC8266_HiP4 CPU_POWERPC_G2_HIP4
-#define CPU_POWERPC_MPC8270 CPU_POWERPC_G2LEgp3
-#define CPU_POWERPC_MPC8271 CPU_POWERPC_G2LEgp3
-#define CPU_POWERPC_MPC8272 CPU_POWERPC_G2LEgp3
-#define CPU_POWERPC_MPC8275 CPU_POWERPC_G2LEgp3
-#define CPU_POWERPC_MPC8280 CPU_POWERPC_G2LEgp3
/* e200 family */
/* e200 cores */
#if 0
@@ -7971,10 +7964,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("MPC8241", CPU_POWERPC_MPC8241,G2)
/* MPC8245 */
POWERPC_DEF("MPC8245", CPU_POWERPC_MPC8245,G2)
-/* MPC8247 */
-POWERPC_DEF("MPC8247", CPU_POWERPC_MPC8247,G2LE)
-/* MPC8248 */
-POWERPC_DEF("MPC8248", CPU_POWERPC_MPC8248,G2LE)
/* MPC8250 */
POWERPC_DEF("MPC8250", CPU_POWERPC_MPC8250,G2)
/* MPC8250 HiP3 */
@@ -8011,16 +8000,6 @@ static const ppc_def_t ppc_defs[] = {
POWERPC_DEF("MPC8266_HiP3", CPU_POWERPC_MPC8266_HiP3, G2)
/* MPC8266 HiP4 */
POWERPC_DEF("MPC8266_HiP4", CPU_POWERPC_MPC8266_HiP4, G2)
-/* MPC8270 */
-POWERPC_DEF("MPC8270", CPU_POWERPC_MPC8270,G2LE)
-/* MPC8271 */
-POWERPC_DEF("MPC8271", CPU_POWERPC_MPC8271,G2LE)
-/* MPC8272 */
-POWERPC_DEF("MPC8272", CPU_POWERPC_MPC8272,G2LE)
-/* MPC8275 */
-POWERPC_DEF("MPC8275", CPU_POWERPC_MPC8275,G2LE)
-/* MPC8280 */
-POWERPC_DEF("MPC8280", CPU_POWERPC_MPC8280,G2LE)
/* e200 family */
/* Generic MPC55xx core */
#if defined (TODO)
@@ -8987,6 +8966,18 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "MPC82xx", "MPC8280" },
/* Codename for MPC82xx */
{ "PowerQUICC-II", "MPC82xx" },
+{ "MPC8247", "G2leGP3" },
+{ "MPC8248", "G2leGP3" },
+/* MPC8270 */
+{ "MPC8270", "G2leGP3" },
+/* MPC8271 */
+{ "MPC8271", "G2leGP3" },
+/* MPC8272 */
+{ "MPC8272", "G2leGP3" },
+/* MPC8275 */
+{ "MPC8275", "G2leGP3" },
+/* MPC8280 */
+{ "MPC8280", "G2leGP3" },
/* Generic PowerPC e200 core */
{ "e200", "e200z6" },
/* Generic PowerPC e300 core */
--
1.7.10.4
[Qemu-devel] [PATCH] Revert "block/vpc: Fix size calculation"
This reverts commit f880defbb06708d30a38ce9f2667067626acdd38.
Jeff Cody's testing revealed that the interpretation of size differs
even between VirtualPC and HyperV. Revert this so there is time to
consider the impact of any backwards incompatible behavior this change
creates.
Signed-off-by: Stefan Hajnoczi
---
block/vpc.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/block/vpc.c b/block/vpc.c
index b4ff564..82229ef 100644
--- a/block/vpc.c
+++ b/block/vpc.c
@@ -34,8 +34,6 @@
#define HEADER_SIZE 512
-#define VHD_SECTOR_SIZE 512
-
//#define CACHE
enum vhd_type {
@@ -206,13 +204,11 @@ static int vpc_open(BlockDriverState *bs, int flags)
/* Write 'checksum' back to footer, or else will leave it with zero. */
footer->checksum = be32_to_cpu(checksum);
-/* The visible size of a image in Virtual PC depends on the guest:
- * QEMU and other emulators report the real size (here in sectors).
- * All modern operating systems use this real size.
- * Very old operating systems use CHS values to calculate the total size.
- * This calculated size is usually smaller than the real size.
- */
-bs->total_sectors = be64_to_cpu(footer->size) / VHD_SECTOR_SIZE;
+// The visible size of a image in Virtual PC depends on the geometry
+// rather than on the size stored in the footer (the size in the footer
+// is too large usually)
+bs->total_sectors = (int64_t)
+be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;
/* Allow a maximum disk size of approximately 2 TB */
if (bs->total_sectors >= 65535LL * 255 * 255) {
--
1.8.1.2
[Qemu-devel] [PATCH ppc-next 22/39] target-ppc: Extract 601/601v aliases
Signed-off-by: Andreas Färber
---
target-ppc/translate_init.c | 10 --
1 Datei geändert, 4 Zeilen hinzugefügt(+), 6 Zeilen entfernt(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 3bbce1b..8434e9e 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -7227,10 +7227,8 @@ enum {
#define CPU_POWERPC_MPC8641 CPU_POWERPC_e600
#define CPU_POWERPC_MPC8641D CPU_POWERPC_e600
/* PowerPC 6xx cores */
-#define CPU_POWERPC_601 CPU_POWERPC_601_v2
CPU_POWERPC_601_v0 = 0x00010001,
CPU_POWERPC_601_v1 = 0x00010001,
-#define CPU_POWERPC_601v CPU_POWERPC_601_v2
CPU_POWERPC_601_v2 = 0x00010002,
CPU_POWERPC_602= 0x00050100,
CPU_POWERPC_603= 0x00030100,
@@ -8594,14 +8592,10 @@ static const ppc_def_t ppc_defs[] = {
CPU_POWERPC_MPC8641D, POWERPC_SVR_8641D, 7400)
/* 32 bits "classic" PowerPC */
/* PowerPC 6xx family*/
-/* PowerPC 601 */
-POWERPC_DEF("601", CPU_POWERPC_601,601v)
/* PowerPC 601v0 */
POWERPC_DEF("601_v0",CPU_POWERPC_601_v0, 601)
/* PowerPC 601v1 */
POWERPC_DEF("601_v1",CPU_POWERPC_601_v1, 601)
-/* PowerPC 601v */
-POWERPC_DEF("601v", CPU_POWERPC_601v, 601v)
/* PowerPC 601v2 */
POWERPC_DEF("601_v2",CPU_POWERPC_601_v2, 601v)
/* PowerPC 602 */
@@ -9109,6 +9103,10 @@ static const PowerPCCPUAlias ppc_cpu_aliases[] = {
{ "PowerQUICC-II", "MPC82xx" },
/* PowerPC e500 core */
{ "e500", "e500v2_v22" },
+/* PowerPC 601 */
+{ "601", "601_v2" },
+/* PowerPC 601v */
+{ "601v", "601_v2" },
/* Code name for PowerPC 603 */
{ "Vanilla", "603" },
/* PowerPC 603e (aka PID6) */
--
1.7.10.4
