Re: [ANNOUNCE] kvm-75 release
Avi Kivity wrote: > Jim Paris wrote: >> Avi Kivity wrote: >> >>> - restore option roms to their original content on reset >>> - fixes extboot failures after reset >> >> It doesn't seem to work here: > > grub is probably booting via int 19 or jumping to the reset vector, so > kvm doesn't see the reboot. You're right: ENTRY(grub_reboot) callEXT_C(prot_to_real) .code16 /* cold boot */ movw$0x0472, %di movw%ax, (%di) ljmp$0x, $0x > If that's the case, we can either implement > the chipset's memory control registers properly and teach the bios to > program them, or add a hack in the bios to trigger the copying without > the full reset. My testing was a bit flawed. With kvm-74, I noticed that reboot from Linux had the problem, and reboot from grub failed the same way. With kvm-75, I only tested reboot from grub. I can verify that reboot from Linux works fine with virtio and kvm-75, and so the current behavior is actually fine for us. Thanks, -jim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: Support for removing device by host addr, improved auto filter syntax
Max Krasnyansky wrote: This patch adds support for removing USB devices by host address. Which is usefull for things like libvirtd because there is no easy way to find guest USB address of the host device. In other words you can now do: usb_add host:3.5 ... usb_del host:3.5 Before the patch 'usb_del' did not support 'host:' notation. Applied. Thanks. BTW, I was able to program my harmony remote with QEMU after your last patch series. This brought me great joy as I do not currently have access to a physical Windows system :-) Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] husb: Make control transactions asynchronous (v2)
Max Krasnyansky wrote: USB is 99.8% async now :). 0.2% is the three control requests that we need to execute synchronously. We could off-load that to a thread or something but it's not worth the pain since those requests are performed only during device initialization (ie when device is connected to the VM). The change is a bit bigger than I wanted due to the fact that generic handle_packet()/handle_control() interface was not designed for async transactions. So I ended up adding custom handle_packet() code to usb-linux. We can make that generic if/when some other component needs it. Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]> Applied. Thanks. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network Overruns
(re-adding list) xming wrote: What NIC model are you using in the guest? I have tried 8319, e1000 and virtio both had stalls. I am using virtio with txqueuelen 1500 on the tap. I didin't had this proble with kvm 69, 70. What is the oldest version that doesn't work? (i.e. when was the regression introduced?) -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] kvm-75 release
Jim Paris wrote: Avi Kivity wrote: - restore option roms to their original content on reset - fixes extboot failures after reset It doesn't seem to work here: $ dmesg | grep kvm | tail -1 [1649282.904413] loaded kvm module (kvm-75) $ sudo kvm | head -1 QEMU PC emulator version 0.9.1 (kvm-75), Copyright (c) 2003-2008 Fabrice Bellard $ sudo /usr/bin/kvm -M pc -m 512 -smp 1 -name svn -boot c -drive file=/dev/mapper/raid1-svn,if=virtio,index=0,boot=on At GRUB, I hit "c" for a command prompt, then type "reboot". grub is probably booting via int 19 or jumping to the reset vector, so kvm doesn't see the reboot. If that's the case, we can either implement the chipset's memory control registers properly and teach the bios to program them, or add a hack in the bios to trigger the copying without the full reset. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] KVM: Device Assignment with VT-d
Han, Weidong wrote: This patch only can work on x86, it breaks build on other architectures. It is caused by kvm_irq_ack_notifier and kvm_assigned_dev_kernel are defined under x86, while they are always used in include/linux/kvm_host.h whether CONFIG_DMAR is set or not. I move these two definitions to include/linux/kvm_host.h, and attached the updated patch. Thanks. I replaced the old patch with your new version. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VT-d support for device assignment
Amit Shah wrote: Sorry for the resends; this one fixes two compile errors introduced by me and a warning. Applied both, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Device Assignment: Free device structures if IRQ allocation fails
Amit Shah wrote: When an IRQ allocation fails, we free up the device structures and disable the device so that we can unregister the device in the userspace and not expose it to the guest at all. Doesn't apply. Can you refresh please? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: Support for removing device by host addr, improved auto filter syntax
This patch adds support for removing USB devices by host address.
Which is usefull for things like libvirtd because there is no easy way to
find guest USB address of the host device.
In other words you can now do:
usb_add host:3.5
...
usb_del host:3.5
Before the patch 'usb_del' did not support 'host:' notation.
Syntax for specifying auto connect filters has been improved.
Old syntax was
host:bus.dev
host:pid:vid
New syntax is
host:auto:bus.dev[:pid:vid]
In both the cases any attribute can be set to "*".
New syntax is more flexible and lets you do things like
host:3.*:5533:* /* grab any device on bus 3 with vendor id 5533 */
It's now possible to remove auto filters. For example:
usb_del host:auto:3.*:5533:*
Active filters are printed after all host devices in 'info usb' output.
Which now looks like this:
Device 1.1, speed 480 Mb/s
Hub: USB device 1d6b:0002, EHCI Host Controller
Device 1.4, speed 480 Mb/s
Class 00: USB device 1058:0704, External HDD
Auto filters:
Device 3.* ID *:*
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
hw/usb.h|1 +
usb-linux.c | 203 ++-
vl.c|3 +
3 files changed, 176 insertions(+), 31 deletions(-)
diff --git a/hw/usb.h b/hw/usb.h
index 997e69f..1a353bb 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -240,6 +240,7 @@ USBDevice *usb_hub_init(int nb_ports);
/* usb-linux.c */
USBDevice *usb_host_device_open(const char *devname);
+int usb_host_device_close(const char *devname);
void usb_host_info(void);
/* usb-hid.c */
diff --git a/usb-linux.c b/usb-linux.c
index b82c4f6..937ff12 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -5,7 +5,7 @@
*
* Copyright (c) 2008 Max Krasnyansky
* Support for host device auto connect & disconnect
- * Magor rewrite to support fully async operation
+ * Major rewrite to support fully async operation
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
deal
@@ -951,23 +951,52 @@ fail:
return NULL;
}
+static int usb_host_auto_add(const char *spec);
+static int usb_host_auto_del(const char *spec);
+
USBDevice *usb_host_device_open(const char *devname)
{
int bus_num, addr;
char product_name[PRODUCT_NAME_SZ];
-if (usb_host_find_device(&bus_num, &addr,
- product_name, sizeof(product_name),
- devname) < 0)
+if (strstr(devname, "auto:")) {
+usb_host_auto_add(devname);
return NULL;
+}
- if (hostdev_find(bus_num, addr)) {
-term_printf("husb: host usb device %d.%d is already open\n", bus_num,
addr);
+if (usb_host_find_device(&bus_num, &addr, product_name,
sizeof(product_name),
+ devname) < 0)
return NULL;
- }
+
+if (hostdev_find(bus_num, addr)) {
+ term_printf("husb: host usb device %d.%d is already open\n", bus_num,
addr);
+ return NULL;
+}
return usb_host_device_open_addr(bus_num, addr, product_name);
}
+
+int usb_host_device_close(const char *devname)
+{
+char product_name[PRODUCT_NAME_SZ];
+int bus_num, addr;
+USBHostDevice *s;
+
+if (strstr(devname, "auto:"))
+return usb_host_auto_del(devname);
+
+if (usb_host_find_device(&bus_num, &addr, product_name,
sizeof(product_name),
+ devname) < 0)
+return -1;
+
+s = hostdev_find(bus_num, addr);
+if (s) {
+usb_device_del_addr(0, s->dev.addr);
+return 0;
+}
+
+return -1;
+}
static int get_tag_value(char *buf, int buf_size,
const char *str, const char *tag,
@@ -1126,21 +1155,76 @@ static void usb_host_auto_timer(void *unused)
}
/*
- * Add autoconnect filter
- * -1 means 'any' (device, vendor, etc)
+ * Autoconnect filter
+ * Format:
+ *auto:bus:dev[:vid:pid]
+ *auto:bus.dev[:vid:pid]
+ *
+ *bus - bus number(dec, * means any)
+ *dev - device number (dec, * means any)
+ *vid - vendor id (hex, * means any)
+ *pid - product id(hex, * means any)
+ *
+ *See 'lsusb' output.
*/
-static void usb_host_auto_add(int bus_num, int addr, int vendor_id, int
product_id)
+static int parse_filter(const char *spec, struct USBAutoFilter *f)
{
-struct USBAutoFilter *f = qemu_mallocz(sizeof(*f));
+enum { BUS, DEV, VID, PID, DONE };
+const char *p = spec;
+int i;
+
+f->bus_num= -1;
+f->addr = -1;
+f->vendor_id = -1;
+f->product_id = -1;
+
+for (i = BUS; i < DONE; i++) {
+ p = strpbrk(p, ":.");
+ if (!p) break;
+p++;
+
+ if (*p == '*')
+continue;
+
+switch(i) {
+case BUS: f->bus_num = strtol(p, NULL, 10);break;
+case DEV: f->addr= strtol(p, NULL, 10);break;
+case VID: f->vendor_id =
[PATCH] husb: Make control transactions asynchronous (v2)
USB is 99.8% async now :). 0.2% is the three control requests that
we need to execute synchronously. We could off-load that to a thread
or something but it's not worth the pain since those requests are
performed only during device initialization (ie when device is
connected to the VM).
The change is a bit bigger than I wanted due to the fact that generic
handle_packet()/handle_control() interface was not designed for
async transactions. So I ended up adding custom handle_packet()
code to usb-linux. We can make that generic if/when some other
component needs it.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
usb-linux.c | 464 +++
1 files changed, 371 insertions(+), 93 deletions(-)
diff --git a/usb-linux.c b/usb-linux.c
index c31d56a..b82c4f6 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -25,28 +25,20 @@
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
+
#include "qemu-common.h"
#include "qemu-timer.h"
-#include "hw/usb.h"
#include "console.h"
#if defined(__linux__)
#include
#include
-#include
-#include
#include
-/* We redefine it to avoid version problems */
-struct usb_ctrltransfer {
-uint8_t bRequestType;
-uint8_t bRequest;
-uint16_t wValue;
-uint16_t wIndex;
-uint16_t wLength;
-uint32_t timeout;
-void *data;
-};
+#include
+#include
+#include
+#include "hw/usb.h"
typedef int USBScanFunc(void *opaque, int bus_num, int addr, int class_id,
int vendor_id, int product_id,
@@ -54,7 +46,6 @@ typedef int USBScanFunc(void *opaque, int bus_num, int addr,
int class_id,
static int usb_host_find_device(int *pbus_num, int *paddr,
char *product_name, int product_name_size,
const char *devname);
-
//#define DEBUG
#ifdef DEBUG
@@ -67,14 +58,32 @@ static int usb_host_find_device(int *pbus_num, int *paddr,
#define PRODUCT_NAME_SZ 32
#define MAX_ENDPOINTS 16
-struct sigaction sigact;
-
/* endpoint association data */
struct endp_data {
uint8_t type;
uint8_t halted;
};
+enum {
+CTRL_STATE_IDLE = 0,
+CTRL_STATE_SETUP,
+CTRL_STATE_DATA,
+CTRL_STATE_ACK
+};
+
+/*
+ * Control transfer state.
+ * Note that 'buffer' _must_ follow 'req' field because
+ * we need contigious buffer when we submit control URB.
+ */
+struct ctrl_struct {
+uint16_t len;
+uint16_t offset;
+uint8_t state;
+struct usb_ctrlrequest req;
+uint8_t buffer[1024];
+};
+
typedef struct USBHostDevice {
USBDevice dev;
int fd;
@@ -82,8 +91,10 @@ typedef struct USBHostDevice {
uint8_t descr[1024];
int descr_len;
int configuration;
+int ninterfaces;
int closing;
+struct ctrl_struct ctrl;
struct endp_data endp_table[MAX_ENDPOINTS];
/* Host side address */
@@ -172,6 +183,26 @@ static void async_free(AsyncURB *aurb)
qemu_free(aurb);
}
+static void async_complete_ctrl(USBHostDevice *s, USBPacket *p)
+{
+switch(s->ctrl.state) {
+case CTRL_STATE_SETUP:
+if (p->len < s->ctrl.len)
+s->ctrl.len = p->len;
+s->ctrl.state = CTRL_STATE_DATA;
+p->len = 8;
+break;
+
+case CTRL_STATE_ACK:
+s->ctrl.state = CTRL_STATE_IDLE;
+p->len = 0;
+break;
+
+default:
+break;
+}
+}
+
static void async_complete(void *opaque)
{
USBHostDevice *s = opaque;
@@ -204,6 +235,8 @@ static void async_complete(void *opaque)
switch (aurb->urb.status) {
case 0:
p->len = aurb->urb.actual_length;
+if (aurb->urb.type == USBDEVFS_URB_TYPE_CONTROL)
+async_complete_ctrl(s, p);
break;
case -EPIPE:
@@ -237,7 +270,7 @@ static void async_cancel(USBPacket *unused, void *opaque)
}
}
-static int usb_host_update_interfaces(USBHostDevice *dev, int configuration)
+static int usb_host_claim_interfaces(USBHostDevice *dev, int configuration)
{
int dev_descr_len, config_descr_len;
int interface, nb_interfaces, nb_configurations;
@@ -246,6 +279,8 @@ static int usb_host_update_interfaces(USBHostDevice *dev,
int configuration)
if (configuration == 0) /* address state - ignore */
return 1;
+dprintf("husb: claiming interfaces. config %d\n", configuration);
+
i = 0;
dev_descr_len = dev->descr[0];
if (dev_descr_len > dev->descr_len)
@@ -265,8 +300,10 @@ static int usb_host_update_interfaces(USBHostDevice *dev,
int configuration)
printf("husb: config #%d need %d\n", dev->descr[i + 5], configuration);
-if (configuration < 0 || configuration == dev->descr[i + 5])
+if (configuration < 0 || configuration == dev->descr[i + 5]) {
+configuration = dev->descr[i + 5];
break;
+}
i += config_descr_
Re: [ANNOUNCE] kvm-75 release
Avi Kivity wrote: > - restore option roms to their original content on reset > - fixes extboot failures after reset It doesn't seem to work here: $ dmesg | grep kvm | tail -1 [1649282.904413] loaded kvm module (kvm-75) $ sudo kvm | head -1 QEMU PC emulator version 0.9.1 (kvm-75), Copyright (c) 2003-2008 Fabrice Bellard $ sudo /usr/bin/kvm -M pc -m 512 -smp 1 -name svn -boot c -drive file=/dev/mapper/raid1-svn,if=virtio,index=0,boot=on At GRUB, I hit "c" for a command prompt, then type "reboot". At the reboot, the BIOS says: QEMU BIOS - build: 09/03/08 $Revision: 1.182 $ $Date: 2007/08/01 17:09:51 $ Options: apmbios pcibios eltorito rombios32 ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom Booting from Hard Disk... Boot from Hard Disk failed: could not read the boot disk FATAL: No bootable device. With if=ide, rebooting in this manner works fine. -jim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network Overruns
xming wrote: >> Most likely the guest's rx queue length is greater than the host's. You >> might try >> >> ifconfig vnet0 txqueuelen 1500 >> >> (and so on for every interface) >> >> >> or perhaps reducing the guests' txqueuelen. >> > > I have the same issue (overruns) and I have stalled network (in my other > report I can only unstall the network by putting the NIC in promisc back > and forth). > > The txqueuelen is indeed greater in the guest then the tap on the host, > and I also notice that it's almost ways the output NIc which get stuck. > > So changing the tap (on the host) to 1500, I can't not reproduce the hang yet > and a ping -f -s 64000 (between guests) does not produce any packet loss. > > 27810 packets transmitted, 27809 received, 0% packet loss, time 259080ms > rtt min/avg/max/mdev = 5.013/7.639/33.999/1.536 ms, pipe 3, ipg/ewma > 9.316/7.284 ms > > I hope this is the solution for my network stalls and packet loss in games. > It's not a fix, rather a workaround. Hopefully some networking guru will come up with a real fix. What NIC model are you using in the guest? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tape support
Laurent Vivier wrote: >> How would that work? Won't qemu attempt to show the tape as a disk? Or >> does it detect this special case and passes-through the scsi device? >> > > Yes, Qemu detects it's SCSI interface and passes the SCSI commands to > devices. But qemu ignores the type of the device but OS (linux) detects > this as a tape (with INQUIRY). > > It works well for CD/DVD and disk, but I'm working with Dietmar to make > it working with tape (commands encoding differs)... and I found some > devices to test. > Neat... -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: > Avi Kivity wrote: > >> Farkas Levente wrote: >> >>> Avi Kivity wrote: >>> >>> Farkas Levente wrote: > ok this last one was my fault:-( > but i retest is again. > - kvm-74 with kmod-kvm-74 not working > - kvm-71 with kmod-kvm-74 working > any progress with this? > anyone can test it with a simple minimal mandrake-10 install. after the > install the system can't boot. > yours. > > > Please provide a pointer to a test .iso image. >>> ftp://carroll.aset.psu.edu/pub/linux/distributions/mandrivalinux/old/10.0/i586/ >>> or the isos: >>> ftp://carroll.aset.psu.edu/pub/linux/distributions/mandrivalinux/official/iso/10.0/i586/ >>> >>> >> The ISO for the first CD is corrupted; I downloaded it twice, yet I get >> the wrong md5sum (and installation fails on some bad package). >> >> Do you have an alternate location? >> >> > > just to find something close to you: > ftp://ftp.heanet.ie/pub/mandrake/Mandrakelinux/official/iso/10.0/i586/ > anyway: > http://www.mandriva.com/en/download > > It's broken too. Maybe it was broken on the master and everyone mirrored it. If you have a good copy, please upload it somewhere. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm userland: Build misses -I
Avi Kivity wrote: Ben Bucksch wrote: configure accepts the kernel source dir as input param, or automatically finds /lib/modules/2.6.27-rc5/build/ or similar. But the build only uses the dir to copy the latest kvm*.h into the local dir. The directory is not passed to gcc via -I . This results in a "linux/ioctl.h not found" and resulting errors, if /usr/include/linux/ does not exist. If I pass the kernel source explicitly, then please use it. 1. Please pass gcc -I/include/ What are you doing exactly? I've never had such issues. Well, I'd assume so, otherwise they'd be fixed I hope :). What I did: 1. Extract Linus kernel source in /usr/src/, resulting in /usr/src/linux-2.6.26/ 2. Build kernel (in source dir) 3. Install kernel to /boot/ and /lib/modules/ via make install; make modules_install etc. 4. Extract kvm git 5. KVM source dir: ./configure --with-patched-kernel --disable-sdl --disable-gfx-check ; make 6. Get lots of errors due to Version mismatch of kvm.h in kernel and libkvm.c in KVM, which actually turned out to be bogus (other bug, see other mail) 7. rm -rf /usr/include/linux/ 8. KVM source dir: ./configure --with-patched-kernel --disable-sdl --disable-gfx-check --kerneldir=/usr/src/linux-2.6.26/ ; make 9. Above error Reason is, as said, that the build assumes that /usr/include/linux/ioctl.h exists, i.e. it just #include , but does not pass the kernel dir *that I explicitly passed to configure* to gcc. If I explicitly pass the kernel dir to configure, I expect that to be used, and only that. So, just pass gcc -I/include/ iggy on IRC noted that kernel source and build dir may be separate. That's true - you probably need two configure flags --kernel-source-dir and --kernel-build-dir. The existing --kerneldir could stay and set both to the same value. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Avi Kivity wrote: > Farkas Levente wrote: >> Avi Kivity wrote: >> >>> Farkas Levente wrote: >>> ok this last one was my fault:-( but i retest is again. - kvm-74 with kmod-kvm-74 not working - kvm-71 with kmod-kvm-74 working any progress with this? anyone can test it with a simple minimal mandrake-10 install. after the install the system can't boot. yours. >>> Please provide a pointer to a test .iso image. >>> >> ftp://carroll.aset.psu.edu/pub/linux/distributions/mandrivalinux/old/10.0/i586/ >> or the isos: >> ftp://carroll.aset.psu.edu/pub/linux/distributions/mandrivalinux/official/iso/10.0/i586/ >> > > The ISO for the first CD is corrupted; I downloaded it twice, yet I get > the wrong md5sum (and installation fails on some bad package). > > Do you have an alternate location? > just to find something close to you: ftp://ftp.heanet.ie/pub/mandrake/Mandrakelinux/official/iso/10.0/i586/ anyway: http://www.mandriva.com/en/download -- Levente "Si vis pacem para bellum!" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mandrake-10 not able to boot on kvm-71-73
Farkas Levente wrote: > Avi Kivity wrote: > >> Farkas Levente wrote: >> >>> ok this last one was my fault:-( >>> but i retest is again. >>> - kvm-74 with kmod-kvm-74 not working >>> - kvm-71 with kmod-kvm-74 working >>> any progress with this? >>> anyone can test it with a simple minimal mandrake-10 install. after the >>> install the system can't boot. >>> yours. >>> >>> >> Please provide a pointer to a test .iso image. >> > > ftp://carroll.aset.psu.edu/pub/linux/distributions/mandrivalinux/old/10.0/i586/ > or the isos: > ftp://carroll.aset.psu.edu/pub/linux/distributions/mandrivalinux/official/iso/10.0/i586/ > The ISO for the first CD is corrupted; I downloaded it twice, yet I get the wrong md5sum (and installation fails on some bad package). Do you have an alternate location? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VMX: NMI injection without virtual NMI support
Jan Kiszka wrote: >> In some cases misbehaving NMIs are worse than no NMIs. For example, a >> software watchdog may use NMIs to monitor a system. But if the guest >> spins with interrupts disabled, the irq window will never open, and NMIs >> will never be delivered, so the watchdog will deliver a false negative. >> >> > > I fail to see the regression. Currently that watchdog would _always_ > deliver false positives and pull the trigger immediately (in fact, this > is precisely the situation we face @work with some special board > emulation where we have to provide an NMI-based watchdog). > > Linux checks whether nmi works and enables it only if it does (I think -- not sure). So for Linux, there would be a regression. > Moreover, only the second and succeeding NMIs under the same > interrupts-disabled window need to get lost: Along with injecting the > first NMI we could request the IRQ window unconditionally, using it to > reset the virtual NMI-blocked state. > But the interrupt window would never open. Consider a spin_lock() executing with interrupts disabled, on a spin lock that is already locked by the current cpu. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Move private memory slot position
Avi Kivity wrote: > Yang, Sheng wrote: > >> On Thursday 04 September 2008 11:30:20 Yang, Sheng wrote: >> >> >>> From ebe4ea311305d2910dcdcff2510662da0dc2c742 Mon Sep 17 00:00:00 2001 >>> From: Sheng Yang <[EMAIL PROTECTED]> >>> Date: Thu, 4 Sep 2008 03:11:48 +0800 >>> Subject: [PATCH] KVM: VMX: Move private memory slot position >>> >>> PCI device assignment would map guest MMIO spaces as separate slot, so it >>> is possible that the device has more than 2 MMIO spaces and overwrite >>> current private memslot. >>> >>> The patch move private memory slot to the top of userspace visible memory >>> slots. >>> >>> >>> >> Avi, these two? >> >> > > Thanks, applied both. > > Note that kvm now exports the number of slots using KVM_CAP_NR_MEMSLOTS, > so userspace could be made dynamic. > Well, the kernel change causes the host to oops while booting Windows on an i386 pae host. No idea why. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Network Overruns
> Most likely the guest's rx queue length is greater than the host's. You > might try > > ifconfig vnet0 txqueuelen 1500 > > (and so on for every interface) > > > or perhaps reducing the guests' txqueuelen. I have the same issue (overruns) and I have stalled network (in my other report I can only unstall the network by putting the NIC in promisc back and forth). The txqueuelen is indeed greater in the guest then the tap on the host, and I also notice that it's almost ways the output NIc which get stuck. So changing the tap (on the host) to 1500, I can't not reproduce the hang yet and a ping -f -s 64000 (between guests) does not produce any packet loss. 27810 packets transmitted, 27809 received, 0% packet loss, time 259080ms rtt min/avg/max/mdev = 5.013/7.639/33.999/1.536 ms, pipe 3, ipg/ewma 9.316/7.284 ms I hope this is the solution for my network stalls and packet loss in games. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tape support
Le samedi 13 septembre 2008 à 07:51 +0300, Avi Kivity a écrit : > Laurent Vivier wrote: > > Le jeudi 11 septembre 2008 à 12:54 +0200, Dietmar Maurer a écrit : > > > >> Is there a way to use a scsi tape? I tried -drive file=/dev/sg0, but > >> that does not work (eject, rewind works, but read/write fails - no date > >> is written - no errors) > >> > > > > try "-drive file=/dev/sg0,if=scsi" > > > > How would that work? Won't qemu attempt to show the tape as a disk? Or > does it detect this special case and passes-through the scsi device? Yes, Qemu detects it's SCSI interface and passes the SCSI commands to devices. But qemu ignores the type of the device but OS (linux) detects this as a tape (with INQUIRY). It works well for CD/DVD and disk, but I'm working with Dietmar to make it working with tape (commands encoding differs)... and I found some devices to test. Regards, Laurent -- - [EMAIL PROTECTED] -- "La perfection est atteinte non quand il ne reste rien à ajouter mais quand il ne reste rien à enlever." Saint Exupéry -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
