[Qemu-devel] Latest git doesn't compile
./configure --enable-linux-aio --enable-io-thread --enable-kvm make clean ... gcc: block/blkdebug.o: No such file or directory -Nigel
[Qemu-devel] --mem-path option broken on qemu-kvm latest git
Hi folks, on during the latest upstream test job I noticed that the -mem-path option got broken on latest qemu-kvm. qemu abnormally ends with exit code 1 when trying to call it with -mem-path 04/29 18:35:32 DEBUG|kvm_vm:0461| Running qemu command: /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor unix:/tmp/monitor-20100429-181844-a21K,server,nowait -drive file=/tmp/kvm_autotest_root/images/rhel5-64.qcow2,if=ide -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:56 -net user,vlan=0 -m 1024 -smp 2 -drive file=/tmp/kvm_autotest_root/isos/linux/RHEL-5.5-x86_64-DVD.iso,index=2,media=cdrom -fda /usr/local/autotest/tests/kvm/images/rhel55-64/floppy.img -tftp /usr/local/autotest/tests/kvm/images/rhel55-64/tftpboot -boot d -bootp /pxelinux.0 -boot n -mem-path /mnt/kvm_hugepage -redir tcp:5000::22 -redir tcp:5001::12323 -vnc :0 04/29 18:35:33 DEBUG|kvm_subpro:0686| (qemu) (Process terminated with status 1) Exact version of qemu.git tested: 04/29 14:18:17 INFO | kvm_utils:0424| Commit hash for git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is a1b705841caa33fca0b95928505c01d5105b706f (tag kvm-88-4245-ga1b7058) Please let me know if there's any additional info you might want. Lucas
[Qemu-devel] [PATCH] QEMU-KVM scsi-bus: Add LBA+Transfer Length to outgoing SBC CDBs in scsi_req_setup() for SG_IO
Greetings Hannes, Gerd and co,
So after doing more digging into the work for a SGL capable QEMU SCSI
HBA emulation interface with the megasas driver on Linux/KVM Hosts, I
realized that the SG_IO breakage we originally encountered is due to the
fact that CDBs containing SBC LBA+block_count where not getting built in
the new HBA I/O helper in hw/scsi-bus.c:scsi_req_setup().
This is AFAICT because hw/scsi-disk.c logic is doing it's underlying
userspace AIO to struct file without any knowledge of SBC CDBs to begin
with. (Please correct me if I am wrong) With the following patch on top
of my working qemu-kvm.git tree containing Gerd's SCSI bus interface, I
am now able to run bulk SG_IO with megasas emulation in a v2.6.26-2
x86_64 KVM Guest on a 2.6.34-rc4 x86_64 Host with TCM_Loop virtual SAS
ports!
Also the original lack of a valid req->cmd.len assignment in
scsi_req_setup() is what was causing the original 'Message too long'
SG_IO failures I encountered.. Here is the combined patch to make go:
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 48e8d40..b8e4b71 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -453,7 +453,39 @@ int scsi_req_parse(SCSIRequest *req, uint8_t *buf)
int scsi_req_setup(SCSIRequest *req, int is_write, uint64_t lba, uint64_t
count)
{
-req->cmd.buf[0] = is_write ? WRITE_12 : READ_12;
+/*
+ * Set the req->cmd.len and fill in the CDB's Logical Block Address and
+ * Transfer length (block count) that is required by SG_IO passthrough
+ * in hw/scsi-generic.c:execute_command_run()
+ */
+if (lba > 0x) {
+ req->cmd.len = 16;
+ req->cmd.buf[0] = is_write ? WRITE_16 : READ_16;
+ req->cmd.buf[2] = (lba >> 56) & 0xff;
+ req->cmd.buf[3] = (lba >> 48) & 0xff;
+ req->cmd.buf[4] = (lba >> 40) & 0xff;
+ req->cmd.buf[5] = (lba >> 32) & 0xff;
+ req->cmd.buf[6] = (lba >> 24) & 0xff;
+ req->cmd.buf[7] = (lba >> 16) & 0xff;
+ req->cmd.buf[8] = (lba >> 8) & 0xff;
+ req->cmd.buf[9] = lba & 0xff;
+ req->cmd.buf[10] = (count >> 24) & 0xff;
+ req->cmd.buf[11] = (count >> 16) & 0xff;
+ req->cmd.buf[12] = (count >> 8) & 0xff;
+ req->cmd.buf[13] = count & 0xff;
+} else {
+ req->cmd.len = 12;
+ req->cmd.buf[0] = is_write ? WRITE_12 : READ_12;
+ req->cmd.buf[2] = (lba >> 24) & 0xff;
+ req->cmd.buf[3] = (lba >> 16) & 0xff;
+ req->cmd.buf[4] = (lba >> 8) & 0xff;
+ req->cmd.buf[5] = lba & 0xff;
+ req->cmd.buf[6] = (count >> 24) & 0xff;
+ req->cmd.buf[7] = (count >> 16) & 0xff;
+ req->cmd.buf[8] = (count >> 8) & 0xff;
+ req->cmd.buf[9] = count & 0xff;
+}
+
req->cmd.mode = is_write ? SCSI_XFER_TO_DEV : SCSI_XFER_FROM_DEV;
req->cmd.lba = lba;
req->cmd.xfer = count * req->dev->blocksize;
and the the link containing the commit proper:
http://git.kernel.org/?p=virt/kvm/nab/qemu-kvm.git;a=commitdiff;h=6a1a11bfbcde49bb864fe40cf3b254b1ed607c72
So far using the LTP-Disktest O_DIRECT benchmark with 8 threads and 64k
blocksize in a guest with 4 VCPUs and 2048MB memory to a SG_IO <->
TCM/RAMDISK_DR backstore running on a KVM 5500 series Nehalem host, I am
seeing ~8.9 Gb/sec (~1050 MB/sec) of bandwith to megasas with the large
blocksizes. Seperately I am able to mkfs and mount filesystems from
within KVM guest, shutdown and then mount locally with TCM_Loop on the
host, etc.
Here is how it looks in action so far:
http://linux-iscsi.org/images/Megasas-SGIO-TCM_Loop-05012010.png
In order to achieve these results I am running with the recommended
MEGASAS_MAX_FRAMES=1000, and two extra kernel patches for seting
include/scsi/sg.h:SG_MAX_QUEUE=128 and increasing TCM_Loop's SCSI LLD
settings for struct scsi_host_template to can_queue=1024,
cmd_per_lun=1024, and max_sectors=256.
diff --git a/include/scsi/sg.h b/include/scsi/sg.h
index a9f3c6f..5decefd 100644
--- a/include/scsi/sg.h
+++ b/include/scsi/sg.h
@@ -240,7 +240,7 @@ typedef struct sg_req_info { /* used by
SG_GET_REQUEST_TABLE ioctl() */
#define SG_DEF_RESERVED_SIZE SG_SCATTER_SZ /* load time option */
/* maximum outstanding requests, write() yields EDOM if exceeded */
-#define SG_MAX_QUEUE 16
+#define SG_MAX_QUEUE 128
#define SG_BIG_BUFF SG_DEF_RESERVED_SIZE/* for backward compatibility */
diff --git a/drivers/target/tcm_loop/tcm_loop_fabric_scsi.c
b/drivers/target/tcm_loop/tcm_loop_fabric_scsi.c
index 5417579..4d4c573 100644
--- a/drivers/target/tcm_loop/tcm_loop_fabric_scsi.c
+++ b/drivers/target/tcm_loop/tcm_loop_fabric_scsi.c
@@ -391,11 +391,11 @@ static struct scsi_host_template tcm_loop_driver_template
= {
.eh_device_reset_handler = NULL,
.eh_host_reset_handler = NULL,
.bios_param = NULL,
- .can_queue = 1,
+ .can_queue = 1024,
.this_id= -1,
.sg_tablesize = 256,
- .cmd_per_lun= 1,
- .max_sectors
[Qemu-devel] Re: --mem-path option broken on qemu-kvm latest git
On Sat, May 01, 2010 at 10:50:56AM -0300, Lucas Meneghel Rodrigues wrote:
> Hi folks, on during the latest upstream test job I noticed that the
> -mem-path option got broken on latest qemu-kvm. qemu abnormally ends
> with exit code 1 when trying to call it with -mem-path
>
> 04/29 18:35:32 DEBUG|kvm_vm:0461| Running qemu command:
> /usr/local/autotest/tests/kvm/qemu -name 'vm1' -monitor
> unix:/tmp/monitor-20100429-181844-a21K,server,nowait -drive
> file=/tmp/kvm_autotest_root/images/rhel5-64.qcow2,if=ide -net
> nic,vlan=0,model=rtl8139,macaddr=52:54:00:12:34:56 -net user,vlan=0 -m 1024
> -smp 2 -drive
> file=/tmp/kvm_autotest_root/isos/linux/RHEL-5.5-x86_64-DVD.iso,index=2,media=cdrom
> -fda /usr/local/autotest/tests/kvm/images/rhel55-64/floppy.img -tftp
> /usr/local/autotest/tests/kvm/images/rhel55-64/tftpboot -boot d -bootp
> /pxelinux.0 -boot n -mem-path /mnt/kvm_hugepage -redir tcp:5000::22 -redir
> tcp:5001::12323 -vnc :0
> 04/29 18:35:33 DEBUG|kvm_subpro:0686| (qemu) (Process terminated with status
> 1)
>
> Exact version of qemu.git tested:
>
> 04/29 14:18:17 INFO | kvm_utils:0424| Commit hash for
> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git is
> a1b705841caa33fca0b95928505c01d5105b706f (tag kvm-88-4245-ga1b7058)
>
> Please let me know if there's any additional info you might want.
I experienced the same in my nested-npt huge page tests. What helped was
to remove the lines:
if (memory < hpagesize) {
return NULL;
}
from file_ram_alloc() in exec.c. The problem is probably that qemu-kvm now
allocs the memory per-slot and not entirely anymore. But thats just a guess.
Joerg
Re: [Qemu-devel] Latest git doesn't compile
On 05/01/2010 09:39 AM, Lucas Meneghel Rodrigues wrote: On Sat, 2010-05-01 at 09:29 -0400, Nigel Horne wrote: ./configure --enable-linux-aio --enable-io-thread --enable-kvm make clean ... gcc: block/blkdebug.o: No such file or directory -Nigel A test job ran hours ago, and qemu.git compiled just fine here (check compile logs attached). Could you provide more info on what you do typically when compiling your tree? Have you tried with a clean git clone? What further information would you like, when you ask for "more info"? -Nigel
[Qemu-devel] [PATCH] pflash_cfi01: add device ID read command
Add support to read manufacturer and device ID. For everything else (eg.
lock bits) 0 is returned.
Signed-off-by: Michael Walle
---
hw/pflash_cfi01.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/hw/pflash_cfi01.c b/hw/pflash_cfi01.c
index 6b2adba..bc901e6 100644
--- a/hw/pflash_cfi01.c
+++ b/hw/pflash_cfi01.c
@@ -166,6 +166,22 @@ static uint32_t pflash_read (pflash_t *pfl,
target_phys_addr_t offset,
ret = pfl->status;
DPRINTF("%s: status %x\n", __func__, ret);
break;
+case 0x90:
+switch (boff) {
+case 0:
+ret = pfl->ident[0] << 8 | pfl->ident[1];
+DPRINTF("%s: Manufacturer Code %04x\n", __func__, ret);
+break;
+case 1:
+ret = pfl->ident[2] << 8 | pfl->ident[3];
+DPRINTF("%s: Device ID Code %04x\n", __func__, ret);
+break;
+default:
+DPRINTF("%s: Read Device Information boff=%x\n", __func__, boff);
+ret = 0;
+break;
+}
+break;
case 0x98: /* Query mode */
if (boff > pfl->cfi_len)
ret = 0;
@@ -283,6 +299,10 @@ static void pflash_write(pflash_t *pfl, target_phys_addr_t
offset,
DPRINTF("%s: Read status register\n", __func__);
pfl->cmd = cmd;
return;
+case 0x90: /* Read Device ID */
+DPRINTF("%s: Read Device information\n", __func__);
+pfl->cmd = cmd;
+return;
case 0x98: /* CFI query */
DPRINTF("%s: CFI query\n", __func__);
break;
--
1.5.6.5
Re: [Qemu-devel] [PATCH 0/2] cmd646: amend bmdma issue fix
Thanks, applied. On 4/23/10, Igor V. Kovalenko wrote: > Hi! > > The following series are not picked from mailing list, so this is a resend. > > Short history is that original fix for cmd646 bmdma issue was done by > reverting pci_dev removal from driver. That was a quick workaround > and later Juan was kind enough to improve driver code. > > Patches on the list: > - http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01421.html > - http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01439.html > > --- > > Igor V. Kovalenko (2): > cmd646: pass pci_dev as it needs it > cmd646: fix abort due to changed opaque pointer for ioport read > > > hw/ide/cmd646.c | 66 > +++-- > hw/ide/internal.h |1 - > hw/ide/piix.c |1 - > 3 files changed, 48 insertions(+), 20 deletions(-) > > -- > Kind regards, > > Igor V. Kovalenko > > >
Re: [Qemu-devel] [PATCH] Clean up definition of MAX_OPC_PARAM
Thanks, applied. On 4/28/10, Stuart Brady wrote: > MAX_OPC_PARAM is intended to refer to the maximum number of entries used > in gen_opparam_buf[] for any single helper call. It is currently defined > as 10, but for 32-bit archs, the correct value (with a maximum for four > helper arguments) is 14, and for 64-bit archs, only 9 entries are needed. > > tcg_gen_callN() fills four entries with the function address, flags, > number of args, etc. and on 32-bit archs uses a further two entries per > argument (with a maximum of four helper arguments), plus two more for the > return value. On 64-bit archs, only half as many entries are used for the > args and the return value. > > In reality, TBs tend not to consist purely of helper calls exceeding the > stated 10 gen_opparam_buf[] entries, so this would never actually be a > problem on 32-bit archs, but the definition is still rather confusing. > > Signed-off-by: Stuart Brady > --- > diff --git a/exec-all.h b/exec-all.h > index 4bae1e2..1016de2 100644 > --- a/exec-all.h > +++ b/exec-all.h > @@ -44,8 +44,20 @@ typedef struct TranslationBlock TranslationBlock; > > /* XXX: make safe guess about sizes */ > #define MAX_OP_PER_INSTR 96 > -/* A Call op needs up to 6 + 2N parameters (N = number of arguments). */ > -#define MAX_OPC_PARAM 10 > + > +#if HOST_LONG_BITS == 32 > +#define MAX_OPC_PARAM_PER_ARG 2 > +#else > +#define MAX_OPC_PARAM_PER_ARG 1 > +#endif > +#define MAX_OPC_PARAM_IARGS 4 > +#define MAX_OPC_PARAM_OARGS 1 > +#define MAX_OPC_PARAM_ARGS (MAX_OPC_PARAM_IARGS + MAX_OPC_PARAM_OARGS) > + > +/* A Call op needs up to 4 + 2N parameters on 32-bit archs, > + * and up to 4 + N parameters on 64-bit archs > + * (N = number of input arguments + output arguments). */ > +#define MAX_OPC_PARAM (4 + (MAX_OPC_PARAM_PER_ARG * MAX_OPC_PARAM_ARGS)) > #define OPC_BUF_SIZE 640 > #define OPC_MAX_SIZE (OPC_BUF_SIZE - MAX_OP_PER_INSTR) > > > >
Re: [Qemu-devel] [PATCH] fix old typos in help header
Thanks, applied.
On 4/28/10, Thomas Monjalon wrote:
> From: Thomas Monjalon
>
> 1) Qemu is not only a PC emulator.
> 2) "image image" has already been changed to "disk image" in qemu-doc.texi
>
> Signed-off-by: Thomas Monjalon
> ---
> vl.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index a485c58..5e03b72 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2001,7 +2001,7 @@ static void main_loop(void)
>
> static void version(void)
> {
> -printf("QEMU PC emulator version " QEMU_VERSION QEMU_PKGVERSION ",
> Copyright (c) 2003-2008 Fabrice Bellard\n");
> +printf("QEMU emulator version " QEMU_VERSION QEMU_PKGVERSION ",
> Copyright (c) 2003-2008 Fabrice Bellard\n");
> }
>
> static void help(int exitcode)
> @@ -2018,7 +2018,7 @@ static void help(int exitcode)
> version();
> printf("usage: %s [options] [disk_image]\n"
> "\n"
> - "'disk_image' is a raw hard image image for IDE hard disk 0\n"
> + "'disk_image' is a raw hard disk image for IDE hard disk 0\n"
> "\n"
> "%s\n"
> "During emulation, the following keys are useful:\n"
>
> --
> 1.7.1
>
>
>
>
>
>
[Qemu-devel] [PATCH] Fix qemu mouse Set_Protocol behavior
The QEMU USB mouse claims to support the "boot" protocol (bInterfaceSubClass is 1). However, the mouse rejects the Set_Protocol command. The qemu mouse does support the "boot" protocol specification, so a simple fix is to just enable the Set_Portocol request. -Kevin --- a/hw/usb-hid.c +++ b/hw/usb-hid.c @@ -790,13 +790,13 @@ static int usb_hid_handle_control(USBDevice *dev, int request, int value, goto fail; break; case GET_PROTOCOL: -if (s->kind != USB_KEYBOARD) +if (s->kind != USB_KEYBOARD && s->kind != USB_MOUSE) goto fail; ret = 1; data[0] = s->protocol; break; case SET_PROTOCOL: -if (s->kind != USB_KEYBOARD) +if (s->kind != USB_KEYBOARD && s->kind != USB_MOUSE) goto fail; ret = 0; s->protocol = value;
[Qemu-devel] Re: Regression in vga performance between 0.11.1 and 0.12.1.1
On 05/01/2010 10:17 PM, Adam Greenblatt wrote: Avi, Sure -- you can download a tarball of kvm_stat logfiles from: Please don't top-post. http://misc.cyclecounters.org/qemu-logs.tgz I ran three workloads (a short, medium, and long) against both 0.11.1 and 0.12.3. Each workload was started with: time ~/qemu-0.12.3/bin/qemu-system-x86_64 -m 1536 -soundhw es1370 -smp 4 -usb -usbdevice tablet -vga std -cpu core2duo -snapshot -name "VKoala (r/o)",process="VKoala" -net nic,macaddr=DE:AD:BE:EF:00:08 -net tap,vlan=0,ifname=tap6,script=no,downscript=no /vm/ubuntu-9.10/0008.img (or ~/qemu-0.11.1/bin/... and the same options.) For the "short" workload, I just shut down the Ubuntu guest immediately after it finishes logging me in. For the "medium" workload, I open up an 80x43 terminal window in the guest, and execute: yes 1234567890123456789012345678901234567890 | head -n 1 before shutting down the guest. For the "long" workload, I open up the same terminal window and execute: yes 1234567890123456789012345678901234567890 | head -n 10 before shutting down the guest. When running these workloads under 0.12.3, you can watch the screen redraw; it takes 1 or 2 seconds just to put up the desktop background after the splash screen. Top shows the `VKoala' process as pegging one or more cpus, while the host's X server is essentially idle (< 5% of a cpu). When running these workloads under 0.11.1, the screen redraw is too fast to notice -- it appears to just "blink" up instantly. Top shows the `VKoala' process as pegging one or more cpus during boot. When the terminal is busy, top shows `VKoala' and the host's X server both using ~60% of a cpu -- so the guest is probably being somewhat limited by the host's wimpy graphics. Anthony, can this be due to the SDL changes doing bitblt using X? Looks like this regresses not only for remote displays, but also for local ones. Hope this is the info you needed. Thanks for your help! Aloha, Adam Avi Kivity wrote: On 04/28/2010 10:33 PM, Adam Greenblatt wrote: Hi, I noticed that certain guests (for example, Ubuntu 9.04, Ubuntu 9.10, and the Ubuntu 10.04 release candidate) show dramatically (~100x) slower graphical output when running under qemu-kvm-0.12.1.1 than under qemu-kvm-0.11.1. Other guests, notably Windows XP and Windows Vista, run fine under both version of qemu. The regression is still present in qemu-kvm-0.12.3. Please post kvm_stat output for the fast and slow cases (preferably running the same workload, perhaps a web page displaying an animation). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
