* 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
** 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
** 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
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à
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
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 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 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
* 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 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
> + --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 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
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 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
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 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: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
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 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
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
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 +-
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 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
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 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
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
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
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
- "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
> 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
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
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 (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, 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 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
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
>
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_
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(+
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
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
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
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
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(+),
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
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
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
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
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
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
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
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.
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
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
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",
>
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
58 matches
Mail list logo