Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/rtl8139.c | 98 -
1 files changed, 62 insertions(+), 36 deletions(-)
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
On Wed, 14 Jul 2010, Eduard - Gabriel Munteanu wrote:
This provides an API for abstracting IOMMU functions. Hardware emulation
code can use it to request address translation and access checking. In
the absence of an emulated IOMMU, no translation/checking happens and
I/O goes through as
On Wed, 14 Jul 2010, Eduard - Gabriel Munteanu wrote:
Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/ac97.c | 20 +---
1 files changed, 17 insertions(+), 3 deletions(-)
Fine with me.
Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes:
---
qemu-doc.texi | 24 +++-
1 files changed, 3 insertions(+), 21 deletions(-)
diff --git a/qemu-doc.texi b/qemu-doc.texi
index e2c8e56..d5bf318 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
[...]
@@ -794,7
Does -net user still do anything useful with VLAN gone?
Let's take a step back and consider: what's left of -net with VLAN gone?
I guess it's just -net none and -net nic,netdev=...
If that's true, the documentation for the backend types user, ... needs
to move to -netdev.
Since we're breaking
Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes:
---
hw/qdev-properties.c | 39 --
hw/qdev.c|2 -
hw/qdev.h|5 -
hw/xen_devconfig.c |8 +-
hw/xen_nic.c |1 -
net.c| 323
Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes:
On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka jan.kis...@web.de wrote:
Miguel Di Ciurcio Filho wrote:
This series removes the vlan stuff without mercy. I've tried to make the
steps
as small as possible, but the last one is huge. I did
Markus Armbruster wrote:
Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes:
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 275f3bc..e2c2a75 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -1224,8 +1224,8 @@ EQMP
#ifdef CONFIG_SLIRP
{
.name =
Markus Armbruster wrote:
Miguel Di Ciurcio Filho miguel.fi...@gmail.com writes:
On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka jan.kis...@web.de wrote:
Miguel Di Ciurcio Filho wrote:
This series removes the vlan stuff without mercy. I've tried to make the
steps
as small as possible, but the
On Wed, Jul 14, 2010 at 08:45:03AM +0300, Eduard - Gabriel Munteanu wrote:
Memory accesses must go through the IOMMU layer.
Signed-off-by: Eduard - Gabriel Munteanu eduard.munte...@linux360.ro
---
hw/pci.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
I'm not very experienced with kernel development, so didn't try to
create a patch for now. It wasn't even immediately obvious were to send
patches to. If nobody else wants to work on the issue I'll try to
allocate some time for it. Pretty amazing how the bug got in the kernel
in the first place.
qcow_create2 assumes that the new image will only need one cluster for its
refcount table initially. Obviously that's not true any more when the image is
big enough (exact value depends on the cluster size).
This patch calculates the refcount table size dynamically.
Signed-off-by: Kevin Wolf
Hi Aurelien,
these are the block related patches that have been applied to git master since
0.12.4 was released and that I consider relevant for stable-0.12.
Kevin
The following changes since commit 0c0f53e25cded4b3b1909391f9bf22d334ed8155:
qemu-options: add documentation for stdio
When trying to do COW, VMDK wrote the data back to the backing file. This
problem was revealed by the patch that made backing files read-only. This patch
does not only fix the problem, but also simplifies the VMDK code a bit.
This fixes the backing file qemu-iotests cases for VMDK.
fail_gd error case would also free rgd_buf that was already freed
Signed-off-by: Juan Quintela quint...@redhat.com
Signed-off-by: Anthony Liguori aligu...@us.ibm.com
(cherry picked from commit a161329b61106ab093aab6d3227ac85e0b8251a9)
Conflicts:
block/vmdk.c
Signed-off-by: Kevin Wolf
While it's true that during regular operation free_clusters failure would be a
bug, an I/O error can always happen. There's no need to kill the VM, the worst
thing that can happen (and it will) is that we leak some clusters.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 8b3b720620a1137a1b794fc3ed64734236f94e06)
Conflicts:
block/qcow2-cluster.c
block/qcow2-refcount.c
block/qcow2-snapshot.c
From: Stefan Weil w...@mail.berlios.de
The VHD algorithm calculates a disk geometry
which is usually smaller than the requested size.
QEMU tried to round up but failed for certain sizes:
qemu-img create -f vpc disk.vpc 9437184
would create an image with 9435136 bytes
(which is too small for
If writing the L1 table to disk failed, we need to restore its old content in
memory to avoid inconsistencies.
Reported-by: Juan Quintela quint...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 68dba0bf455e60061bb3c9c40ef0d82916372664)
---
block/qcow2-cluster.c
Add new functions that write and flush the written data to disk immediately.
This is what needs to be used for image format metadata to maintain integrity
for cache=... modes that don't use O_DSYNC. (Actually, we only need barriers,
and therefore the functions are defined as such, but flushes is
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 078a458e077d6b0db262c4b05fee51d01de2d1d2)
Conflicts:
block/vpc.c
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vpc.c |9 +
1
bdrv_aio_writev may call the callback immediately (and it will commonly do so
in error cases). Current code doesn't consider this. For details see the
comment added by this patch.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 453f9a1652629e5805995b165be2e634c8487139)
Don't try to be clever by freeing all temporary data and calling all callbacks
when the return value (an error) is certain. Doing so has at least two
important problems:
* The temporary data that is freed (qiov, possibly zero buffer) is still used
by the requests that have not yet completed.
*
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit 5e5557d97026d1d3325e0e7b0ba593366da2f3dc)
Conflicts:
block/qcow.c
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/qcow.c | 18
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf kw...@redhat.com
(cherry picked from commit b8852e87d9d113096342c3e0977266cda0fe9ee5)
Conflicts:
block/vmdk.c
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/vmdk.c | 10 +-
This mistake makes PCI devices can't work correctly.
Signed-off-by: Huacai Chen zltjiang...@gmail.com
---
hw/bonito.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/hw/bonito.c b/hw/bonito.c
index 8b81032..dcf0311 100644
--- a/hw/bonito.c
+++ b/hw/bonito.c
@@ -775,7
Arun R Bharadwaj wrote:
Hi,
This patch cleans up the legacy 'dotu' variable which is always set to
1 by default, since qemu doesnt support legacy 9p clients.
Do we have 2/2 in this series? Also please check the thread-id.
It is showing part of your other patch, TLERROR/RLERROR.
- JV
On Wed, Jul 14, 2010 at 07:51:49PM +0800, Huacai Chen wrote:
This mistake makes PCI devices can't work correctly.
Signed-off-by: Huacai Chen zltjiang...@gmail.com
---
hw/bonito.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
Thanks, applied.
diff --git a/hw/bonito.c
On Wed, Jul 14, 2010 at 01:23:59PM +0200, Kevin Wolf wrote:
Hi Aurelien,
these are the block related patches that have been applied to git master since
0.12.4 was released and that I consider relevant for stable-0.12.
Thanks, pulled.
The following changes since commit
On (Thu) Jul 01 2010 [14:58:16], Amit Shah wrote:
If a virtio-serial port is removed before the guest comes up and
initialises the virtqueues, qemu exits with the message
Guest moved used index from 0 to 61440
This happens because we try to clear any pending buffers from the
virtqueue.
On (Wed) Jun 23 2010 [22:49:20], Amit Shah wrote:
Starting with qemu -M pc-0.12 -device virtio-serial
results in
-device virtio-serial: Property 'virtio-serial-pci.max_nr_ports' not found
The property name 'max_ports' is incorrectly named 'max_nr_ports'. Fix
that.
Also fix the ppc440
On (Wed) Jun 23 2010 [20:14:04], Amit Shah wrote:
qemu-config.c doesn't contain any target-specific code, and the
TARGET_I386 conditional code didn't get compiled as a result. Removing
this enables the driftfix parameter for rtc.
Signed-off-by: Amit Shah amit.s...@redhat.com
Ping
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
You should be adding a DeviceState argument to cpu_physical_memory_{rw,map}.
This should then handle IOMMU translation transparently.
You also need to accomodate the the case
- Amit Shah amit.s...@redhat.com wrote:
If a virtio-serial port is removed before the guest comes up and
initialises the virtqueues, qemu exits with the message
Guest moved used index from 0 to 61440
This happens because we try to clear any pending buffers from the
virtqueue.
On Tue, Jul 13, 2010 at 8:52 PM, Isaku Yamahata yamah...@valinux.co.jp wrote:
On Tue, Jul 13, 2010 at 04:48:19PM -0600, Cam Macdonell wrote:
On Tue, Jul 13, 2010 at 2:41 PM, Isaku Yamahata yamah...@valinux.co.jp
wrote:
On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote:
Hi,
I would like to remind everybody that the deadline for submitting a
proposal to Linux Plumbers 2010 is nearing, so this is the time to get
your proposals in. The deadline is July 19th!
There has been some confusion about the submission process and I have
only just found out myself what is
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, and the vast majority of
On Tue, 13 Jul 2010 21:01:33 -0300
Marcelo Tosatti mtosa...@redhat.com wrote:
If -write fails, declare migration status as MIG_STATE_ERROR.
Also, in buffered_file.c, -close the object in case of an
error.
Fixes migrate -d exec:dd of=file, where dd fails to open file.
Signed-off-by:
Am 14.07.2010 18:12, schrieb Anthony Liguori:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
On 07/14/2010 11:42 AM, Kevin Wolf wrote:
Am 14.07.2010 18:12, schrieb Anthony Liguori:
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format
CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could
trick the block probing code into accessing arbitrary files in a guest. To
mitigate this, we added an explicit format parameter to -drive which disabling
block probing.
Fast forward to today, and the vast majority of
Create USB buses and devices based on USB version.
Signed-off-by: David Ahern daah...@cisco.com
---
hw/usb-bus.c| 70 ---
hw/usb-msd.c|2 +-
hw/usb-net.c|2 +-
hw/usb-ohci.c |2 +-
hw/usb-serial.c |4 +-
This patch improves the resilience of the load_vmstate() function, doing
further and better ordered tests.
In load_vmstate(), if there is any error on bdrv_snapshot_goto(), except if the
error is on VM state device, load_vmstate() will return zero and the VM will be
started with major corruption
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
There are real devices that care very much about an IOMMU. Basically all
devices supporting ATS care about that. So I
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for nested virtualization I guess this use case will become
rather common, just
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for nested virtualization I
On 07/14/2010 01:43 PM, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for nested virtualization I
On Wed, Jul 14, 2010 at 08:43:11PM +0200, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image inside an image, and with hardware
support for
On 07/14/2010 01:54 PM, Aurelien Jarno wrote:
On Wed, Jul 14, 2010 at 08:43:11PM +0200, Christoph Hellwig wrote:
Err, strong NACK. Please don't start messing with the contents of the
data plane, we're getting into real trouble there. It's perfectly
valid for a guest to create an image
On Tue, 13 Jul 2010 18:20:20 +0200
Markus Armbruster arm...@redhat.com wrote:
Luiz Capitulino lcapitul...@redhat.com writes:
On Tue, 13 Jul 2010 13:49:46 +0200
Markus Armbruster arm...@redhat.com wrote:
[cc: kraxel]
I didn't get around to review v1. Sorry.
Miguel Di Ciurcio
If we've unregistered a memory area, we should avoid calling
qemu_get_ram_ptr() on the left over phys_offset cruft in the
slot array. Now that we support removing ramblocks, the
phys_offset ram_addr_t can go away and cause a lookup fault
and abort.
Signed-off-by: Alex Williamson
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
There are real devices that care very much about an IOMMU. Basically all
devices supporting ATS care about
+ --enable-amd-iommu-emul) amd_iommu=yes
+#ifdef CONFIG_AMD_IOMMU
+amd_iommu_init(pci_bus);
+#endif
This should not be a configure option.
Paul
On 07/14/2010 03:13 PM, Paul Brook wrote:
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
There are real devices that care very much about an
* Anthony Liguori (anth...@codemonkey.ws) wrote:
On 07/14/2010 03:13 PM, Paul Brook wrote:
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
There are real devices that
On Wed, Jul 14, 2010 at 10:07:20AM +0400, malc wrote:
On Wed, 14 Jul 2010, Eduard - Gabriel Munteanu wrote:
This provides an API for abstracting IOMMU functions. Hardware emulation
code can use it to request address translation and access checking. In
the absence of an emulated IOMMU, no
On Wed, Jul 14, 2010 at 04:37:39PM +0900, Isaku Yamahata wrote:
On Wed, Jul 14, 2010 at 08:45:03AM +0300, Eduard - Gabriel Munteanu wrote:
[snip]
PCIDevice *pci_register_device(PCIBus *bus, const char *name,
int instance_size, int devfn,
On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
They don't really care. iommu_get() et al. are convenience functions
which can and do return NULL when there's no
On Wed, Jul 14, 2010 at 09:13:44PM +0100, Paul Brook wrote:
Well, ok, the function name needs fixing too. However I think the only thing
missing from the current API is that it does not provide a way to determine
which device is performing the access.
Depending how the we decide to
Clicca qui per accedere alle soluzioni finanziarie
Novità: Prestito personale Veloce ( delibera entro 60 minuti )
prestito con cessione del quinto e prestito con delega
Prestito Ipotecario Vitalizio: prendi i soldi e non li rendi
Aziende in crisi: gestione dei debiti e rilancio dell'attività
** Changed in: qemu-kvm (Ubuntu)
Importance: Undecided = Medium
--
qemu-system-arm segfaults emulating versatile machine after running debootstrap
--second-stage inside vm
https://bugs.launchpad.net/bugs/604872
You received this bug notification because you are a member of qemu-
devel-ml,
** Changed in: qemu-kvm (Ubuntu)
Importance: Medium = Undecided
--
qemu-system-arm segfaults emulating versatile machine after running debootstrap
--second-stage inside vm
https://bugs.launchpad.net/bugs/604872
You received this bug notification because you are a member of qemu-
devel-ml,
* Venkateswararao Jujjuri (JV) jv...@linux.vnet.ibm.com [2010-07-14 04:25:21]:
Arun R Bharadwaj wrote:
Hi,
This patch cleans up the legacy 'dotu' variable which is always set to
1 by default, since qemu doesnt support legacy 9p clients.
Do we have 2/2 in this series? Also please
63 matches
Mail list logo