Version 3 of series to add Aarch64 support.
Alexander Graf (11):
ARM: Export cpu_env
ARM: Prepare translation for AArch64 code
ARM: Add AArch64 translation stub
AArch64: Add gdb stub
linux-user: Don't treat aarch64 cpu names specially
linux-user: AArch64 requires at least 3.8.0
From: Alexander Graf ag...@suse.de
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.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
target-arm/translate.c |
From: Alexander Graf ag...@suse.de
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
From: Alexander Graf ag...@suse.de
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
From: Alexander Graf ag...@suse.de
This patch adds all the prerequisites for AArch64 support that didn't
fit into split up patches. It extends important bits in the core cpu
headers to also take AArch64 mode into account.
Add new ARM_TBFLAG_AARCH64_STATE translation buffer flag
indicate an ARMv8
From: Alexander Graf ag...@suse.de
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
From: Andreas Schwab sch...@suse.de
This patch adds signal handling for AArch64. The code is based on the
respective source in the Linux kernel.
Signed-off-by: Andreas Schwab sch...@suse.de
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
gdb-xml/aarch64-core.xml |
From: Alexander Graf ag...@suse.de
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
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
Signed-off-by: John Rigby
ignore this part 6/12 one, somehow I neglected to remove it from the series
the fix in 12/12 is the one riku recommended
From: Alexander Graf ag...@suse.de
This patch adds support for AArch64 in all the small corners of
linux-user and beyond.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
default-configs/aarch64-linux-user.mak | 3 +
linux-user/aarch64/syscall.h
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
On 05/11/13 00:45, 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 has some pending patches
Resend of v3 with part 6 removed and change notes included.
Alexander Graf (10):
ARM: Export cpu_env
ARM: Prepare translation for AArch64 code
ARM: Add AArch64 translation stub
AArch64: Add gdb stub
linux-user: Don't treat aarch64 cpu names specially
linux-user: Add syscall handling
From: Alexander Graf ag...@suse.de
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.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
Changes in v3:
- None
From: Alexander Graf ag...@suse.de
This patch adds all the prerequisites for AArch64 support that didn't
fit into split up patches. It extends important bits in the core cpu
headers to also take AArch64 mode into account.
Add new ARM_TBFLAG_AARCH64_STATE translation buffer flag
indicate an ARMv8
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
Changes in v3:
- fix
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
From: Alexander Graf ag...@suse.de
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
From: Alexander Graf ag...@suse.de
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 ag...@suse.de
Signed-off-by: John Rigby
From: Alexander Graf ag...@suse.de
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
From: Andreas Schwab sch...@suse.de
This patch adds signal handling for AArch64. The code is based on the
respective source in the Linux kernel.
Signed-off-by: Andreas Schwab sch...@suse.de
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
Changes
From: Alexander Graf ag...@suse.de
This patch adds support for AArch64 in all the small corners of
linux-user and beyond.
Signed-off-by: Alexander Graf ag...@suse.de
Signed-off-by: John Rigby john.ri...@linaro.org
---
Changes in v3:
- Aarch64 files go in linux-user/aarch64 instead of ifdefs in
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,
From: Alexander Graf ag...@suse.de
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
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 low-level
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 block device to a new
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 kw...@redhat.com
---
blockdev.c | 22 +++---
qapi-schema.json | 8
2 files
On 13 May 2013 07:57, John Rigby john.ri...@linaro.org 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 al...@redhat.com 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 al...@redhat.com
---
v3: use RAM_ADDR_FMT
Il 13/05/2013 05:21, Liu Ping Fan ha scritto:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
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
On 13 May 2013 07:57, John Rigby john.ri...@linaro.org 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
Il 13/05/2013 05:21, Liu Ping Fan ha scritto:
From: Liu Ping Fan pingf...@linux.vnet.ibm.com
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
Hi
Please send in any agenda topics you are interested in.
Later, Juan.
Am 13.05.2013 um 11:28 schrieb Peter Maydell peter.mayd...@linaro.org:
On 13 May 2013 07:57, John Rigby john.ri...@linaro.org 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.
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
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
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
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 da...@gibson.dropbear.id.au
---
hw/i386/kvm/ioapic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/kvm/ioapic.c
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
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
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
On 13 May 2013 11:54, David Gibson da...@gibson.dropbear.id.au 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
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 paid more
On Mon, May 13, 2013 at 12:10:10PM +0100, Peter Maydell wrote:
On 13 May 2013 11:54, David Gibson da...@gibson.dropbear.id.au 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
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 da...@gibson.dropbear.id.au 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
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 of the 1 30
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
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 da...@gibson.dropbear.id.au
---
hw/i386/kvm/ioapic.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 pbonz...@redhat.com writes:
Il 10/05/2013 17:11, Anthony Liguori ha scritto:
Chegu Vinod chegu_vi...@hp.com writes:
On 5/10/2013 6:07 AM, Anthony Liguori wrote:
Chegu Vinod chegu_vi...@hp.com writes:
If a user chooses to turn on the auto-converge migration capability
Il 13/05/2013 14:07, Peter Maydell ha scritto:
On 13 May 2013 12:48, David Gibson da...@gibson.dropbear.id.au 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
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 berra...@redhat.com writes:
On Fri, May 10, 2013 at 08:07:51AM -0500, Anthony Liguori wrote:
Chegu Vinod chegu_vi...@hp.com writes:
If a user chooses to turn on the auto-converge migration capability
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 kw...@redhat.com
---
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 kw...@redhat.com
---
blockdev.c | 22
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
the same,
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
instead of using
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 da...@gibson.dropbear.id.au wrote:
On Mon, May 13, 2013 at 12:10:10PM +0100, Peter Maydell wrote:
Hmm, is this the ideal semantics? Typically 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 from
On Mon, 13 May 2013 15:09:31 +0200
Kevin Wolf kw...@redhat.com 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 if we
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
From: Petar Jovanovic petar.jovano...@imgtec.com
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 petar.jovano...@imgtec.com
---
From: Petar Jovanovic petar.jovano...@imgtec.com
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
-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 that it
we will use the 26bit relative relocations in the aarch64 tcg target.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
include/elf.h | 128 ++
1 file changed, 128 insertions(+)
diff --git a/include/elf.h b/include/elf.h
index
add preliminary support for TCG target aarch64.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
include/exec/exec-all.h |5 +-
tcg/aarch64/tcg-target.c | 1084 ++
tcg/aarch64/tcg-target.h | 106 +
3 files changed, 1194
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 peter.mayd...@linaro.org wrote:
On 13 May 2013 07:57, John Rigby john.ri...@linaro.org wrote:
Resend of v3 with part
Paolo Bonzini pbonz...@redhat.com 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
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
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 has
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:
Signed-off-by: Kevin Wolf kw...@redhat.com
---
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
Il 07/05/2013 19:40, Peter Maydell ha scritto:
On 7 May 2013 15:16, Paolo Bonzini pbonz...@redhat.com 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
It's supposed to fail gracefully instead of segfaulting.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
tests/qemu-iotests/054 | 58
tests/qemu-iotests/054.out | 10
tests/qemu-iotests/common.rc | 2 +-
tests/qemu-iotests/group |
Il 07/05/2013 20:20, Peter Maydell ha scritto:
On 7 May 2013 15:16, Paolo Bonzini pbonz...@redhat.com 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
support compiling on aarch64.
Signed-off-by: Claudio Fontana claudio.font...@huawei.com
---
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__ ;
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
query-* command
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 ak...@redhat.com
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
HACKING | 7 +++
exec.c | 6 +++---
include/qemu/osdep.h | 2 +-
include/sysemu/kvm.h | 4 ++--
kvm-all.c
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.
On 13 May 2013 15:19, Paolo Bonzini pbonz...@redhat.com 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
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 maybe we make the 'enum'
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 pbonz...@redhat.com 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
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 way
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 al...@redhat.com wrote:
From: Marc-André Lureau marcandre.lur...@gmail.com
This version handles non-blocking sending and receiving from the
socket.
Jordan Justen jordan.l.jus...@intel.com 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
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: Kevin Wolf
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 kw...@redhat.com
---
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
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 wdon...@linux.vnet.ibm.com
---
v17-v18:
1) use error_report, not fprintf.
2) remove version
1 - 100 of 199 matches
Mail list logo
