From: Alexander Graf
We want to be able to debug AArch64 guests. So let's add the respective gdb
stub functions and xml descriptions that allow us to do so.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
---
Changes in v3:
- fix checkpatch.pl issues
gdb-xml/aarch64-core.xml | 46 ++
From: Alexander Graf
If we want to compile a target machine type that is AArch64 capable,
we need to add a new 64-bit capable ARM target. Use AArch64 since that
is the official ARM LTD name.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
---
Changes in v3:
- Arch aarch64 gets its own
From: Alexander Graf
32-bit ARM has a lot of different names for different types of CPUs it supports.
On AArch64, we don't have this, so we really don't want to execute the 32-bit
logic. Stub it out for AArch64 linux-user guests.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
---
lin
From: Alexander Graf
Glibc 1.17 checks for the host kernel version on startup. Unfortunately,
it also checks whether the host kernel version is recent enough for the
target to run at all.
Since AArch64 support only got introduced in 3.8.0, that means that glibc
refuses to run on any older kernel
From: Alexander Graf
The AArch64 syscall definitions are all publicly available in the Linux
kernel. Let's add them to our linux-user emulation target, so that we
can easily handle AArch64 syscalls.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
---
Changes in v3:
- Put aarch64 sysca
From: Alexander Graf
Some syscall handlers have special code for ARM enabled that we don't
need on AArch64. Exclude AArch64 in those cases. In other places we
can share struct definitions with other targets or have to provide our
own.
With this patch applied, most syscall definitions in linux-us
From: Andreas Schwab
This patch adds signal handling for AArch64. The code is based on the
respective source in the Linux kernel.
Signed-off-by: Andreas Schwab
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
---
Changes in v3:
- Remove unneeded __{put,get}__user error checking
- Fix
From: Alexander Graf
This patch adds support for AArch64 in all the small corners of
linux-user and beyond.
Signed-off-by: Alexander Graf
Signed-off-by: John Rigby
---
Changes in v3:
- Aarch64 files go in linux-user/aarch64 instead of ifdefs in linux-user/arm
default-configs/aarch64-linux-u
On 05/11/13 10:16, Richard Jones wrote:
> Still happening in upstream qemu from git:
>
> Program terminated with signal 11, Segmentation fault.
> #0 0x7f4f86c721a0 in get_cluster_table (bs=bs@entry=0x7f4f886e7880,
> offset=offset@entry=1152921504606834688,
> new_l2_table=new_l2_tabl
From: Alexander Graf
We should translate AArch64 mode separately from AArch32 mode. In AArch64 mode,
registers look vastly different, instruction encoding is completely different,
basically the system turns into a different machine.
So let's do a simple if() in translate.c to decide whether we c
Am 11.05.2013 um 05:34 hat Eric Blake geschrieben:
> On 05/08/2013 06:49 AM, Kevin Wolf wrote:
> > Am 29.04.2013 um 09:42 hat Stefan Hajnoczi geschrieben:
> >> @block-backup
> >>
>
> > drive-backup would probably be a more consistent naming. We would then
> > still have block-backup for a future l
Am 11.05.2013 um 06:02 hat Eric Blake geschrieben:
> On 04/29/2013 01:42 AM, Stefan Hajnoczi wrote:
> > @block-backup
> >
> > +++ b/qapi-schema.json
> > @@ -1715,6 +1715,37 @@
> > '*speed': 'int' } }
> >
> > ##
> > +# @block-backup
> > +#
> > +# Start a point-in-time copy of a bloc
There's no reason to restrict transactions to operations related to
block devices, so rename the type now before schema introspection stops
us from doing so.
Signed-off-by: Kevin Wolf
---
blockdev.c | 22 +++---
qapi-schema.json | 8
2 files changed, 15 insertions
On 13 May 2013 07:57, John Rigby wrote:
> Resend of v3 with part 6 removed and change notes included.
If you resend a patchset please bump the version number,
it's kind of confusing otherwise...
thanks
-- PMM
Alon Levy wrote:
> Makes it easier to debug situations where the source and target have
> different ram blocks in a device and migration fails due to that, for
> instance a BAR size change on a PCI device.
>
> Signed-off-by: Alon Levy
> ---
> v3: use RAM_ADDR_FMT
>
> arch_init.c | 3 +++
> 1 fil
Il 13/05/2013 05:21, Liu Ping Fan ha scritto:
> From: Liu Ping Fan
>
> Now, each AddressSpaceDispatch has its own radix-tree, and all of them
> lie on phys_section[] and phys_map_nodes[]. When we want lockless
> mmio dispatch, we need something like RCU.
>
> Acheive this with PhysPageTable which
On 13 May 2013 07:57, John Rigby wrote:
> The cpu_env tcg variable will be used by both the AArch32 and AArch64
> handling code. Unstaticify it, so that both sides can make use of it.
>
> target-arm/translate.c | 2 +-
> target-arm/translate.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletio
Il 13/05/2013 05:21, Liu Ping Fan ha scritto:
> From: Liu Ping Fan
>
> Each address space listener has PhysPageMap *cur_map, *next_map,
> the switch from cur_map to next_map complete the RCU style. The
> mem_commit() do the switch, and it is against reader but AddressSpace's
> lock or later RCU m
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
Am 13.05.2013 um 11:28 schrieb Peter Maydell :
> On 13 May 2013 07:57, John Rigby wrote:
>> The cpu_env tcg variable will be used by both the AArch32 and AArch64
>> handling code. Unstaticify it, so that both sides can make use of it.
>>
>> target-arm/translate.c | 2 +-
>> target-arm/translate
Currently do_pci_unregister_device() calls memory_region_del_subregion()
on the device's bus_master_enable_region and the device's iommu region.
But the bus_master_enable_region is an _alias_ to the iommu region, the
iommu region is _not_ a subregion of it. I suspect this has slipped by
only becau
Currently the PCI iommu_fn hook returns a MemoryRegion * to represent the
DMA address of this bus's IOMMU, although that MemoryRegion does have to
be a root MemoryRegion. Several upcoming users of this need the extra
features of an AddressSpace object, rather than a MemoryRegion, and while
they co
Hi,
Here's another spin on my patches working towards integrating vfio
with guest visible iommu support. These are on top of Paolo Bonzini's
iommu branch at:
git://github.com/bonzini/qemu.git
This new spin starts with some extensions to the pci / memory API
core, then some VFIO updates t
The iommu tree introduced a build bug into hw/i386/kvm/ioapic.c. Looks
like a messed up copy and paste.
Signed-off-by: David Gibson
---
hw/i386/kvm/ioapic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/kvm/ioapic.c b/hw/i386/kvm/ioapic.c
index e3c29da..fe24d26
The only model so far supported for VFIO passthrough devices is the model
usually used on x86, where all of the guest's RAM is mapped into the
(host) IOMMU and there is no IOMMU visible in the guest.
This patch begins to relax this model, introducing the notion of a
VFIOAddressSpace. This represe
A PCI device's DMA address space (possibly an IOMMU) is returned by a
method on the PCIBus. At the moment that only has one caller, so the
method is simply open coded. We'll need another caller for VFIO, so
this patch introduces a helper/wrapper function.
Signed-off-by: David Gibson
---
hw/pci
At the moment, most AddressSpace objects last as long as the guest system
in practice, but that could well change in future. In addition, for VFIO
we will be introducing some private per-AdressSpace information, which must
be disposed of before the AddressSpace itself is destroyed.
To reduce the
The current bus callbacks to assign and destroy an iommu memory region for
a PCI device tacitly assume that the lifetime of that address space is
tied to the lifetime of the PCI device. Although that's certainly
possible, it's much more likely that the region will be (at least
potentially) shared
So far, VFIO has a notion of different logical DMA address spaces, but
only ever uses one (system memory). This patch extends this, creating
new VFIOAddressSpace objects as necessary, according to the AddressSpace
reported by the PCI subsystem for this device's DMAs.
This isn't enough yet to supp
On 13 May 2013 11:54, David Gibson wrote:
> At the moment, most AddressSpace objects last as long as the guest system
> in practice, but that could well change in future. In addition, for VFIO
> we will be introducing some private per-AdressSpace information, which must
> be disposed of before th
On Sun, May 12, 2013 at 06:47:05PM +0200, Andreas Färber wrote:
> Am 10.05.2013 22:09, schrieb mdroth:
> > On Fri, May 10, 2013 at 09:53:27PM +0200, Laszlo Ersek wrote:
> >> On 05/10/13 21:30, mdroth wrote:
> >>> On Wed, May 08, 2013 at 05:31:34PM +0200, Laszlo Ersek wrote:
> I should have pai
On Mon, May 13, 2013 at 12:10:10PM +0100, Peter Maydell wrote:
> On 13 May 2013 11:54, David Gibson wrote:
> > At the moment, most AddressSpace objects last as long as the guest system
> > in practice, but that could well change in future. In addition, for VFIO
> > we will be introducing some pri
On Fri, May 10, 2013 at 02:27:29PM +0200, Paolo Bonzini wrote:
> @@ -305,29 +285,28 @@ static void handle_notify(EventNotifier *e)
> vring_disable_notification(s->vdev, &s->vring);
>
> for (;;) {
> -head = vring_pop(s->vdev, &s->vring, iov, end, &out_num,
> &in_num)
On 13 May 2013 12:48, David Gibson wrote:
> On Mon, May 13, 2013 at 12:10:10PM +0100, Peter Maydell wrote:
>> Hmm, is this the ideal semantics? Typically the owner of the
>> MemoryListener isn't the owner of the AddressSpace so it isn't
>> necessarily in a position to guarantee that it can unregis
On Fri, May 10, 2013 at 08:10:23PM +0400, Igor Mitsyanko wrote:
> +if (sd->state != sd_sendingdata_state) {
> +DPRINTF("Transfer was aborted\n");
> +return;
> +}
> +
> +io_len = (sd->ocr & (1 << 30)) ? 512 : sd->blk_len;
If you respin, a constant would be nice instead o
Il 13/05/2013 12:54, David Gibson ha scritto:
> Currently do_pci_unregister_device() calls memory_region_del_subregion()
> on the device's bus_master_enable_region and the device's iommu region.
> But the bus_master_enable_region is an _alias_ to the iommu region, the
> iommu region is _not_ a subr
Il 13/05/2013 12:54, David Gibson ha scritto:
> The iommu tree introduced a build bug into hw/i386/kvm/ioapic.c. Looks
> like a messed up copy and paste.
>
> Signed-off-by: David Gibson
> ---
> hw/i386/kvm/ioapic.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/
Il 13/05/2013 12:54, David Gibson ha scritto:
> The current bus callbacks to assign and destroy an iommu memory region for
> a PCI device tacitly assume that the lifetime of that address space is
> tied to the lifetime of the PCI device. Although that's certainly
> possible, it's much more likely
Il 13/05/2013 12:54, David Gibson ha scritto:
> Currently the PCI iommu_fn hook returns a MemoryRegion * to represent the
> DMA address of this bus's IOMMU, although that MemoryRegion does have to
> be a root MemoryRegion. Several upcoming users of this need the extra
> features of an AddressSpace
Paolo Bonzini writes:
> Il 10/05/2013 17:11, Anthony Liguori ha scritto:
>> Chegu Vinod writes:
>>
>>> On 5/10/2013 6:07 AM, Anthony Liguori wrote:
Chegu Vinod writes:
> If a user chooses to turn on the auto-converge migration capability
> these changes detect the lack of
Il 13/05/2013 14:07, Peter Maydell ha scritto:
> On 13 May 2013 12:48, David Gibson wrote:
>> On Mon, May 13, 2013 at 12:10:10PM +0100, Peter Maydell wrote:
>>> Hmm, is this the ideal semantics? Typically the owner of the
>>> MemoryListener isn't the owner of the AddressSpace so it isn't
>>> neces
On Fri, May 10, 2013 at 08:10:18PM +0400, Igor Mitsyanko wrote:
> This is an initial attempt to change our SD card model to use asynchronious
> input/output API instead of synchronious one. This will require converting of
> every user also. Right now I've converted only PL181 model, and I'll wait
>
Il 13/05/2013 12:54, David Gibson ha scritto:
> Specifically the way the iommu is
> determined from a callback in the PCIBus means that it won't be
> assigned for devices under a PCI-PCI bridge.
Right. I saw the report from Alexey, but I am a bit wary of touching it
because it's not a regression.
On Fri, May 10, 2013 at 10:08:05AM -0500, Anthony Liguori wrote:
> "Daniel P. Berrange" writes:
>
> > On Fri, May 10, 2013 at 08:07:51AM -0500, Anthony Liguori wrote:
> >> Chegu Vinod writes:
> >>
> >> > If a user chooses to turn on the auto-converge migration capability
> >> > these changes
On Mon, May 13, 2013 at 10:46:14AM +0200, Kevin Wolf wrote:
> There's no reason to restrict transactions to operations related to
> block devices, so rename the type now before schema introspection stops
> us from doing so.
>
> Signed-off-by: Kevin Wolf
> ---
> blockdev.c | 22 +++-
On 05/13/2013 02:46 AM, Kevin Wolf wrote:
> There's no reason to restrict transactions to operations related to
> block devices, so rename the type now before schema introspection stops
> us from doing so.
>
> Signed-off-by: Kevin Wolf
> ---
> blockdev.c | 22 +++---
> qapi
On 05/13/2013 02:28 AM, Kevin Wolf wrote:
>>> +{ 'command': 'block-backup',
>>> + 'data': { 'device': 'str', 'target': 'str', '*format': 'str',
>>
>> Hmm - wondering if we should add an enum type for supported disk formats
>> instead of using free-form strings. The wire representation would be
>
Am 13.05.2013 um 14:56 hat Eric Blake geschrieben:
> On 05/13/2013 02:28 AM, Kevin Wolf wrote:
>
> >>> +{ 'command': 'block-backup',
> >>> + 'data': { 'device': 'str', 'target': 'str', '*format': 'str',
> >>
> >> Hmm - wondering if we should add an enum type for supported disk formats
> >> instea
On Mon, May 13, 2013 at 02:19:50PM +0200, Paolo Bonzini wrote:
> Il 13/05/2013 14:07, Peter Maydell ha scritto:
> > On 13 May 2013 12:48, David Gibson wrote:
> >> On Mon, May 13, 2013 at 12:10:10PM +0100, Peter Maydell wrote:
> >>> Hmm, is this the ideal semantics? Typically the owner of the
> >>>
On Mon, May 13, 2013 at 02:23:30PM +0200, Paolo Bonzini wrote:
> Il 13/05/2013 12:54, David Gibson ha scritto:
> > Specifically the way the iommu is
> > determined from a callback in the PCIBus means that it won't be
> > assigned for devices under a PCI-PCI bridge.
>
> Right. I saw the report fro
On Mon, 13 May 2013 15:09:31 +0200
Kevin Wolf wrote:
> Am 13.05.2013 um 14:56 hat Eric Blake geschrieben:
> > On 05/13/2013 02:28 AM, Kevin Wolf wrote:
> >
> > >>> +{ 'command': 'block-backup',
> > >>> + 'data': { 'device': 'str', 'target': 'str', '*format': 'str',
> > >>
> > >> Hmm - wondering
This series implements preliminary support for the ARM aarch64 TCG target.
Limitations of this initial implementation (TODOs) include:
* unconditional lookups in TLBs in qemu_ld/st via C helper functions
* most optional opcodes are not implemented yet
* CONFIG_SOFTMMU only
* only little endia
From: Petar Jovanovic
The mask for EXTP instruction when size=31 has not been correctly
calculated.
The test (mips32-dsp/extp.c) has been extended to include the case that
triggers the issue.
Signed-off-by: Petar Jovanovic
---
target-mips/dsp_helper.c |3 +--
tests/tcg/mips/mips32
From: Petar Jovanovic
This change makes sure that modifications of pos field in the DSPControl
register do not trash other bits in the register. This bug can be triggered
with the additional test case in mips32-dsp/extpdp.c in this commit.
In addition to this, this change corrects incorrect calc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 13/05/2013 15:13, David Gibson ha scritto:
> On Mon, May 13, 2013 at 02:23:30PM +0200, Paolo Bonzini wrote:
>> Il 13/05/2013 12:54, David Gibson ha scritto:
>>> Specifically the way the iommu is determined from a callback
>>> in the PCIBus means tha
we will use the 26bit relative relocations in the aarch64 tcg target.
Signed-off-by: Claudio Fontana
---
include/elf.h | 128 ++
1 file changed, 128 insertions(+)
diff --git a/include/elf.h b/include/elf.h
index a21ea53..43f6c9b 100644
--
add preliminary support for TCG target aarch64.
Signed-off-by: Claudio Fontana
---
include/exec/exec-all.h |5 +-
tcg/aarch64/tcg-target.c | 1084 ++
tcg/aarch64/tcg-target.h | 106 +
3 files changed, 1194 insertions(+), 1 deletion(-)
creat
Sorry about this. I'll rebase and add an mach-virt for aarch64 patch
and send out a v4. Please just ignore this mess untill then.
On Mon, May 13, 2013 at 2:54 AM, Peter Maydell wrote:
> On 13 May 2013 07:57, John Rigby wrote:
>> Resend of v3 with part 6 removed and change notes included.
>
> I
Paolo Bonzini writes:
> Using qemu_memalign only leaves the RAM zero by chance, because libc
> will usually use mmap to satisfy our huge requests. But memory will
> not be zero when using MALLOC_PERTURB_ with a nonzero value. In the
> case of incoming migration, this breaks a recently-introduce
This catches the situation that is described in the bug report at
https://bugs.launchpad.net/qemu/+bug/865518 and goes like this:
$ qemu-img create -f qcow2 huge.qcow2 $((1024*1024))T
Formatting 'huge.qcow2', fmt=qcow2 size=1152921504606846976 encryption=off
cluster_size=65536 lazy_refcou
On Fri, May 10, 2013 at 05:45:59PM -0500, Michael Roth wrote:
> These patches apply on top of qemu.git master, and can also be obtained from:
> git://github.com/mdroth/qemu.git qapi-native-lists
>
> Sending this now since a number of series have popped up in the past that
> wanted this, and Amos h
Suggestions for a better test case are welcome. But now that creating a large
image file fails, and if you somehow manage to create it anyway (qcow2.py)
opening it fails, it's hard to test the actual read/write cases.
Kevin Wolf (3):
qcow2: Catch some L1 table index overflows
qcow2.py: Subcomm
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/qcow2.py | 12
1 file changed, 12 insertions(+)
diff --git a/tests/qemu-iotests/qcow2.py b/tests/qemu-iotests/qcow2.py
index fecf5b9..b6abd16 100755
--- a/tests/qemu-iotests/qcow2.py
+++ b/tests/qemu-iotests/qcow2.py
@@ -149,6 +149,17
Il 07/05/2013 19:40, Peter Maydell ha scritto:
> On 7 May 2013 15:16, Paolo Bonzini wrote:
>> Checking whether an address space is possible in the old-style
>> IOMMU implementation, but there is no equivalent in the memory API.
>
> This sentence appears to be missing a clause ("whether
> an addre
It's supposed to fail gracefully instead of segfaulting.
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/054 | 58
tests/qemu-iotests/054.out | 10
tests/qemu-iotests/common.rc | 2 +-
tests/qemu-iotests/group | 1 +
4 files ch
Il 07/05/2013 20:20, Peter Maydell ha scritto:
> On 7 May 2013 15:16, Paolo Bonzini wrote:
>> The translate function in the DMAContext is now always NULL.
>> Remove every reference to it.
>
>> --- a/include/sysemu/dma.h
>> +++ b/include/sysemu/dma.h
>
>> -static inline int dma_memory_rw_relaxed(
support compiling on aarch64.
Signed-off-by: Claudio Fontana
---
configure | 8
1 file changed, 8 insertions(+)
diff --git a/configure b/configure
index 9439f1c..9cc398c 100755
--- a/configure
+++ b/configure
@@ -384,6 +384,8 @@ elif check_define __s390__ ; then
fi
elif check_defi
On 05/13/2013 07:18 AM, Luiz Capitulino wrote:
Luiz, any idea how to do something like this, a QAPI enum with values
that are determined at runtime? Especially with respect to the coming
schema introspection?
>>>
>>> Or maybe we make the 'enum' list ALL possible types, but then add a
Reported by Amos.
Paolo Bonzini (2):
osdep: rename qemu_vmalloc to qemu_anon_ram_alloc
osdep: introduce qemu_anon_ram_free to free qemu_anon_ram_alloc-ed memory
HACKING | 7 +++
exec.c | 14 +-
include/qemu/osdep.h | 3 ++-
include/sysemu/kvm.h |
This is preparatory to the introduction of a separate freeing API.
Reported-by: Amos Kong
Signed-off-by: Paolo Bonzini
---
HACKING | 7 +++
exec.c | 6 +++---
include/qemu/osdep.h | 2 +-
include/sysemu/kvm.h | 4 ++--
kvm-all.c| 6 +++---
target-s390x
We switched from qemu_memalign to mmap() but then we don't modify
qemu_vfree() to do a munmap() over free(). Which we cannot do
because qemu_vfree() frees memory allocated by qemu_{mem,block}align.
Introduce a new function that does the munmap(), luckily the size is
available in the RAMBlock.
Re
On 13 May 2013 15:19, Paolo Bonzini wrote:
> --- a/include/qemu/osdep.h
> +++ b/include/qemu/osdep.h
> @@ -98,6 +98,7 @@ int qemu_daemon(int nochdir, int noclose);
> void *qemu_memalign(size_t alignment, size_t size);
> void *qemu_anon_ram_alloc(size_t size);
> void qemu_vfree(void *ptr);
> +vo
Am 13.05.2013 um 16:14 hat Eric Blake geschrieben:
> On 05/13/2013 07:18 AM, Luiz Capitulino wrote:
> Luiz, any idea how to do something like this, a QAPI enum with values
> that are determined at runtime? Especially with respect to the coming
> schema introspection?
> >>>
> >>> Or m
On Mon, May 13, 2013 at 03:42:53PM +0200, Kevin Wolf wrote:
[...]
I tested the first patch (didn't try the tests) with qemu-img
and libguestfs and it works.
New qemu-img fails with:
qemu-img: The image size is too large for file format 'qcow2'
If you use the old qemu-img to create the file, and
> On 13 May 2013 15:19, Paolo Bonzini wrote:
> > --- a/include/qemu/osdep.h
> > +++ b/include/qemu/osdep.h
> > @@ -98,6 +98,7 @@ int qemu_daemon(int nochdir, int noclose);
> > void *qemu_memalign(size_t alignment, size_t size);
> > void *qemu_anon_ram_alloc(size_t size);
> > void qemu_vfree(voi
On 05/13/2013 08:27 AM, Kevin Wolf wrote:
> I think long term we'll need a dynamic schema anyway. As we go forward
> with modularisation and putting things into shared libraries, we'll have
> modules that add support for commands, enum values, etc.
In other words, qapi-schema.json should have a wa
Hi,
it looks like some "new" glib functions are used here which are
not available in older glib.
On Mon, Apr 22, 2013 at 5:04 PM, Alon Levy wrote:
> From: Marc-André Lureau
>
> This version handles non-blocking sending and receiving from the
> socket.
>
> Signed-off-by: Marc-André Lureau
> ---
Jordan Justen writes:
> The isapc machine with seabios currently requires the BIOS region
> to be read/write memory rather than read-only memory.
>
> KVM currently cannot support the BIOS as a ROM region, but qemu
> in non-KVM mode can. Based on this, isapc machine currently only
> works with KVM
On Mon, May 13, 2013 at 06:51:06AM -0600, Eric Blake wrote:
> On 05/13/2013 02:46 AM, Kevin Wolf wrote:
> > There's no reason to restrict transactions to operations related to
> > block devices, so rename the type now before schema introspection stops
> > us from doing so.
> >
> > Signed-off-by: K
Hi,
I'm trying to port an implementation of an ARM-based SoC from QEMU 1.4 to
QEMU 1.5.
I bumped into the following error:
qom/object.c:919:void object_property_add_child(Object *, const char *,
Object *, Error **): assertion failed: (child->parent == NULL)
which is due to an explicit call to:
On Mon, May 13, 2013 at 03:42:55PM +0200, Kevin Wolf wrote:
> Signed-off-by: Kevin Wolf
> ---
> tests/qemu-iotests/qcow2.py | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/tests/qemu-iotests/qcow2.py b/tests/qemu-iotests/qcow2.py
> index fecf5b9..b6abd16 100755
> --- a/tes
On Wed, Apr 10, 2013 at 04:11:52PM +0800, Dong Xu Wang wrote:
> add-cow file format core code. It use block-cache.c as cache code.
> It lacks of snapshot_blkdev support.
>
> Signed-off-by: Dong Xu Wang
> ---
> v17-v18:
> 1) use error_report, not fprintf.
> 2) remove version field from header.
> 3
Hi Anthony,
These are fix-ups for Laszlo's CVE-2013-2007 fix:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg170944.html
The main effect is to avoid cluttering filesystems with empty files if
we hit an error path in the open/create/chmod path.
I'm unable to confirm whether or not these er
From: Laszlo Ersek
In Windows guests this may make a difference.
Since the original patch (commit c689b4f1) sought to be pedantic and to
consider theoretical corner cases of portability, we should fix it up
where it failed to come through in that pursuit.
Suggested-by: Eric Blake
Reviewed-by:
From: Laszlo Ersek
We shouldn't allow guest filesystem pollution on error paths.
Suggested-by: Eric Blake
Signed-off-by: Laszlo Ersek
Reviewed-by: Eric Blake
Reviewed-by: Luiz Capitulino
Signed-off-by: Michael Roth
---
qga/commands-posix.c |3 +++
1 file changed, 3 insertions(+)
diff
From: Petar Jovanovic
First we need to clear the bit and then we set the given value.
Instruction ADDSC sets the bit and instruction ADDWC uses this bit.
Signed-off-by: Petar Jovanovic
---
target-mips/dsp_helper.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/ta
Hi,
Another issue on my old distro.
On Mon, Apr 22, 2013 at 5:04 PM, Alon Levy wrote:
> From: Marc-André Lureau
>
> It is needed to give that flag to the linker as well, but latest
> libtool 2.4.2 still swallows that argument, so let's pass it with
> libtool -Wc argument.
>
> qemu-1.4.0/stubs/a
On 05/13/13 01:19, Michael Marineau wrote:
> USB_DEV_FLAG_IS_HOST is the bit number, not value. Booting with a
> "Fitbit Base Station" USB dongle was triggering this assert.
>
> Signed-off-by: Michael Marineau
> ---
> hw/usb/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
On 29 April 2013 19:05, Anthony Liguori wrote:
> N.B. If you are on CC, see after the '---' for a requested action!
>
> The license of SoftFloat-2b is claimed to be GPLv2 incompatible by
> the FSF due to an indemnification clause. The previous release,
> SoftFloat-2a, did not contain this clause.
Pulled. Thanks.
Regards,
Anthony Liguori
Pulled. Thanks.
Regards,
Anthony Liguori
Applied. Thanks.
Regards,
Anthony Liguori
Applied. Thanks.
Regards,
Anthony Liguori
Applied. Thanks.
Regards,
Anthony Liguori
Applied. Thanks.
Regards,
Anthony Liguori
The isapc machine with seabios currently requires the BIOS region
to be read/write memory rather than read-only memory.
KVM currently cannot support the BIOS as a ROM region, but qemu
in non-KVM mode can. Based on this, isapc machine currently only
works with KVM.
To work-around this isapc issue,
Paolo/anyone who knows -
Are drive-mirror sync points (NBD flush commands) reflecting guest write
barriers? Are guest write barriers respected by drive-mirror? If so, that
would make drive-mirror much more palatable for disk introspection work (a
drop-in usable feature of QEMU!).
--
Wolf
On 13 May 2013 14:33, Claudio Fontana wrote:
>
> add preliminary support for TCG target aarch64.
Thanks for this patch. Some comments below.
> Signed-off-by: Claudio Fontana
> ---
> include/exec/exec-all.h |5 +-
> tcg/aarch64/tcg-target.c | 1084
> +++
On 13 May 2013 14:28, Claudio Fontana wrote:
>
> support compiling on aarch64.
>
> Signed-off-by: Claudio Fontana
This looks good, but it should be the last patch in the series,
so we don't allow the support to be enabled until the code
that implements it is present.
thanks
-- PMM
On 13 May 2013 14:31, Claudio Fontana wrote:
>
> we will use the 26bit relative relocations in the aarch64 tcg target.
This patch looks OK, but can I ask you to just neaten up
the #defines by making the column of values line up?
(use spaces, not hardcoded tabs).
> @@ -616,6 +618,132 @@ typedef s
1 - 100 of 183 matches
Mail list logo
