[PATCH] uhci: Fixed length handling for SETUP and OUT tokens
Fixes regression reported agains Linux 2.6.18.
Looks like XP and newer Linux kernels are less sensitive
to length returned for control transfers.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
hw/usb-uhci.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 0714520..86b4696 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -651,7 +651,7 @@ static int uhci_broadcast_packet(UHCIState *s, USBPacket *p)
dprintf("uhci: packet enter. pid %s addr 0x%02x ep %d len %d\n",
pid2str(p->pid), p->devaddr, p->devep, p->len);
-if (p->pid == USB_TOKEN_OUT)
+if (p->pid == USB_TOKEN_OUT || p->pid == USB_TOKEN_SETUP)
dump_data(p->data, p->len);
ret = USB_RET_NODEV;
@@ -771,7 +771,7 @@ out:
static int uhci_handle_td(UHCIState *s, uint32_t addr, UHCI_TD *td, uint32_t
*int_mask)
{
UHCIAsync *async;
-int len = 0, max_len, ret = 0;
+int len = 0, max_len;
uint8_t pid;
/* Is active ? */
@@ -814,12 +814,13 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
case USB_TOKEN_OUT:
case USB_TOKEN_SETUP:
cpu_physical_memory_read(td->buffer, async->buffer, max_len);
-ret = uhci_broadcast_packet(s, &async->packet);
-len = max_len;
+len = uhci_broadcast_packet(s, &async->packet);
+if (len >= 0)
+len = max_len;
break;
case USB_TOKEN_IN:
-ret = uhci_broadcast_packet(s, &async->packet);
+len = uhci_broadcast_packet(s, &async->packet);
break;
default:
@@ -830,17 +831,17 @@ static int uhci_handle_td(UHCIState *s, uint32_t addr,
UHCI_TD *td, uint32_t *in
return -1;
}
-if (ret == USB_RET_ASYNC) {
+if (len == USB_RET_ASYNC) {
uhci_async_link(s, async);
return 2;
}
-async->packet.len = ret;
+async->packet.len = len;
done:
-ret = uhci_complete_td(s, td, async, int_mask);
+len = uhci_complete_td(s, td, async, int_mask);
uhci_async_free(s, async);
-return ret;
+return len;
}
static void uhci_async_complete(USBPacket *packet, void *opaque)
--
1.5.5.1
--
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] uhci: improved TD matching, working ISOC transfers
While trying to make VX-3000 camera work on XP under KVM I realized that
we do not necessarily have to find original TD address. All we care about
is the token which identifies the transfer rather well (direction, endpoint,
size, etc).
This is especially important for the isochronous transfers because otherwise
they are being canceled left and right and we do not make much progress.
With this patch all devices that used bulk transfers that I've tried so
far continue to work just as well. And now my USB web cammera (isoc transfers)
is working well tool. It's not as smooth as native Windows but it's pretty
darn smooth.
The cool thing is that new USB code (both usb-uhci and usb-linux) is totaly
generic and does not need any special logic for ISOC.
Signed-off-by: Max Krasnyansky <[EMAIL PROTECTED]>
---
hw/usb-uhci.c | 40
1 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1b15074..0714520 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -265,25 +265,41 @@ static void uhci_async_cancel_all(UHCIState *s)
static UHCIAsync *uhci_async_find_td(UHCIState *s, uint32_t addr, uint32_t
token)
{
UHCIAsync *async = s->async_pending;
+UHCIAsync *match = NULL;
+int count = 0;
+
+/*
+ * We're looking for the best match here. ie both td addr and token.
+ * Otherwise we return last good match. ie just token.
+ * It's ok to match just token because it identifies the transaction
+ * rather well, token includes: device addr, endpoint, size, etc.
+ *
+ * Also since we queue async transactions in reverse order by returning
+ * last good match we restores the order.
+ *
+ * It's expected that we wont have a ton of outstanding transactions.
+ * If we ever do we'd want to optimize this algorithm.
+ */
while (async) {
-if (async->td == addr) {
-if (async->token == token)
-return async;
-
-/*
- * TD was reused for a different transfer.
- * Invalidate the original one asap.
- */
-if (async->valid > 0) {
-async->valid = 0;
-dprintf("husb: bad reuse. td 0x%x\n", async->td);
+if (async->token == token) {
+/* Good match */
+match = async;
+
+if (async->td == addr) {
+/* Best match */
+break;
}
}
async = async->next;
+count++;
}
-return NULL;
+
+if (count > 64)
+ fprintf(stderr, "uhci: warning lots of async transactions\n");
+
+return match;
}
static void uhci_attach(USBPort *port1, USBDevice *dev);
--
1.5.5.1
--
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-73 release
Avi Kivity wrote:
> Avi Kivity wrote:
>> Zhang, Xiantao wrote:
>>> Hi, AviSince ia64 has supported userspace's build, could we
>>> include ia64 bits in next release?
>>
>> I updated my scripts. I'll send you a test tarball via private mail
>> to see I hadn't missed any files.
>>
>
> Better a link: http://userweb.kernel.org/~avi/test.tar.gz
Hi, Avi
You may need to apply this patch, and regenerate the package again
to keep kvm/ia64 compatible with Linux-2.6.26 and newer versions. :)
Thannks
Xiantao
>From e552da3b1e7d2d30bcd09982d313ebf74c348be1 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Fri, 22 Aug 2008 11:07:37 +0800
Subject: [PATCH] KVM: external module: keep kvm/ia64 compatible with
Linux-2.6.26 and newer version.
Add some compatibility hack for Linux-2.6.26 and newer versions for ia64
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
kernel/Makefile |4 ++--
kernel/external-module-compat-comm.h | 13 -
kernel/ia64/Kbuild |2 +-
kernel/ia64/external-module-compat.h | 34
++
kernel/ia64/hack-module.awk | 14 ++
kernel/x86/external-module-compat.h | 14 ++
kernel/{ => x86}/hack-module.awk |0
7 files changed, 65 insertions(+), 16 deletions(-)
create mode 100644 kernel/ia64/hack-module.awk
rename kernel/{ => x86}/hack-module.awk (100%)
diff --git a/kernel/Makefile b/kernel/Makefile
index 6f8cc9d..3f5f6da 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -19,7 +19,7 @@ LINUX = ../linux-2.6
version = $(shell cd $(LINUX); git describe)
_hack = mv $1 $1.orig && \
- gawk -v version=$(version) -f hack-module.awk $1.orig \
+ gawk -v version=$(version) -f $(ARCH_DIR)/hack-module.awk
$1.orig \
| sed '/\#include/! s/\blapic\b/l_apic/g' > $1 && rm $1.orig
unifdef = mv $1 $1.orig && \
@@ -29,7 +29,7 @@ unifdef = mv $1 $1.orig && \
hack = $(call _hack,$T/$(strip $1))
hack-files-x86 = kvm_main.c mmu.c vmx.c svm.c x86.c irq.h lapic.c
i8254.c
-hack-files-ia64 =
+hack-files-ia64 = kvm_main.c kvm_fw.c
hack-files = $(hack-files-$(ARCH_DIR))
diff --git a/kernel/external-module-compat-comm.h
b/kernel/external-module-compat-comm.h
index 97e921b..fcffb1f 100644
--- a/kernel/external-module-compat-comm.h
+++ b/kernel/external-module-compat-comm.h
@@ -17,7 +17,6 @@
#include
#include
#include
-#include
/*
* 2.6.16 does not have GFP_NOWAIT
@@ -40,18 +39,6 @@
#define prof_on 4321
#endif
-/*
- * smp_call_function_single() is not exported below 2.6.20, and has
different
- * semantics below 2.6.23. The 'nonatomic' argument was removed in
2.6.27.
- */
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)
-
-int kvm_smp_call_function_single(int cpu, void (*func)(void *info),
-void *info, int wait);
-
-#define smp_call_function_single kvm_smp_call_function_single
-
-#endif
/* on_each_cpu() lost an argument in 2.6.27. */
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)
diff --git a/kernel/ia64/Kbuild b/kernel/ia64/Kbuild
index 764a493..50af491 100644
--- a/kernel/ia64/Kbuild
+++ b/kernel/ia64/Kbuild
@@ -1,6 +1,6 @@
obj-m := kvm.o kvm-intel.o
-kvm-objs := kvm_main.o ioapic.o coalesced_mmio.o kvm-ia64.o kvm_fw.o
+kvm-objs := kvm_main.o ioapic.o coalesced_mmio.o kvm-ia64.o kvm_fw.o
../anon_inodes.o
EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127
kvm-intel-objs := vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o
mmio.o \
diff --git a/kernel/ia64/external-module-compat.h
b/kernel/ia64/external-module-compat.h
index 3c4001c..1f8dc9b 100644
--- a/kernel/ia64/external-module-compat.h
+++ b/kernel/ia64/external-module-compat.h
@@ -2,8 +2,11 @@
* Compatibility header for building as an external module.
*/
+#ifndef __ASSEMBLY__
#include
+#include "../external-module-compat-comm.h"
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,26)
#error "KVM/IA-64 Can't be compiled if kernel version < 2.6.26"
#endif
@@ -13,3 +16,34 @@
TODO: Implement it later! */
#error "KVM/IA-64 depends on preempt notifiers in kernel."
#endif
+
+/* on_each_cpu() lost an argument in 2.6.27. */
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)
+
+#define kvm_smp_call_function(func, info, wait) smp_call_function(func,
info, 0, wait)
+
+#else
+
+#define kvm_smp_call_function(func, info, wait) smp_call_function(func,
info, wait)
+
+#endif
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,27)
+
+/* The 'nonatomic' argument was removed in 2.6.27. */
+
+#undef smp_call_function_single
+
+#include
+
+static inline int kvm_smp_call_function_single(int cpu, void
(*func)(void *info),
+void *info, int wait)
+{
+ return smp_call_function_single(cpu, func, info, 0, wait);
+}
+
+#define smp_call_function_single kvm_smp_call_function_single
+
+#endif
+
+#endif
diff --git a/kernel/ia64/hack-module.awk b/kernel/ia64/hack-module.awk
new file mode 100644
ind
Re: [PATCH 0/8] Various USB fixes and improvements (update 2)
Max Krasnyansky wrote: This is an updated version of the USB patches I sent out yesterday. It includes changes and fixes suggested by Anthony. Applied whole series. 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
kvm-70; Ubuntu Hardy: many kvm_handle_exit errors in dmesg
Greetings, I'm running KVM-70 on Ubuntu Hardy (2.6.24-16-server x86_64) running ten VMs. After some time, I start to get this message in dmesg: kvm_handle_exit: unexpected, valid vectoring info and exit reason is 0x9 And a bunch of these in my syslog: Aug 21 06:43:57 trinity kernel: tortorintortttotoritoritoritoritoritortoritortoritoritortoritoritortoritoritortorit... (line shortened easy posting but it continues on like that) Both lines are repeating at an approximate rate of several hundred per second. The syslog entries start almost immediately after the kvm_handle_exit entries so it's likely just the kernel flooding syslog. The problem goes away when I migrate the VMs to another host (and does not restart on the new host until some time later). As far as I can tell, the guests are not affected by this. I only notice the problem when the rapidly growing syslog starts to fill my disk. Any idea what be could be causing this and how might I go about fixing it? Thanks. -- Randy Smith http://www.vuser.org/ signature.asc Description: This is a digitally signed message part.
Re: [PATCH 0/8] Various USB fixes and improvements (update 2)
Max Krasnyansky wrote: Anthony Liguori wrote: Any objections to applying this series? It seems like the consensus is that OHCI support is better long term but this series seems pretty sane and self-contained. I'm actually having seconds thought on the OHCI vs UHCI. You probably saw my reply to Paul. New UHCI code is fairly clean and simple, and is working well. But I definitely think that we should fix OHCI too, and at some point we need to add EHCI (ie USB 2.0 stuff). I have more patches coming. I made isoc transactions work on Friday which made MS VX-3000 USB camera totally usable (will send a patch in a couple of hours). And I'm working on making control transactions async too which should shave off last bits of bad latency (2-3milliseconds) from the USB code. Initially I thought control stuff is not very frequent but this stupid USB webcam drivers does one very often. So yeah, it be nice if this stuff is merged soonish :). btw If you're using git as a front end to the SVN I can push my git tree somewhere to kernel.org so that you can just pull the whole thing. Yes, please do for the future. 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: [ANNOUNCE] kvm-73 release
Avi Kivity wrote: > Zhang, Xiantao wrote: >> Hi, Avi >>Since ia64 has supported userspace's build, could we include ia64 >> bits in next release? >> > > I updated my scripts. I'll send you a test tarball via private mail > to see I hadn't missed any files. Great! I will guarantee it can work well on ia64 platforms. Thanks! Xiantao -- 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/4] libkvm: add kvm_has_mmu_notifiers
Anthony Liguori wrote: This patch adds a kvm_has_mmu_notifiers routine to libkvm. This allows userspace to query the existence of mmu notifiers which is important for ballooning since madvise() is not safe from userspace without it. Can we call this kvm_has_sync_mmu()? s390 doesn't need mmu notifiers, but still has a synchronized mmu. mmu notifiers is the implementation, while a synchronized mmu is the goal. -- error compiling committee.c: too many arguments to function -- 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: qemu: Handle tap fds with IFF_VNET_HDR
Avi Kivity wrote: Mark McLoughlin wrote: I'll take a stab at "-capabilities" later. It's quite tricky; anything we forget now, we won't have a way to detect in the future, so it needs to be fairly complete. BTW, I prefer that it's part of the output from -version. Regards, Anthony Liguori In the mean time, it may make sense to commit the patch minus the -help string. Done. -- 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: qemu: Handle tap fds with IFF_VNET_HDR
Mark McLoughlin wrote: I'll take a stab at "-capabilities" later. It's quite tricky; anything we forget now, we won't have a way to detect in the future, so it needs to be fairly complete. In the mean time, it may make sense to commit the patch minus the -help string. Done. -- error compiling committee.c: too many arguments to function -- 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] Use .fixup instead of .text.fixup on __kvm_handle_fault_on_reboot
Eduardo Habkost wrote: [oops. sent it to the old kvm-devel list. sending to the right list, now] vmlinux.lds expects the fixup code to be on a section named .fixup. The .text.fixup section is not mentioned on vmlinux.lds, and is included on the resulting vmlinux (just after .text) only because of ld heuristics on placing orphan sections. However, placing .text.fixup outside .text breaks the definition of _etext, making it exclude the .text.fixup contents. That makes .text.fixup be ignored by the kernel initialization code that needs to know about section locations, such as the code setting page protection bits. Applied, thanks. -- error compiling committee.c: too many arguments to function -- 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: Issues while "Debugging Windows Kernel" running on KVM
Can you try http://kvm.qumranet.com/kvmwiki/WindowsGuestDebug You can use windows host as a VM too. Since (in the past) there was a problem with the virtual serial polling you can use -no-kvm and the qemu patch, as described in the wiki. Good luck, Dor. Muppana, Bhaskar wrote: Hi, I am facing issues while trying to debug Windows XP kernel running on top of Linux KVM. I have to debug Windows XP kernel running in a VM. I have dedicated ttyS0 on the host to the guest. I am using the following command to bring up Windows VM. /usr/local/kvm/bin/qemu-system-x86_64 \ -hda /opt/vdisk.img \ -boot c \ -m 512 \ -net nic,model=rtl8139,macaddr=52:54:00:12:34:56 \ -net tap,ifname=qtap0,script=no \ -smp 1 \ -usb \ -usbdevice tablet \ -localtime \ -serial /dev/ttyS0 I have another machine, running Windows XP, connected to the Linux host through serial cable. |Windows | | VM| |(target)| --- | Windows Host | - | Linux with KVM | --- I am able to send messages between Windows host and target through serial ports (tested using windows power shell). But, I am not able to use Win DBG (Kernel Debugger) in host to connect to target. Target is getting stuck while booting. Debug enabled Windows entry in boot.ini: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /debugport=COM1 /baudrate=115200 Can someone please help me regarding this? Thanks, Bhaskar -- 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 -- 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 assignemnt with VT-d
* On Thursday 21 Aug 2008 16:35:57 Ben-Ami Yassour wrote:
> On Thu, 2008-08-21 at 12:13 +0530, Amit Shah wrote:
> > * On Thursday 07 Aug 2008 19:44:47 Ben-Ami Yassour wrote:
> > > Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
> > >
> > > This patch enables pci device assignment based on VT-d support.
> > > When a device is assigned to the guest, the guest memory is pinned and
> > > the mapping is updated in the VT-d IOMMU.
> > >
> > > Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
> > > Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
> > > Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
> > > ---
> > > arch/x86/kvm/Makefile |3 +
> > > arch/x86/kvm/vtd.c | 203
> > > arch/x86/kvm/x86.c
> > > | 10 ++
> > > include/asm-x86/kvm_host.h |3 +
> > > include/linux/kvm_host.h | 32 +++
> > > virt/kvm/kvm_main.c|9 ++-
> > > 6 files changed, 259 insertions(+), 1 deletions(-)
> > > create mode 100644 arch/x86/kvm/vtd.c
> > >
> > > +int kvm_iommu_map_guest(struct kvm *kvm,
> > > + struct kvm_assigned_dev_kernel *assigned_dev)
> > > +{
> > > + struct pci_dev *pdev = NULL;
> > > + int rc;
> > > +
> > > + if (!intel_iommu_found()) {
> > > + printk(KERN_ERR "intel iommu not found\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + printk(KERN_DEBUG "VT-d direct map: host bdf = %x:%x:%x\n",
> > > +assigned_dev->host_busnr,
> > > +PCI_SLOT(assigned_dev->host_devfn),
> > > +PCI_FUNC(assigned_dev->host_devfn));
> > > +
> > > + pdev = assigned_dev->dev;
> > > +
> > > + if (pdev == NULL) {
> > > + if (kvm->arch.intel_iommu_domain) {
> > > + intel_iommu_domain_exit(kvm->arch.intel_iommu_domain);
> > > + kvm->arch.intel_iommu_domain = NULL;
> > > + }
> > > + return -ENODEV;
> > > + }
> > > +
> > > + kvm->arch.intel_iommu_domain = intel_iommu_domain_alloc(pdev);
> > >
> > > +int kvm_iommu_unmap_guest(struct kvm *kvm)
> > > +{
> > > + struct kvm_assigned_dev_kernel *entry;
> > > + struct pci_dev *pdev = NULL;
> > > + struct dmar_domain *domain = kvm->arch.intel_iommu_domain;
> > > +
> > > + /* check if iommu exists and in use */
> > > + if (!domain)
> > > + return 0;
> > > +
> > > + list_for_each_entry(entry, &kvm->arch.assigned_dev_head, list) {
> > > + printk(KERN_DEBUG "VT-d unmap: host bdf = %x:%x:%x\n",
> > > +entry->host_busnr,
> > > +PCI_SLOT(entry->host_devfn),
> > > +PCI_FUNC(entry->host_devfn));
> > > +
> > > + for_each_pci_dev(pdev) {
> > > + if ((pdev->bus->number == entry->host_busnr) &&
> > > + (pdev->devfn == entry->host_devfn))
> > > + break;
> > > + }
> > > +
> > > + if (pdev == NULL)
> > > + return -ENODEV;
> > > +
> > > + /* detach kvm dmar domain */
> > > + intel_iommu_detach_dev(domain,
> > > +pdev->bus->number, pdev->devfn);
> > > + }
> > > + kvm_iommu_unmap_memslots(kvm);
> > > + intel_iommu_domain_exit(domain);
> > > + return 0;
> > > +}
> > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > > index a97157c..5cfc21a 100644
> > > --- a/arch/x86/kvm/x86.c
> > > +++ b/arch/x86/kvm/x86.c
> > > @@ -35,6 +35,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -271,9 +272,17 @@ static int kvm_vm_ioctl_assign_device(struct kvm
> > > *kvm,
> > >
> > > list_add(&match->list, &kvm->arch.assigned_dev_head);
> > >
> > > + /* currenlty iommu is required for handling dma */
> > > + r = kvm_iommu_map_guest(kvm, match);
> > > + if (r)
> > > + goto out_list_del;
> > > +
> >
> > This will break pvdma support. Please check if intel-iommu is found and
> > only then bail out of here.
> >
> > Even though pvdma is out-of-tree, it doesn't make sense to restrict our
> > usage here. AMD IOMMU support will need this to be handled in the right
> > way as well.
> >
> > > out:
> > > mutex_unlock(&kvm->lock);
> > > return r;
> > > +out_list_del:
> > > + list_del(&match->list);
> > > + pci_release_regions(dev);
> > > out_disable:
> > > pci_disable_device(dev);
> > > out_put:
> > > @@ -4219,6 +4228,7 @@ static void kvm_free_vcpus(struct kvm *kvm)
> > >
> > > void kvm_arch_destroy_vm(struct kvm *kvm)
> > > {
> > > + kvm_iommu_unmap_guest(kvm);
> >
> > Likewise, check if intel-iommu is found as a first step in this function.
> >
> > As part of getting AMD-iommu and pvdma support in, we should have generic
> > function names, but that can be done later.
> >
> > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > > index a18aaad..b703890 100644
> > > --- a/include/linux/kvm_host.h
> > > +++ b/include/linux/kvm_host.h
> > > @@ -285,6 +285,33 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v);
> > > int k
Re: [ANNOUNCE] kvm-73 release
Avi Kivity wrote: Zhang, Xiantao wrote: Hi, AviSince ia64 has supported userspace's build, could we include ia64 bits in next release? I updated my scripts. I'll send you a test tarball via private mail to see I hadn't missed any files. Better a link: http://userweb.kernel.org/~avi/test.tar.gz -- error compiling committee.c: too many arguments to function -- 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-73 release
Zhang, Xiantao wrote: Hi, Avi Since ia64 has supported userspace's build, could we include ia64 bits in next release? I updated my scripts. I'll send you a test tarball via private mail to see I hadn't missed any files. -- error compiling committee.c: too many arguments to function -- 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-73 release
Yang, Sheng wrote: On Thursday 21 August 2008 00:43:22 Muli Ben-Yehuda wrote: On Wed, Aug 20, 2008 at 06:04:26PM +0300, Avi Kivity wrote: Other noteworthy changes: speedups of both virtio-net and qcow2 with cache=off. Two important works-in-progress: device assignment (not usable yet, as dma support is still missing) and the real-mode emulation framework. Hi Avi, The latest version of the VT-d patches for device assignment was posted by Ben on Aug 7th[1][2]. There were no substantial review comments, so... what are we waiting for? [1] http://www.mail-archive.com/kvm@vger.kernel.org/msg02554.html [2] http://www.mail-archive.com/kvm@vger.kernel.org/msg02553.html Hi Muli The next step should be send the first patch to linux-pci(and CC Jesse Barnes and other guys) to have review, for it related to DMAR modification... I think we mentioned that in recent comments, and I meant to remind Ben about that, but forgot it... Yeah. I can queue the patch, provided it is acked by the VT-d maintainer. -- error compiling committee.c: too many arguments to function -- 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] Make " make sync" get correct header files with latest Linux source.
Zhang, Xiantao wrote: Avi, Please drop the previous one due to its incompleteness, and help to check-in this one. Sure; applied. -- error compiling committee.c: too many arguments to function -- 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 2/2] KVM: Device assignemnt with VT-d
Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
This patch enables pci device assignment based on VT-d support.
When a device is assigned to the guest, the guest memory is pinned and
the mapping is updated in the VT-d IOMMU.
Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
---
arch/x86/kvm/Makefile |3 +
arch/x86/kvm/vtd.c | 203
arch/x86/kvm/x86.c | 10 ++
include/asm-x86/kvm_host.h |3 +
include/linux/kvm_host.h | 32 +++
virt/kvm/kvm_main.c|9 ++-
6 files changed, 259 insertions(+), 1 deletions(-)
create mode 100644 arch/x86/kvm/vtd.c
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index d0e940b..3072b17 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -12,6 +12,9 @@ EXTRA_CFLAGS += -Ivirt/kvm -Iarch/x86/kvm
kvm-objs := $(common-objs) x86.o mmu.o x86_emulate.o i8259.o irq.o lapic.o \
i8254.o
+ifeq ($(CONFIG_DMAR),y)
+kvm-objs += vtd.o
+endif
obj-$(CONFIG_KVM) += kvm.o
kvm-intel-objs = vmx.o
obj-$(CONFIG_KVM_INTEL) += kvm-intel.o
diff --git a/arch/x86/kvm/vtd.c b/arch/x86/kvm/vtd.c
new file mode 100644
index 000..4336769
--- /dev/null
+++ b/arch/x86/kvm/vtd.c
@@ -0,0 +1,203 @@
+/*
+ * Copyright (c) 2006, Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ * Copyright (C) 2006-2008 Intel Corporation
+ * Copyright IBM Corporation, 2008
+ * Author: Allen M. Kay <[EMAIL PROTECTED]>
+ * Author: Weidong Han <[EMAIL PROTECTED]>
+ * Author: Ben-Ami Yassour <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static int kvm_iommu_unmap_memslots(struct kvm *kvm);
+
+int kvm_iommu_map_pages(struct kvm *kvm,
+ gfn_t base_gfn, unsigned long npages)
+{
+ gfn_t gfn = base_gfn;
+ pfn_t pfn;
+ int i, rc;
+ struct dmar_domain *domain = kvm->arch.intel_iommu_domain;
+
+ /* check if iommu exists and in use */
+ if (!domain)
+ return 0;
+
+ for (i = 0; i < npages; i++) {
+ /* check if already mapped */
+ pfn = (pfn_t)intel_iommu_iova_to_pfn(domain,
+gfn_to_gpa(gfn));
+ if (pfn && !is_mmio_pfn(pfn))
+ continue;
+
+ pfn = gfn_to_pfn(kvm, gfn);
+ if (!is_mmio_pfn(pfn)) {
+ rc = intel_iommu_page_mapping(domain,
+ gfn_to_gpa(gfn),
+ pfn_to_hpa(pfn),
+ PAGE_SIZE,
+ DMA_PTE_READ |
+ DMA_PTE_WRITE);
+ if (rc) {
+ kvm_release_pfn_clean(pfn);
+ printk(KERN_DEBUG "kvm_iommu_map_pages:"
+ "iommu failed to map pfn=%lx\n", pfn);
+ return rc;
+ }
+ } else {
+ printk(KERN_DEBUG "kvm_iommu_map_page:"
+ "invalid pfn=%lx\n", pfn);
+ return 0;
+ }
+
+ gfn++;
+ }
+ return 0;
+}
+
+static int kvm_iommu_map_memslots(struct kvm *kvm)
+{
+ int i, rc;
+
+ down_read(&kvm->slots_lock);
+ for (i = 0; i < kvm->nmemslots; i++) {
+ rc = kvm_iommu_map_pages(kvm, kvm->memslots[i].base_gfn,
+kvm->memslots[i].npages);
+ if (rc) {
+ up_read(&kvm->slots_lock);
+ return rc;
+ }
+ }
+ up_read(&kvm->slots_lock);
+ return 0;
+}
+
+int kvm_iommu_map_guest(struct kvm *kvm,
+ struct kvm_assigned_dev_kernel *assigned_dev)
+{
+ struct pci_dev *pdev = NULL;
+ int rc;
+
+ if (!intel_iommu_found()) {
+ printk(KERN_ERR "intel iommu not found\n");
+ return -ENODEV;
+ }
+
+ printk(KERN_DEBUG "VT-d direct map: host bdf = %x:%x:%x\n",
+
[PATCH 1/2] VT-d: changes to support KVM
From: Kay, Allen M <[EMAIL PROTECTED]>
This patch extends the VT-d driver to support KVM
[Ben: fixed memory pinning]
Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
---
drivers/pci/dmar.c |4 +-
drivers/pci/intel-iommu.c| 117 +-
drivers/pci/iova.c |2 +-
{drivers/pci => include/linux}/intel-iommu.h | 11 +++
{drivers/pci => include/linux}/iova.h|0
5 files changed, 127 insertions(+), 7 deletions(-)
rename {drivers/pci => include/linux}/intel-iommu.h (94%)
rename {drivers/pci => include/linux}/iova.h (100%)
diff --git a/drivers/pci/dmar.c b/drivers/pci/dmar.c
index 8bf86ae..1df28ea 100644
--- a/drivers/pci/dmar.c
+++ b/drivers/pci/dmar.c
@@ -26,8 +26,8 @@
#include
#include
-#include "iova.h"
-#include "intel-iommu.h"
+#include
+#include
#undef PREFIX
#define PREFIX "DMAR:"
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 8d0e60a..1eefc60 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -20,6 +20,7 @@
* Author: Anil S Keshavamurthy <[EMAIL PROTECTED]>
*/
+#undef DEBUG
#include
#include
#include
@@ -33,8 +34,8 @@
#include
#include
#include
-#include "iova.h"
-#include "intel-iommu.h"
+#include
+#include
#include /* force_iommu in this header in x86-64*/
#include
#include
@@ -160,7 +161,7 @@ static inline void *alloc_domain_mem(void)
return iommu_kmem_cache_alloc(iommu_domain_cache);
}
-static inline void free_domain_mem(void *vaddr)
+static void free_domain_mem(void *vaddr)
{
kmem_cache_free(iommu_domain_cache, vaddr);
}
@@ -1414,7 +1415,7 @@ static void domain_remove_dev_info(struct dmar_domain
*domain)
* find_domain
* Note: we use struct pci_dev->dev.archdata.iommu stores the info
*/
-struct dmar_domain *
+static struct dmar_domain *
find_domain(struct pci_dev *pdev)
{
struct device_domain_info *info;
@@ -2430,3 +2431,111 @@ int __init intel_iommu_init(void)
return 0;
}
+void intel_iommu_domain_exit(struct dmar_domain *domain)
+{
+ u64 end;
+
+ /* Domain 0 is reserved, so dont process it */
+ if (!domain)
+ return;
+
+ end = DOMAIN_MAX_ADDR(domain->gaw);
+ end = end & (~PAGE_MASK_4K);
+
+ /* clear ptes */
+ dma_pte_clear_range(domain, 0, end);
+
+ /* free page tables */
+ dma_pte_free_pagetable(domain, 0, end);
+
+ iommu_free_domain(domain);
+ free_domain_mem(domain);
+}
+EXPORT_SYMBOL_GPL(intel_iommu_domain_exit);
+
+struct dmar_domain *intel_iommu_domain_alloc(struct pci_dev *pdev)
+{
+ struct dmar_drhd_unit *drhd;
+ struct dmar_domain *domain;
+ struct intel_iommu *iommu;
+
+ drhd = dmar_find_matched_drhd_unit(pdev);
+ if (!drhd) {
+ printk(KERN_ERR "intel_iommu_domain_alloc: drhd == NULL\n");
+ return NULL;
+ }
+
+ iommu = drhd->iommu;
+ if (!iommu) {
+ printk(KERN_ERR
+ "intel_iommu_domain_alloc: iommu == NULL\n");
+ return NULL;
+ }
+ domain = iommu_alloc_domain(iommu);
+ if (!domain) {
+ printk(KERN_ERR
+ "intel_iommu_domain_alloc: domain == NULL\n");
+ return NULL;
+ }
+ if (domain_init(domain, DEFAULT_DOMAIN_ADDRESS_WIDTH)) {
+ printk(KERN_ERR
+ "intel_iommu_domain_alloc: domain_init() failed\n");
+ intel_iommu_domain_exit(domain);
+ return NULL;
+ }
+ return domain;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_domain_alloc);
+
+int intel_iommu_context_mapping(
+ struct dmar_domain *domain, struct pci_dev *pdev)
+{
+ int rc;
+ rc = domain_context_mapping(domain, pdev);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_context_mapping);
+
+int intel_iommu_page_mapping(
+ struct dmar_domain *domain, dma_addr_t iova,
+ u64 hpa, size_t size, int prot)
+{
+ int rc;
+ rc = domain_page_mapping(domain, iova, hpa, size, prot);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_page_mapping);
+
+void intel_iommu_detach_dev(struct dmar_domain *domain, u8 bus, u8 devfn)
+{
+ detach_domain_for_dev(domain, bus, devfn);
+}
+EXPORT_SYMBOL_GPL(intel_iommu_detach_dev);
+
+struct dmar_domain *
+intel_iommu_find_domain(struct pci_dev *pdev)
+{
+ return find_domain(pdev);
+}
+EXPORT_SYMBOL_GPL(intel_iommu_find_domain);
+
+int intel_iommu_found(void)
+{
+ return g_num_of_iommus;
+}
+EXPORT_SYMBOL_GPL(intel_iommu_found);
+
+u64 intel_iommu_iova_to_pfn(struct dmar_domain *domain, u64 iova)
+{
+ struct dma_pte *pte;
+ u64 pfn;
+
+ pfn = 0;
+ pte = addr_to_dma_pte(domain, iova);
+
+ if (pte)
+ pfn = dma_pte_addr(*pte)
VT-d support for device assignment
Avi, I am re-sending the VT-d patches, please apply. The following two patches contains the VT-d support for device assignment. The first patch contains the changes that are required to the generic VT-d code. The second patch contains the changes to KVM. Regards, Ben -- 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 assignemnt with VT-d
On Thu, 2008-08-21 at 12:13 +0530, Amit Shah wrote:
> * On Thursday 07 Aug 2008 19:44:47 Ben-Ami Yassour wrote:
> > Based on a patch by: Kay, Allen M <[EMAIL PROTECTED]>
> >
> > This patch enables pci device assignment based on VT-d support.
> > When a device is assigned to the guest, the guest memory is pinned and
> > the mapping is updated in the VT-d IOMMU.
> >
> > Signed-off-by: Kay, Allen M <[EMAIL PROTECTED]>
> > Signed-off-by: Weidong Han <[EMAIL PROTECTED]>
> > Signed-off-by: Ben-Ami Yassour <[EMAIL PROTECTED]>
> > ---
> > arch/x86/kvm/Makefile |3 +
> > arch/x86/kvm/vtd.c | 203
> > arch/x86/kvm/x86.c |
> > 10 ++
> > include/asm-x86/kvm_host.h |3 +
> > include/linux/kvm_host.h | 32 +++
> > virt/kvm/kvm_main.c|9 ++-
> > 6 files changed, 259 insertions(+), 1 deletions(-)
> > create mode 100644 arch/x86/kvm/vtd.c
>
> > +int kvm_iommu_map_guest(struct kvm *kvm,
> > + struct kvm_assigned_dev_kernel *assigned_dev)
> > +{
> > + struct pci_dev *pdev = NULL;
> > + int rc;
> > +
> > + if (!intel_iommu_found()) {
> > + printk(KERN_ERR "intel iommu not found\n");
> > + return -ENODEV;
> > + }
> > +
> > + printk(KERN_DEBUG "VT-d direct map: host bdf = %x:%x:%x\n",
> > + assigned_dev->host_busnr,
> > + PCI_SLOT(assigned_dev->host_devfn),
> > + PCI_FUNC(assigned_dev->host_devfn));
> > +
> > + pdev = assigned_dev->dev;
> > +
> > + if (pdev == NULL) {
> > + if (kvm->arch.intel_iommu_domain) {
> > + intel_iommu_domain_exit(kvm->arch.intel_iommu_domain);
> > + kvm->arch.intel_iommu_domain = NULL;
> > + }
> > + return -ENODEV;
> > + }
> > +
> > + kvm->arch.intel_iommu_domain = intel_iommu_domain_alloc(pdev);
>
> > +int kvm_iommu_unmap_guest(struct kvm *kvm)
> > +{
> > + struct kvm_assigned_dev_kernel *entry;
> > + struct pci_dev *pdev = NULL;
> > + struct dmar_domain *domain = kvm->arch.intel_iommu_domain;
> > +
> > + /* check if iommu exists and in use */
> > + if (!domain)
> > + return 0;
> > +
> > + list_for_each_entry(entry, &kvm->arch.assigned_dev_head, list) {
> > + printk(KERN_DEBUG "VT-d unmap: host bdf = %x:%x:%x\n",
> > + entry->host_busnr,
> > + PCI_SLOT(entry->host_devfn),
> > + PCI_FUNC(entry->host_devfn));
> > +
> > + for_each_pci_dev(pdev) {
> > + if ((pdev->bus->number == entry->host_busnr) &&
> > + (pdev->devfn == entry->host_devfn))
> > + break;
> > + }
> > +
> > + if (pdev == NULL)
> > + return -ENODEV;
> > +
> > + /* detach kvm dmar domain */
> > + intel_iommu_detach_dev(domain,
> > + pdev->bus->number, pdev->devfn);
> > + }
> > + kvm_iommu_unmap_memslots(kvm);
> > + intel_iommu_domain_exit(domain);
> > + return 0;
> > +}
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index a97157c..5cfc21a 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -35,6 +35,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -271,9 +272,17 @@ static int kvm_vm_ioctl_assign_device(struct kvm *kvm,
> >
> > list_add(&match->list, &kvm->arch.assigned_dev_head);
> >
> > + /* currenlty iommu is required for handling dma */
> > + r = kvm_iommu_map_guest(kvm, match);
> > + if (r)
> > + goto out_list_del;
> > +
>
> This will break pvdma support. Please check if intel-iommu is found and only
> then bail out of here.
>
> Even though pvdma is out-of-tree, it doesn't make sense to restrict our usage
> here. AMD IOMMU support will need this to be handled in the right way as
> well.
>
> > out:
> > mutex_unlock(&kvm->lock);
> > return r;
> > +out_list_del:
> > + list_del(&match->list);
> > + pci_release_regions(dev);
> > out_disable:
> > pci_disable_device(dev);
> > out_put:
> > @@ -4219,6 +4228,7 @@ static void kvm_free_vcpus(struct kvm *kvm)
> >
> > void kvm_arch_destroy_vm(struct kvm *kvm)
> > {
> > + kvm_iommu_unmap_guest(kvm);
>
> Likewise, check if intel-iommu is found as a first step in this function.
>
> As part of getting AMD-iommu and pvdma support in, we should have generic
> function names, but that can be done later.
>
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> > index a18aaad..b703890 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -285,6 +285,33 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v);
> > int kvm_cpu_has_pending_timer(struct kvm_vcpu *vcpu);
> > void kvm_vcpu_kick(struct kvm_vcpu *vcpu);
> >
> > +#ifdef CONFIG_DMAR
> > +int kvm_iommu_map_pages(struct kvm *kvm, gfn_t base_gfn,
> > + unsigne
RE: [PATCH] Make " make sync" get correct header files with latest Linux source.
Avi,
Please drop the previous one due to its incompleteness, and help to
check-in this one.
Xiantao
>From ae0e1b37520f6aba051b5ebb47028520383ca494 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Thu, 21 Aug 2008 17:30:32 +0800
Subject: [PATCH] KVM: Userspace: Make " make sync" get correct header
files with latest Linux source.
In latest linux repo, ia64, s390 and other archs moved header files from
$(LINUX)/include/asm-$(ARCH)/ to $(LINUX)/arch/$(ARCH)/include/asm/, so
this
patch adds the compatibility for new source structure.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
kernel/Makefile |5 -
kernel/ia64/Makefile.pre |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/Makefile b/kernel/Makefile
index e5f43a2..6f8cc9d 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -36,7 +36,7 @@ hack-files = $(hack-files-$(ARCH_DIR))
all:: header-link prerequisite
# include header priority 1) $LINUX 2) $KERNELDIR 3)
include-compat
$(MAKE) -C $(KERNELDIR) M=`pwd` \
- LINUXINCLUDE="-I`pwd`/include -Iinclude
-I`pwd`/include-compat \
+ LINUXINCLUDE="-I`pwd`/include -Iinclude
-Iarch/${ARCH_DIR}/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/$(ARCH_DIR)/external-module-compat.h"
"$$@"
@@ -56,6 +56,9 @@ header-sync:
"$(LINUX)"/./include/linux/kvm*.h \
"$(LINUX)"/./include/asm-*/kvm*.h \
$T/
+ -rsync -R \
+"$(LINUX)"/arch/$(ARCH_DIR)/include/asm/./kvm*.h \
+ $T/include/asm-$(ARCH_DIR)/
set -e && for i in $(find $T -name '*.h'); do \
$(call unifdef,$$i); done
diff --git a/kernel/ia64/Makefile.pre b/kernel/ia64/Makefile.pre
index 033bdee..c55ea0f 100644
--- a/kernel/ia64/Makefile.pre
+++ b/kernel/ia64/Makefile.pre
@@ -20,4 +20,4 @@ asm-offsets.h: asm-offsets.s
echo "#endif") <$< >$@
asm-offsets.s: ia64/asm-offsets.c
- gcc -S -D__KERNEL__ -I$(KERNELDIR)/include -I./include
ia64/asm-offsets.c
+ gcc -S -D__KERNEL__ -I$(KERNELDIR)/include
-I$(KERNELDIR)/arch/ia64/include -I./include ia64/asm-offsets.c
--
1.5.1
0001-KVM-Userspace-Make-make-sync-get-correct-header.patch
Description: 0001-KVM-Userspace-Make-make-sync-get-correct-header.patch
Re: [PATCH] kvm: qemu: Handle tap fds with IFF_VNET_HDR
On Wed, 2008-08-20 at 20:51 +0300, Avi Kivity wrote: > Anthony Liguori wrote: > > Mark McLoughlin wrote: > >> Allow users to pass an IFF_VNET_HDR tap fd via "-net tap,fd=X" > >> by querying the fd with the recently added TUNGETIFF ioctl() to > >> see if IFF_VNET_HDR has been enabled. > >> > >> Note: users wishing to pass an IFF_VNET_HDR tap fd to qemu > >> should check both that a) this version of qemu can handle > >> such an fd and b) that the TUNGETIFF ioctl() is available in > >> the running kernel. > >> > >> We add a comment to the "qemu -help" output to indicate to > >> users that this version of qemu supports IFF_VNET_HDR. > >> > > > > The -help output is not a supported interface. An info command in the > > monitor would be a better way to detect this. > > > > You need to know this before you create a virtual machine. I suggested > a 'qemu -capabilities' thing to describe what this qemu can do. I'll take a stab at "-capabilities" later. In the mean time, it may make sense to commit the patch minus the -help string. Cheers, Mark. -- 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
Issues while "Debugging Windows Kernel" running on KVM
Hi, I am facing issues while trying to debug Windows XP kernel running on top of Linux KVM. I have to debug Windows XP kernel running in a VM. I have dedicated ttyS0 on the host to the guest. I am using the following command to bring up Windows VM. /usr/local/kvm/bin/qemu-system-x86_64 \ -hda /opt/vdisk.img \ -boot c \ -m 512 \ -net nic,model=rtl8139,macaddr=52:54:00:12:34:56 \ -net tap,ifname=qtap0,script=no \ -smp 1 \ -usb \ -usbdevice tablet \ -localtime \ -serial /dev/ttyS0 I have another machine, running Windows XP, connected to the Linux host through serial cable. |Windows | | VM| |(target)| --- | Windows Host | - | Linux with KVM | --- I am able to send messages between Windows host and target through serial ports (tested using windows power shell). But, I am not able to use Win DBG (Kernel Debugger) in host to connect to target. Target is getting stuck while booting. Debug enabled Windows entry in boot.ini: multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /debugport=COM1 /baudrate=115200 Can someone please help me regarding this? Thanks, Bhaskar -- 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-73 release
On Thu, Aug 21, 2008 at 11:26:59AM +0800, Han, Weidong wrote: > I thought the patches would be merged into KVM mainline first. Avi, > is it possible? If not, we should send the patch to LKML soon. That was my understanding too from previous discussions. Cheers, Muli -- Workshop on I/O Virtualization (WIOV '08) Co-located with OSDI '08, Dec 2008, San Diego, CA http://www.usenix.org/wiov08 -- 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-73 release
On Thursday 21 August 2008 09:45:29 Yang, Sheng wrote: > On Thursday 21 August 2008 00:43:22 Muli Ben-Yehuda wrote: > > On Wed, Aug 20, 2008 at 06:04:26PM +0300, Avi Kivity wrote: > > > Other noteworthy changes: speedups of both virtio-net and qcow2 > > > with cache=off. Two important works-in-progress: device > > > assignment (not usable yet, as dma support is still missing) > > > and the real-mode emulation framework. > > > > Hi Avi, > > > > The latest version of the VT-d patches for device assignment was > > posted by Ben on Aug 7th[1][2]. There were no substantial review > > comments, so... what are we waiting for? > > > > [1] http://www.mail-archive.com/kvm@vger.kernel.org/msg02554.html > > [2] http://www.mail-archive.com/kvm@vger.kernel.org/msg02553.html > > Hi Muli > > The next step should be send the first patch to linux-pci(and CC > Jesse Barnes and other guys) to have review, for it related to DMAR > modification... I think we mentioned that in recent comments, and I > meant to remind Ben about that, but forgot it... Hi Ben I think you can CC Jesse Barnes, David Woodhouse([EMAIL PROTECTED], current VT-d maintainer) and Mark Gross(former VT-d maintainer). -- regards Yang, Sheng -- 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
