This patch adds the final missing bits for support of
passing a serial/id string to a virtio-blk guest driver.
The guest-side component already exists in the virtio
driver, and has recently been reworked by Ryan to export
a /sys interface for retrival of the id from guest userland.
Subject is confusing: suggests a series of four parts.
john cooper john.coo...@redhat.com writes:
This patch adds the final missing bits for support of
passing a serial/id string to a virtio-blk guest driver.
The guest-side component already exists in the virtio
driver, and has recently
Markus Armbruster wrote:
Subject is confusing: suggests a series of four parts.
Sorry. My bad for recycling old mail.
Looks like this conflicts with my PATCH v3 00/13] More block-related
fixes and cleanups.
Perhaps the easiest way to get this in would be to rebase to Kevin's
block
(gdb) run
Starting program: /usr/bin/kvm -M pc-0.12 -enable-kvm -m 256 -smp 1 -boot d
-drive file=/mnt/megadiff/cdiso_400_130.iso,if=ide,media=cdrom,index=2 -drive
file=/home/mmarkk/spamsender2.img,if=scsi,index=0,format=qcow2,cache=writeback
[Thread debugging using libthread_db enabled]
[New
scsi-disk: Tag 0x0 already in use
maybe problem here?
--
KVM segmentation fault, using SCSI+writeback and linux 2.4 guest
https://bugs.launchpad.net/bugs/595438
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug
sudo apt-get install libaio1-dbg libcomerr2-dbg libdbus-glib-1-2-dbg
libgcrypt11-dbg keyutils-dbg libncurses5-dbg zlib1g-dbg libc6-dbg
libcurl3-dbg libdirectfb-1.2-0-dbg libgnutls26-dbg libkrb5-dbg
libice6-dbg libldap-2.4-2-dbg libogg-dbg libpulse0-dbg gsasl-dbg
libsm6-dbg libtasn1-3-dbg
On Thu, Jul 1, 2010 at 8:30 PM, Eduard - Gabriel Munteanu
eduard.munte...@linux360.ro wrote:
On Wed, Jun 30, 2010 at 09:37:31AM +0100, Stefan Hajnoczi wrote:
On Tue, Jun 29, 2010 at 6:25 PM, Eduard - Gabriel Munteanu
eduard.munte...@linux360.ro wrote:
On the other hand, we could just leave it
[cc: kraxel]
Hidetoshi Seto seto.hideto...@jp.fujitsu.com writes:
(2010/06/30 15:53), Markus Armbruster wrote:
Summary: upstream qemu commit b560a9ab broke -pcidevice and pci_add host
in two ways:
* Use without options id and name is broken when option host contains
':'. That's because
On Thu, Jul 1, 2010 at 3:31 PM, Kevin Wolf kw...@redhat.com wrote:
bdrv_aio_writev may call the callback immediately (and it will commonly do so
in error cases). If num_requests doesn't have its final value yet,
multiwrite_cb will falsely detect that all requests are completed and frees
the
On Thu, Jul 1, 2010 at 3:31 PM, Kevin Wolf kw...@redhat.com wrote:
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
On 07/01/10 19:53, Stefan Weil wrote:
Two patches are needed anyway.
For reasons of economy, I won't send a new patch.
Feel free do send one which meets your criteria.
Regards,
Stefan
Well if you are not interested in working the way the community works,
please don't expect us to fix
Hi,
As far as I can tell, name predates the qdev conversion, and was used
just for error messages and such.
Yes, was already there when I touched the code the first time.
It defaulted to host. When Gerd
did the qdev conversion, he made id default to name, then host.
See commit 6b5bbd04.
On Thu, Jul 01, 2010 at 04:31:57PM +0200, Kevin Wolf wrote:
bdrv_aio_writev may call the callback immediately (and it will commonly do so
in error cases). If num_requests doesn't have its final value yet,
multiwrite_cb will falsely detect that all requests are completed and frees
the mcb.
On Thu, Jul 01, 2010 at 04:31:58PM +0200, Kevin Wolf wrote:
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
On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
On Thu, Jul 1, 2010 at 8:30 PM, Eduard - Gabriel Munteanu
eduard.munte...@linux360.ro wrote:
On Wed, Jun 30, 2010 at 09:37:31AM +0100, Stefan Hajnoczi wrote:
On Tue, Jun 29, 2010 at 6:25 PM, Eduard - Gabriel Munteanu
Yeah. I have compile non-stripped kvm binary.
(gdb) bt
#0 0x0852cd88 in ?? ()
#1 0x080f0f16 in scsi_command_complete (r=0x86252d8, status=value optimized
out, sense=value optimized out)
at /home/mmarkk/src/KVM/qemu-kvm-0.12.3+noroms/hw/scsi-disk.c:105
#2 0x080d4d19 in qcow_aio_write_cb
/* Helper function for command completion. */
static void scsi_command_complete(SCSIDiskReq *r, int status, int sense)
{
DPRINTF(Command complete tag=0x%x status=%d sense=%d\n,
r-req.tag, status, sense);
scsi_req_set_status(r-req, status, sense);
scsi_req_complete(r-req);
On Thu, Jul 01, 2010 at 04:35:53PM -0500, Rob Landley wrote:
I just confirmed that Vincent Sanders' patch (which he posted on May 29, 2009,
and again on November 27, 2009) still applies to (and works with )current
qemu-git.
It adds a -cpu arm920t option to qemu-system-arm which boots a Linux
On Fri, Jul 2, 2010 at 5:23 AM, Ananth N Mavinakayanahalli
ana...@in.ibm.com wrote:
On Wed, Jun 30, 2010 at 12:51:59PM +0100, Stefan Hajnoczi wrote:
On Wed, Jun 30, 2010 at 11:20 AM, Prerna Saxena
pre...@linux.vnet.ibm.com wrote:
On 06/26/2010 01:36 PM, Stefan Hajnoczi wrote:
Here are the
void scsi_req_complete(SCSIRequest *req)
{
assert(req-status != -1);
req-bus-complete(req-bus, SCSI_REASON_DONE,
req-tag,
req-status);
}
(gdb) bt 1
#0 0x0852cd88 in ?? ()
(More stack frames follow...)
(gdb) frame 1
#1 0x080f0f16 in
Set up host kernel include paths specified by --kerneldir
When host kernel headers are placed in non-standard paths, the
KVM_CFLAGS are presently invoked only for a few .c files
(kvm*.c,vhost*.c) and not for other files like machine.c, cpus.c
..etc which also depend on linux/kvm.h
The bdrv_aio_multiwrite error handling has some bugs that lead to premature
cleanup, causing use-after-free and double free problems.
v2:
- Completely replaced patch 1 which Stefan found to be incorrect (thanks for
the good review!). Hope I've got it right this time.
Kevin Wolf (2):
block:
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.
*
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
---
block.c | 35 +--
1 files changed,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello.
I noticed that qcow2 images, esp. fresh ones (so that they
receive lots of metadata updates) are very slow on my
machine. And on IRC (#kvm), Sheldon Hearn found that on
ext3, it is fast again.
So I tested different combinations for a bit,
On Fri, Jul 2, 2010 at 1:07 PM, Kevin Wolf kw...@redhat.com wrote:
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
Am 02.07.2010 15:18, schrieb Stefan Hajnoczi:
On Fri, Jul 2, 2010 at 1:07 PM, Kevin Wolf kw...@redhat.com wrote:
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.
On 04/09/2010 01:20 PM, Stefan Weil wrote:
Some restrictions why qemu-common.h was not used might be no longer
valid (I think they came from pre-tcg times). Nevertheless,
cris-dis.c even says that it cannot include qemu-common.h (without
giving a reason).
I think these are no longer valid. In
On 07/02/2010 08:37 AM, Paolo Bonzini wrote:
The second (more real) reason is inline assembly failures, for example
(32-bit x86):
register int e asm(edi);
static inline int h()
{
int x;
asm volatile (mov $0, %0 : =D (x));
}
int g()
{
The following changes since commit 8713f8ffb87a28c94b4f22b9a9ec16c55381187e:
Andi Kleen (1):
Don't declare XSAVE as supported
are available in the git repository at:
git://repo.or.cz/qemu/kevin.git for-anthony
Christoph Hellwig (1):
block: allow filenames with colons again for
From: Christoph Hellwig h...@lst.de
Before the raw/file split we used to allow filenames with colons for host
device only. While this was more by accident than by design people rely
on it, so we need to bring it back.
So move the host device probing to be before the protocol detection
again.
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
blockdev.c | 12
blockdev.h |1 -
2 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index
From: Markus Armbruster arm...@redhat.com
None of its callers checks for failure. scsi_hot_add() can crash
because of that:
(qemu) drive_add 4 if=scsi,format=host_device,file=/dev/sg1
scsi-generic: scsi generic interface too old
Segmentation fault (core dumped)
Fix all callers, not just
From: Ryan Harper ry...@us.ibm.com
To fix https://bugs.launchpad.net/qemu/+bug/597402 where qemu fails to
call unlink() on temporary snapshots due to bs-is_temporary getting clobbered
in bdrv_open_common() after being set in bdrv_open() which calls the former.
We don't need to initialize
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
hw/ide.h | 11 ++-
hw/ide/isa.c |8
hw/ide/piix.c |6 --
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git
From: Markus Armbruster arm...@redhat.com
For instance, -device scsi-disk,drive=foo -device scsi-disk,drive=foo
happily creates two SCSI disks connected to the same block device.
It's all downhill from there.
Device usb-storage deliberately attaches twice to the same blockdev,
which fails with
From: Markus Armbruster arm...@redhat.com
Drives defined with -drive if=ide get get created along with the IDE
controller, inside machine-init(). That's before cmos_init().
Drives defined with -device get created during generic device init.
That's after cmos_init(). Because of that, CMOS has no
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.
*
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
---
block.c | 35 +--
1 files changed,
From: MORITA Kazutaka morita.kazut...@lab.ntt.co.jp
This patch removes exit(1) from error(), and properly releases
resources such as a block driver and an allocated memory.
For testing the Sheepdog block driver with qemu-iotests, it is
necessary to call bdrv_delete() before the program exits.
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/block.c b/block.c
index feda755..003d132 100644
--- a/block.c
+++
From: Markus Armbruster arm...@redhat.com
savevm.c keeps a pointer to the snapshot block device. If you manage
to get that device deleted, the pointer dangles, and the next snapshot
operation will crash burn. Unplugging a guest device that uses it
does the trick:
$ MALLOC_PERTURB_=234
state = 0 in rules means that the rule is valid for any state. Therefore it's
impossible to have a rule that works only in the initial state. This changes
the initial state from 0 to 1 to make this possible.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/blkdebug.c |3 +++
1 files
From: Markus Armbruster arm...@redhat.com
Make the property point to BlockDriverState, cutting out the DriveInfo
middleman. This prepares the ground for block devices that don't have
a DriveInfo.
Currently all user-defined ones have a DriveInfo, because the only way
to define one is -drive
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
blockdev.c | 12
blockdev.h |1 +
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/blockdev.c b/blockdev.c
index
From: Markus Armbruster arm...@redhat.com
We automatically delete blockdev host parts on unplug of the guest
device. Too much magic, but we can't change that now.
The delete happens early in the guest device teardown, before the
connection to the host part is severed. Thus, the guest part's
From: Markus Armbruster arm...@redhat.com
Unused since commit 6ced55a5.
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
blockdev.c | 12
blockdev.h |1 -
2 files changed, 0 insertions(+), 13 deletions(-)
diff --git
From: Markus Armbruster arm...@redhat.com
BlockDriverState member removable controls whether virtual media
change (monitor commands change, eject) is allowed. It is set when
the type hint is BDRV_TYPE_CDROM or BDRV_TYPE_FLOPPY.
The type hint is only set by drive_init(). It sets
On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
That's true, but it's fair to be concerned about the guest itself.
Imagine it runs some possibly malicious apps which program the hardware
to do DMA. That should be safe when a IOMMU is present.
But suddenly the guest OS
From: Markus Armbruster arm...@redhat.com
All callers of ide_create_drive() ignore its value. Currently
harmless, because it fails only when qdev_init() fails, which fails
only when ide_drive_initfn() fails, which never fails.
Brittle. Change it to die instead of silently ignoring failure.
We currently need this either to allocate the next ram_addr_t for a
new block, or for total memory to be migrated. Both of which we can
calculate without need of this to keep us in a contiguous address space.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch_init.c | 23
Stuff a pointer to the DeviceState into the VirtIONet structure so that
we can easily remove the vmstate entry later. Also, let vmstate track
the instance number (it should always be zero internally since the
device path should now be unique).
Signed-off-by: Alex Williamson
With these two pieces in place, we can start naming ramblocks. When
the device is present and it lives on a bus that provides a device
path, we concatenate the path and the provided name. Otherwise we
just use name. The resulting id string must be unique. For now we
assume an allocation for
Forgetting to free them means that the next instance inherits all rules and
gets its own rules only additionally.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/blkdebug.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/block/blkdebug.c b/block/blkdebug.c
index
This works great for PCI since a segment:bus:dev.fn uniquely
describes a global address. No need to traverse up the qdev tree.
PCI segment support is a placeholder for compatibility once we
support multiple segments.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/pci.c | 14
From: Markus Armbruster arm...@redhat.com
Signed-off-by: Markus Armbruster arm...@redhat.com
Signed-off-by: Kevin Wolf kw...@redhat.com
---
qemu-option.c |9 +
qemu-option.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index
This function is meant to provide a stable device path for buses
which are able to implement it. If a bus has a globally unique
addresses scheme, one address level may be sufficient to provide
a path. Other buses may need to recursively traverse up the
qdev tree.
Signed-off-by: Alex Williamson
v3:
Still looking for comments...
changes:
- Rebase to latest upstream to pickup a few more callers
- Fix a bug in patch introducing qemu_ram_free(). Since we now
try to place blocks into existing holes in the address space,
the end of the current block isn't necessarily the top
The list head was initialized to point to the wrong list, so all actions ended
up being handled as inject-error even if they were set-state in fact.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block/blkdebug.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
Allows us to compress the protocol a bit by setting a flag on the
offset which indicates we're still working within the same block
as last time. That way we can avoid sending the block name for
every page. Suggested by Anthony Liguori.
Signed-off-by: Alex Williamson alex.william...@redhat.com
These will be used to generate unique id strings for ramblocks. The name
field is required, the device pointer is optional as most callers don't
have a device. When there's no device or the device isn't a child of
a bus implementing BusInfo.get_dev_path, the name should be unique for
the
This will benefit us when we migrate based on ramblock name since
we won't be bouncing between separate blocks.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/pc.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/hw/pc.c b/hw/pc.c
For callers that pass a device we can traverse up the qdev tree and
make use of the BusInfo.get_dev_path information for creating unique
savevm id strings. This avoids needing to rely on the instance number,
which can cause problems with device initialization order and hotplug.
For
People think that their images are corrupted when in fact there are just some
leaked clusters. Differentiating several error cases should make the messages
more comprehensible.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c| 10 ++--
block.h| 10 -
qemu-img.c |
Synchronize RAM blocks with the target and migrate using name/offset
pairs. This ensures both source and target have the same view of
RAM and that we get the right bits into the right slot.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch_init.c | 118
This allows us to create a more meaningful savevm string.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/eepro100.c |4 ++--
hw/eeprom93xx.c |8
hw/eeprom93xx.h |4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/eepro100.c
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
hw/pci.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index fe7c5c3..a7ff566 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -76,6 +76,7 @@ static struct BusInfo pci_bus_info = {
On Fri, Jul 02, 2010 at 06:41:55PM +0900, Isaku Yamahata wrote:
On Fri, Jul 02, 2010 at 09:03:39AM +0100, Stefan Hajnoczi wrote:
On Thu, Jul 1, 2010 at 8:30 PM, Eduard - Gabriel Munteanu
eduard.munte...@linux360.ro wrote:
But suddenly the guest OS changes mappings and expects the IOMMU to
We don't want to assume a contiguous address space, so migrate based
on RAM blocks instead of a fixed linear address map. This will allow
us to have holes in the ram_addr_t namespace, so we can implement
qemu_ram_free().
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch_init.c
Now that we can support a ram_addr_t space with holes, we can implement
qemu_ram_free().
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
cpu-all.h |3 +++
exec.c| 62 +
2 files changed, 61 insertions(+), 4
This distinguishes between harmless leaks and real corruption. Hopefully users
better understand what qemu-img check wants to tell them.
Signed-off-by: Kevin Wolf kw...@redhat.com
---
block.c|3 +-
block/qcow2-refcount.c | 120 ++--
Now that we have a working qemu_ram_free() and the primary runtime
user of it has been updated, don't be lenient about duplicate id strings.
We also shouldn't need to create them ondemand at the target.
Signed-off-by: Alex Williamson alex.william...@redhat.com
---
arch_init.c |5 +++--
qemu-img check produces messages that are hard to understand. Even worse is
that in the end it just says something like 42 errors with no further
explanation. Recently I got bug reports from people who though that their image
was corrupted, when in fact there were only a few leaked clusters after
On Tue, Jun 15, 2010 at 2:23 PM, Cam Macdonell c...@cs.ualberta.ca wrote:
Latest patch for PCI shared memory device that maps a host shared memory
object
to be shared between guests
new in this series
- replace marking memory from v6 with marking device as unmigratable
indicating
You wrote 1 июля 2010 г., 19:43:06:
On Thu, 1 Jul 2010, Richard Henderson wrote:
On 07/01/2010 05:04 AM, Vic3Dexe wrote:
Public bug reported:
xchg r8,rax (49h 90h) executed as nop (90h) in long mode, in other words
REX not used.
qemu 0.12.4, host Win 7 x64, running
On Thursday 01 July 2010 16:50:29 Paul Brook wrote:
Here is the patch again. There may be more work to be done on top of
this, but this patch staying out of tree hasn't noticeably accelerated
that work in the past year and change. Could it please be merged?
As mentioned previously, V5
On 07/02/2010 12:13 PM, vic3d...@gmail.com wrote:
Sorry for inconvenience, I just forgot to look in source. :)
Do you plan to fix it in the near future?
No, in the near past. ;-)
The fix was committed to qemu.git head yesterday.
r~
---
qemu-monitor.hx | 68 +++
1 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 9f62b94..5348899 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -2490,6 +2490,74 @@ STEXI
show device
This series introduces the documentation for the query-qdm command and the
conversion of the monitor command 'info qdm' to QMP.
The documentation and code are based on a patch previously sent to qemu-devel
by Daniel P. Berrange:
http://lists.gnu.org/archive/html/qemu-devel/2010-06/msg00931.html
Converts the 'info qdm' command to QMP, allowing the discovery of all devices
known to the QEMU binary without relying on command line paramaters like
-device ? and -device devtype,?
This change does not modify the output of the 'info qdm' monitor command.
Signed-off-by: Miguel Di Ciurcio Filho
On Thu, Jul 01, 2010 at 01:25:51PM -0300, Lucas Meneghel Rodrigues wrote:
Now that we already have a mechanism to perform automated and regular
unittesting, let me start by reporting the first problems I'm seeing
with the unittests. Some (or all) of the problems might be due to
inappropriate
Long time no post, i tried to install Win2k3 through RIS/PXE this time.
I still get the same error at boot time: A disk read error occurred.
Press Ctrl + Alt + Del to restart.
Neither the Win2k3 install source nor the VirtIO drivers are defective.
Something's just wrong with QEMU.
Currently
@Jes:
No, it doesn't boot on its own, it's a simple FAT formatted floppy
image. I've even tried to format a real floppy on Windows, copied the
drivers on it, and saved the whole floppy as an image with rawrite. I
also tried other floppy images, but:
QEMU 0.12.4 hangs if I try to boot from the
83 matches
Mail list logo
