Miguel Di Ciurcio Filho writes:
> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka 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 some basic tests and
>>> networ
Markus Armbruster wrote:
> Miguel Di Ciurcio Filho 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 = "hostfwd_add",
>
Markus Armbruster wrote:
> Miguel Di Ciurcio Filho writes:
>
>> On Tue, Jul 13, 2010 at 3:16 AM, Jan Kiszka 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 d
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
> ---
> hw/pci.c | 21 +
> 1 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/hw/pci.c
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
(ch
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 signal=on
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.
Signed-off-by:
fail_gd error case would also free rgd_buf that was already freed
Signed-off-by: Juan Quintela
Signed-off-by: Anthony Liguori
(cherry picked from commit a161329b61106ab093aab6d3227ac85e0b8251a9)
Conflicts:
block/vmdk.c
Signed-off-by: Kevin Wolf
---
block/vmdk.c |2 +-
1 files ch
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
(cherry picked from commit 003fad6e2cae5311d3a
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf
(cherry picked from commit 8b3b720620a1137a1b794fc3ed64734236f94e06)
Conflicts:
block/qcow2-cluster.c
block/qcow2-refcount.c
block/qcow2-snapshot.c
block/qcow2.c
Si
From: Stefan Weil
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 qemu-img convert).
Inst
If writing the L1 table to disk failed, we need to restore its old content in
memory to avoid inconsistencies.
Reported-by: Juan Quintela
Signed-off-by: Kevin Wolf
(cherry picked from commit 68dba0bf455e60061bb3c9c40ef0d82916372664)
---
block/qcow2-cluster.c |1 +
1 files changed, 1 inserti
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 wh
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf
(cherry picked from commit 078a458e077d6b0db262c4b05fee51d01de2d1d2)
Conflicts:
block/vpc.c
Signed-off-by: Kevin Wolf
---
block/vpc.c |9 +
1 files changed, 5 insertions(+),
The fix is based on a patch from Kevin Wolf. Here his comment:
"The number of blocks needs to be rounded up to cover all of the virtual hard
disk. Without this fix, we can't even open our own images if their size is not
a multiple of the block size."
While Kevin's patch addressed vdi_create, my m
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
(cherry picked from commit 453f9a1652629e5805995b165be2e634c8487139)
Conflicts:
b
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.
* C
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf
(cherry picked from commit 5e5557d97026d1d3325e0e7b0ba593366da2f3dc)
Conflicts:
block/qcow.c
Signed-off-by: Kevin Wolf
---
block/qcow.c | 18 ++
1 files changed, 10 ins
Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash.
Signed-off-by: Kevin Wolf
(cherry picked from commit b8852e87d9d113096342c3e0977266cda0fe9ee5)
Conflicts:
block/vmdk.c
Signed-off-by: Kevin Wolf
---
block/vmdk.c | 10 +-
1 files changed, 5 insertions(+
This mistake makes PCI devices can't work correctly.
Signed-off-by: Huacai Chen
---
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 +775,6 @@ PCIBus *bonito_
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
> ---
> hw/bonito.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Thanks, applied.
> diff --git a/hw/bonito.c b/hw/bonito.c
> index
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 0c0f53e2
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
> virtque
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 t
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
Ping
Amit
> 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 wher
- "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.
>
> Ensure the vi
On Tue, Jul 13, 2010 at 8:52 PM, Isaku Yamahata 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
>> wrote:
>> > On Tue, Jul 13, 2010 at 02:05:51PM -0600, Cam Macdonell wrote:
>> >> >> > Seabios completely ignore the 64-bit
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 the
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 u
On Tue, 13 Jul 2010 21:01:33 -0300
Marcelo Tosatti 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: Marcelo
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 probi
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 parame
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 u
Create USB buses and devices based on USB version.
Signed-off-by: David Ahern
---
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 +-
hw/usb-uhci.c |2 +-
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 c
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
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 a
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 gu
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 gu
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 ne
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 insi
On Tue, 13 Jul 2010 18:20:20 +0200
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Tue, 13 Jul 2010 13:49:46 +0200
> > Markus Armbruster wrote:
> >
> >> [cc: kraxel]
> >>
> >> I didn't get around to review v1. Sorry.
> >>
> >> Miguel Di Ciurcio Filho writes:
> >>
> >> > Change
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
---
kvm-all.c
> 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
> + --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 IO
* 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 rea
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 IOM
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 I
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 h
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, wh
** 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, wh
* Venkateswararao Jujjuri (JV) [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 check the thread-i
58 matches
Mail list logo
