Re: [PATCH] KVM: Fix wrong KVM_GET_LAPIC
Yang, Sheng wrote: From a8ca7dd8f5fe0125e7b7d0a21f5caddacd754911 Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Mon, 18 Aug 2008 11:04:22 +0800 Subject: [PATCH] KVM: Fix wrong KVM_GET_LAPIC Which caused migration fail in recent commits. 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: [PATCH] kvm: qemu: Add missing DEPLIBS in Makefile.target
Yang, Sheng wrote: From 50a27ca42a565579e78e3545ca097a65a88cbadd Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Wed, 13 Aug 2008 11:35:17 +0800 Subject: [PATCH] kvm: qemu: Add missing DEPLIBS in Makefile.target Seems this flags is missing during merging long ago... And this result in updating of libkvm.a didn't affect make process of qemu, which is very puzzling... 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: Un-googlable
on Sat Aug 16 2008, Avi Kivity avi-AT-qumranet.com wrote: In many ways kvm is a horrible choice. I'm not sure a name change is possible at this stage, though. I've thought of 'slice' (which rhymes nicely with some Qumranet products, and so may not be the first choice for other kvm developers), but that may not be the googliest name either. No, and I can't claim to have come up with anything apt. Perhaps one day the distinction between kvm and linux will disappear, and the hypervisor will be known simply as 'Linux'. Thanks for a thoughtful answer, Avi. -- Dave Abrahams BoostPro Computing http://www.boostpro.com -- 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: Check for privileges before assigning irq
Amit Shah wrote: Even though we don't share irqs at the moment, we should ensure regular user processes don't try to allocate system resources. We check for capability to access IO devices (CAP_SYS_RAWIO) before we request_irq on behalf of the guest. 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: [PATCH] kvm: bios: end AP boot code execution in rombios
Yang, Sheng wrote: On Monday 18 August 2008 10:33:11 Anthony Liguori wrote: Sebastian Herbszt wrote: Jump to rombios before executing the halt loop. Why? More importantly, why is this specific to KVM? The bios copy AP boot up code to 0x1 now in KVM, so it can be overwrite by userspace program like grub. I found it caused stop/cont/info cpus in grub corrupt AP. Please refer to KVM: Fix exiting from HLT emulation with MP_STATE_HALTED (well, I found the patch duplicated with Marcelo's patch later, then drop it...) Yeah, I am agree this should not be a specific issue to KVM. It is actually kvm specific. The SIPI code runs with interrupts disabled, so the 'hlt' instruction cannot be resumed due to an interrupt (and as the apic hasn't been configured yet, no nmis either). But due to a bug in kvm, an exit to userspace (like the one caused by 'info cpus' or stop+cont) can cause kvm to resume executing after the hlt instruction, which is now arbitrary application code. Marcelo has a patch that addresses this, unfortunately with a regression, so hopefully the kvm bug will be closed soon. That's not to say running out of ROM space is a bad idea, so I'll apply this. (would be even better not to copy the code at all) -- 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: bios: end AP boot code execution in rombios
Sebastian Herbszt wrote: Jump to rombios before executing the halt loop. Applied, thanks. .code16 smp_ap_boot_code_start: + cli Redundant (but no harm 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] KVM: SVM: Fix typo
Amit Shah wrote: Fix typo in as-yet unused macro definition. 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: Building and Installing everything but Modules...
Stuart Sheldon wrote: Another newbie question... I've looks all over the place, and just can't seem to figure this out. I want to build and install everything but the kernel modules from release source. This will allow me to test against the vanilla modules that come with the kernel source. Can anyone point me in the right direction here? The simplest way is to compile as usual, but when installing, do a 'sudo make -C qemu install'. This will install qemu but not the modules. -- 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] Work around dhclient brokenness
Anthony Liguori wrote: With the latest GSO/csum offload patches, any guest using an unpatched version of dhclient (any Ubuntu guest, for instance), will no longer be able to get a DHCP address. dhclient is actually at fault here. It uses AF_PACKET to receive DHCP responses but does not check auxdata to see if the packet has a valid csum. This causes it to throw out the DHCP responses it gets from the virtio interface as there is not a valid checksum. Fedora has carried a patch to fix their dhclient (it's needed for Xen too) but this patch has not made it into a release of dhclient. AFAIK, the patch is in the dhclient CVS but I cannot confirm since their CVS is not public. This patch, suggested by Rusty, looks for UDP packets (of a normal MTU) and explicitly adds a checksum to them if they are missing one. We could further refine the search criteria based on srcport but that's probably unnecessary. Won't this slow down nfs/udp? I think a srcport check would be good here. -- 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] KVM: x86: Use kvm_set_irq to inject interrupts
From: Amit Shah [EMAIL PROTECTED]
... instead of using the pic and ioapic variants
Signed-off-by: Amit Shah [EMAIL PROTECTED]
---
arch/x86/kvm/i8254.c |6 ++
arch/x86/kvm/x86.c |8 +---
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 7d04dd3..c43894f 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -596,10 +596,8 @@ void kvm_free_pit(struct kvm *kvm)
static void __inject_pit_timer_intr(struct kvm *kvm)
{
mutex_lock(kvm-lock);
- kvm_ioapic_set_irq(kvm-arch.vioapic, 0, 1);
- kvm_ioapic_set_irq(kvm-arch.vioapic, 0, 0);
- kvm_pic_set_irq(pic_irqchip(kvm), 0, 1);
- kvm_pic_set_irq(pic_irqchip(kvm), 0, 0);
+ kvm_set_irq(kvm, 0, 1);
+ kvm_set_irq(kvm, 0, 0);
mutex_unlock(kvm-lock);
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ee005a6..4933f0c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1951,13 +1951,7 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
if (irqchip_in_kernel(kvm)) {
mutex_lock(kvm-lock);
- if (irq_event.irq 16)
- kvm_pic_set_irq(pic_irqchip(kvm),
- irq_event.irq,
- irq_event.level);
- kvm_ioapic_set_irq(kvm-arch.vioapic,
- irq_event.irq,
- irq_event.level);
+ kvm_set_irq(kvm, irq_event.irq, irq_event.level);
mutex_unlock(kvm-lock);
r = 0;
}
--
1.5.4.3
--
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] Work around dhclient brokenness
Herbert Xu wrote: On Mon, Aug 18, 2008 at 02:06:46PM +0300, Avi Kivity wrote: I still think that having the guests tell us that they can handle it is the safest and most efficient way to proceed. I thought this is a userspace problem? Can we fix this in the guest kernel? Right, I meant that it's best to have the guest's user-space tell us that it can handle checksum offload through ethtool via virtio. Isn't that turned on automatically for real hardware? And what's to prevent a broken dhclient together with the (presumably) hacked up initscripts that call ethtool? -- 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] Work around dhclient brokenness
On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote:
Isn't that turned on automatically for real hardware? And what's to
prevent a broken dhclient together with the (presumably) hacked up
initscripts that call ethtool?
Well the idea is that only a fixed guest would even know about
enabling this.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: x86: Use kvm_set_irq to inject interrupts
Amit Shah wrote: ... instead of using the pic and ioapic variants 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: [PATCH] userspace: Remove some unused variables
Jan Kiszka wrote: There are more warnings, but one after the other. This patch addresses all current warnings regarding unused variables in KVM userspace. Applied (as well as the next patch), 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: [PATCH] KVM: x86: Use kvm_set_irq to inject interrupts
* On Monday 18 Aug 2008 17:08:20 Avi Kivity wrote: Configuration problem? Strange! Maybe the server I sent it from did something bad; I had sent another patch just some time ago and that didn't get mangled. Avi Kivity doesn't think he wrote: From: Amit Shah [EMAIL PROTECTED] ... instead of using the pic and ioapic variants Signed-off-by: Amit Shah [EMAIL PROTECTED] -- 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
where can i find the current pci passthrough patches
Hi, i want to make some test with qemu and pci passthrough with the VT-d feature. In the linux-kernel git (http://git.kernel.org/; linux/kernel/git/amit/kvm-userspace.git) repository i only found a 6 weeks old version. How can i get the latest version? Where are the patches for the current KVM-72/GIT-Version. My PC is a Dell OPTIPLEX 755 with Hardwaresupport for VT-d as an BIOS Feature. I hope, i can get some help in this mailinglist. Regards, Gregor -- 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: where can i find the current pci passthrough patches
Hello, * On Monday 18 Aug 2008 18:28:07 [EMAIL PROTECTED] wrote: Hi, i want to make some test with qemu and pci passthrough with the VT-d feature. In the linux-kernel git (http://git.kernel.org/; linux/kernel/git/amit/kvm-userspace.git) repository i only found a 6 weeks old version. How can i get the latest version? Where are the patches for the current KVM-72/GIT-Version. My PC is a Dell OPTIPLEX 755 with Hardwaresupport for VT-d as an BIOS Feature. The basic pci-passthrough patches have been merged in Avi's tree. The VT-d patches are yet to be merged as is the userspace patch. Nevertheless, if you want to try out the VT-d functionality, the tree that you refer to above will continue to work. Amit. -- 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 0/8] Various USB fixes and improvements (update 2)
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. Regards, Anthony Liguori Max Krasnyansky wrote: This is an updated version of the USB patches I sent out yesterday. It includes changes and fixes suggested by Anthony. This time I also did more testing with XP running on top of QEMU/KQEMU (used to be QEMU/KVM). Max Krasnyansky (8): husb: support for USB host device auto disconnect. husb: support for USB host device auto connect. usb: generic packet handler cleanup and documentation uhci: rewrite UHCI emulator, fully async operation with multiple outstanding transactions husb: rewrite Linux host USB layer, fully async operation husb: remove disconnect detection timer husb: fixup printfs and stuff based on the review comments uhci: fixes for save/load-vm hw/usb-uhci.c | 905 ++--- hw/usb.c | 265 + hw/usb.h | 37 +++- usb-linux.c | 645 +++- vl.c | 83 +++--- 5 files changed, 1138 insertions(+), 797 deletions(-) Here is the original description. This patch series started when I tried to share USB ports between four instances of Windows XP running on the same Linux box (under KVM). I quickly realized that current USB support is not very flexible. We do not handle devices disconnects, there is not way to assign certain USB ports to VM instance, etc. Once I fixed that I discovered that USB devices that I absolutely need in the VMs (Xilinx and Altera USB dongles) do not really work with QEMU. VMs were getting stuck, applications unhappy, etc. So I endded up rewriting UHCI and Linux host USB layers to make them fully async and to support multiple outstanding transactions. The result is quite nice. We can now assign USB buses to VM instances and devices are automatically connected to the VMs. Just do usb_add host:N.* in the console or -usbdevice command line option (N is the bus number). Also when device is disconnected from the host it's automatically removed from the guest. Host USB devices operate in fully async mode (except the control transfers). All the stalls and jerkiness due to long synchronous transactions is gone. I can easily hook up four different USB devices (mouse, CF card reader, phone, Xilinx dongle) and everything is working perfectly. Mouse movements are silky smooth :). I did some profiling with OProfile and we seems to be doing ok while XP is pumping ~10 MBytes over USB (reported by one of the apps I'm using). UHCI stuff is well below VNC for example. There is more work to be done (async control transfers for example). But I think this is way better than what we have now and is ready for more testing by wider audience. Most of the testing so far was done with KVM flavor of QEMU. I did test generic i386-softmmu target a bit, it's too slow for any serious testing with XP. I did full compile (all targets) too and it went fine. -- 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: Balloon device in qemu?
Avi Kivity wrote: Andrea Arcangeli wrote: I'm more worried about the fact that with Anthony's plan ballooning will be unusable for a long while on enterprise distros, as it will take a while before they run on a =2.6.27 kernel. So I wonder if a compact layer is worth it. But surely initially we can modify KVM_CAP_SYNC_MMU to not be set if kernel isn't compiled with CONFIG_MMU_NOTIFIER=y and we can add the compact layer later if needed. I added something to hack-module.awk, so KVM_CAP_SYNC_MMU is now reliable. Great, I'll update the balloon backend and resubmit this afternoon. 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: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect.
Max Krasnyansky wrote: Guido Günther wrote: What about /dev/bus/usb - it supports inotify fine on udev? Yes it should since it's a regular filesystem. I was thinking of this too since /proc/bus/usb is deprecated in favor of /dev/bus/usb. If someone was willing to port QEMU to /dev/bus/usb, it would be greatly appreciated! Regards, Anthony Liguori Now inotify based solution probably won't be pretty because we'd have to monitor each subdir. ie When new device get added top level /dev/bus/usb is not modified, what does get modified is /dev/bus/usb/bus_num/ directory so we'd have to monitor /dev/bus/usb and dynamically register/unregister monitors for each /dev/bus/usb/bus_num/. Maybe it won't be that bad. If I get a chance I'll give it a shot. btw Interface to HAL might still be useful in general to monitor other device classes that we may want to automatically assign to the VMs. So I'll play around with that too (some day :)). Max -- 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: [Qemu-devel] Re: [PATCH 0/8] Various USB fixes and improvements (update 2)
Anthony Liguori writes ([Qemu-devel] Re: [PATCH 0/8] Various USB fixes and improvements (update 2)): 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 haven't reviewed the code but based on the descriptions I'm keen to see this committed. Ian. -- 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] userspace: update .gitignore
/kernel subdir layout changed recently. Update gitignore to reflect this. Signed-off-by: Jan Kiszka [EMAIL PROTECTED] --- diff --git a/.gitignore b/.gitignore index 7422760..bb35cca 100644 --- a/.gitignore +++ b/.gitignore @@ -15,19 +15,6 @@ qemu/qemu-img qemu/qemu-nbd *.ko *.mod.c -kernel/kvm_main.c -kernel/kvm.h -kernel/kvm_svm.h -kernel/vmx.[ch] -kernel/svm.[ch] -kernel/mmu.c -kernel/paging_tmpl.h -kernel/segment_descriptor.h -kernel/x86_emulate.[ch] -kernel/include/linux/kvm*.h -kernel/Module.symvers -kernel/Modules.symvers -kernel/.tmp_versions bios/*.bin bios/*.sym bios/*.txt @@ -37,23 +24,32 @@ vgabios/*.txt extboot/extboot.bin extboot/extboot.img extboot/signrom +kernel/modules.order +kernel/Module.symvers +kernel/Modules.symvers kernel/Module.markers -kernel/i825[49].[ch] +kernel/.tmp_versions kernel/include-compat/asm kernel/include-compat/asm-x86/asm-x86 kernel/include -kernel/ioapic.[ch] -kernel/iodev.h -kernel/irq.[ch] -kernel/kvm_trace.c -kernel/lapic.[ch] -kernel/mmu.h -kernel/modules.order -kernel/tss.h -kernel/x86.[ch] -kernel/coalesced_mmio.c -kernel/coalesced_mmio.h -kernel/kvm_cache_regs.h +kernel/x86/modules.order +kernel/x86/i825[49].[ch] +kernel/x86/kvm_main.c +kernel/x86/kvm_svm.h +kernel/x86/vmx.[ch] +kernel/x86/svm.[ch] +kernel/x86/mmu.[ch] +kernel/x86/paging_tmpl.h +kernel/x86/x86_emulate.[ch] +kernel/x86/ioapic.[ch] +kernel/x86/iodev.h +kernel/x86/irq.[ch] +kernel/x86/kvm_trace.c +kernel/x86/lapic.[ch] +kernel/x86/tss.h +kernel/x86/x86.[ch] +kernel/x86/coalesced_mmio.[ch] +kernel/x86/kvm_cache_regs.h qemu/pc-bios/extboot.bin qemu/qemu-doc.html qemu/*.[18] -- 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: Un-googlable
On Saturday 16 August 2008 06:45:55 pm David Abrahams wrote: on Sat Aug 16 2008, Glauber Costa glommer-AT-gmail.com wrote: Really, everyone types out that long phrase when asking questions? No, I type kernel kvm or do kvm -switch to remove pages that talk about KVM switches. I have also thought the name to be unfortunate, but you just need to ask Google a better question. -- 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: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect.
Anthony Liguori wrote: Max Krasnyansky wrote: Guido Günther wrote: What about /dev/bus/usb - it supports inotify fine on udev? Yes it should since it's a regular filesystem. I was thinking of this too since /proc/bus/usb is deprecated in favor of /dev/bus/usb. If someone was willing to port QEMU to /dev/bus/usb, it would be greatly appreciated! Sure. It's a one liner. I have one more patch for UHCI and a couple for usb-linux. I'll include this as well. Max -- 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: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect.
Javier Guerra wrote: On Fri, Aug 15, 2008 at 1:24 PM, Max Krasnyansky [EMAIL PROTECTED] wrote: btw Interface to HAL might still be useful in general to monitor other device classes that we may want to automatically assign to the VMs. So I'll play around with that too (some day :)). what about doing it the other way around? that is, setting udev scripts that notify KVM of the hardware changes. That seems a bit odd. What if you have more than one QEMU instance and stuff. Max -- 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: [Qemu-devel] [PATCH 5/5] husb: rewrite Linux host USB layer, fully async operation
Paul Brook wrote: Given that OHCI is much more complex than UHCI (both the code and the spec) I decided to give up on OHCI, at least for now. I noticed Codesourcery copyright on OHCI. Did you have anything to do with the OHCI implementation? Yes, I wrote the current OHCI support, based on some initial patches by Gianni. Great. So do you have spare cycles to add decent async support to it ? I found OHCI to be much easier to deal with than than UHCI. The low-level bits of the USB protocol are fairly nasty. UHCI is a cheap and nasty host solution, which directly exposes (and requires faking of) all the nasty low level details and timing. OHCI is a higher level interface which I found makes it much easier to actually implement things sanely in a virtual environment. Four days ago :) I would've completely agreed with you. But once I figured out a ridiculously simple way to match outstanding transactions against current QHs and TDs (ED/TD in the OHCI terms) I changed my opinion. I mean in general OHCI does seem better. But cheap does not necessarily mean bad. In this case it means _simple_. Last Friday I made asynchronous ISOC transactions work reliably and both UHCI and usb-linux code is very generic and does not need any special logic for isoc which is nice. Unless I'm missing something OCHI also exposes USB frame timing when it comes to ISOC and interrupt transactions, and is fairly similar to UHCI in that regard. btw With the new UHCI code there is really no need to fake any USB timing in the UHCI. I simply match transactions by tokens (which encodes addr/endpoit/size/etc) and use QH/TD structure just to determine how the frame is composed. Yes there is per frame timer, but all it does it just updates pending transactions and submits new ones. OHCI also needs a timer to handle ISOC transactions. So overall I think UHCI is totally usable and sane now. And what I like the most is that it's very simple. It's almost 2:1 ratio, code size wise, with OHCI vs UHCI once I added support for multiple async transactions to both (like I did not finish OHCI). So we'd definitely need to work on OHCI if it's important for some platforms. I consider OHCI to be important. x86 is abut the only target foolish enough to use UHCI. I think we need both for ultimate compatibility. We also need EHCI otherwise XP keeps telling me dude, you plugged device XYZ into the wrong port :). Max -- 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: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect.
On Mon, Aug 18, 2008 at 1:21 PM, Max Krasnyansky [EMAIL PROTECTED] wrote: Javier Guerra wrote: what about doing it the other way around? that is, setting udev scripts that notify KVM of the hardware changes. That seems a bit odd. What if you have more than one QEMU instance and stuff. there has to be some policy in place to redirect USB devices to each QEMU instance, maybe at startup it could reserve a node in the USB device tree (an USB controller, or maybe a port in a hub). when invoked by udev, some script would consult those reservations and pick the appropriate QEMU yep, it's not trivial, but seems doable with scripts (and a small DB, or maybe a clever filesystem arrangement). -- Javier -- 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: [Qemu-devel] Re: [PATCH 2/5] husb: support for USB host device auto connect.
Javier Guerra wrote: there has to be some policy in place to redirect USB devices to each QEMU instance, maybe at startup it could reserve a node in the USB device tree (an USB controller, or maybe a port in a hub). when invoked by udev, some script would consult those reservations and pick the appropriate QEMU yep, it's not trivial, but seems doable with scripts (and a small DB, or maybe a clever filesystem arrangement). I think that's more or less how udev is *supposed* to be used. It's weird for a bit, then it makes sense. Especially as it can integrate nicely with distro scripts, e.g. for networking. But HAL and PolicyKit etc. turn it all on its head and you soon get lost in a twisty maze of configuration files. -- Jamie -- 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 0/8] Various USB fixes and improvements (update 2)
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. Max Regards, Anthony Liguori Max Krasnyansky wrote: This is an updated version of the USB patches I sent out yesterday. It includes changes and fixes suggested by Anthony. This time I also did more testing with XP running on top of QEMU/KQEMU (used to be QEMU/KVM). Max Krasnyansky (8): husb: support for USB host device auto disconnect. husb: support for USB host device auto connect. usb: generic packet handler cleanup and documentation uhci: rewrite UHCI emulator, fully async operation with multiple outstanding transactions husb: rewrite Linux host USB layer, fully async operation husb: remove disconnect detection timer husb: fixup printfs and stuff based on the review comments uhci: fixes for save/load-vm hw/usb-uhci.c | 905 ++--- hw/usb.c | 265 + hw/usb.h | 37 +++- usb-linux.c | 645 +++- vl.c | 83 +++--- 5 files changed, 1138 insertions(+), 797 deletions(-) Here is the original description. This patch series started when I tried to share USB ports between four instances of Windows XP running on the same Linux box (under KVM). I quickly realized that current USB support is not very flexible. We do not handle devices disconnects, there is not way to assign certain USB ports to VM instance, etc. Once I fixed that I discovered that USB devices that I absolutely need in the VMs (Xilinx and Altera USB dongles) do not really work with QEMU. VMs were getting stuck, applications unhappy, etc. So I endded up rewriting UHCI and Linux host USB layers to make them fully async and to support multiple outstanding transactions. The result is quite nice. We can now assign USB buses to VM instances and devices are automatically connected to the VMs. Just do usb_add host:N.* in the console or -usbdevice command line option (N is the bus number). Also when device is disconnected from the host it's automatically removed from the guest. Host USB devices operate in fully async mode (except the control transfers). All the stalls and jerkiness due to long synchronous transactions is gone. I can easily hook up four different USB devices (mouse, CF card reader, phone, Xilinx dongle) and everything is working perfectly. Mouse movements are silky smooth :). I did some profiling with OProfile and we seems to be doing ok while XP is pumping ~10 MBytes over USB (reported by one of the apps I'm using). UHCI stuff is well below VNC for example. There is more work to be done (async control transfers for example). But I think this is way better than what we have now and is ready for more testing by wider audience. Most of the testing so far was done with KVM flavor of QEMU. I did test generic i386-softmmu target a bit, it's too slow for any serious testing with XP. I did full compile (all targets) too and it went fine. -- 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][RESEND] x86 emulator: Add in/out instructions (opcodes 0xe4-0xe7, 0xec-0xef)
The patch adds in/out instructions to the x86 emulator.
The instruction was encountered while running the BIOS while using
the invalid guest state emulation patch.
Signed-off-by: Mohammed Gamal [EMAIL PROTECTED]
---
arch/x86/kvm/x86_emulate.c | 35 +--
1 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86_emulate.c b/arch/x86/kvm/x86_emulate.c
index 005f1db..dfc1090 100644
--- a/arch/x86/kvm/x86_emulate.c
+++ b/arch/x86/kvm/x86_emulate.c
@@ -170,11 +170,14 @@ static u16 opcode_table[256] = {
/* 0xD8 - 0xDF */
0, 0, 0, 0, 0, 0, 0, 0,
/* 0xE0 - 0xE7 */
- 0, 0, 0, 0, 0, 0, 0, 0,
+ 0, 0, 0, 0,
+ SrcNone | ByteOp | ImplicitOps, SrcNone | ImplicitOps,
+ SrcNone | ByteOp | ImplicitOps, SrcNone | ImplicitOps,
/* 0xE8 - 0xEF */
ImplicitOps | Stack, SrcImm | ImplicitOps,
ImplicitOps, SrcImmByte | ImplicitOps,
- 0, 0, 0, 0,
+ SrcNone | ByteOp | ImplicitOps, SrcNone | ImplicitOps,
+ SrcNone | ByteOp | ImplicitOps, SrcNone | ImplicitOps,
/* 0xF0 - 0xF7 */
0, 0, 0, 0,
ImplicitOps, ImplicitOps, Group | Group3_Byte, Group | Group3,
@@ -1252,6 +1255,8 @@ x86_emulate_insn(struct x86_emulate_ctxt *ctxt, struct
x86_emulate_ops *ops)
u64 msr_data;
unsigned long saved_eip = 0;
struct decode_cache *c = ctxt-decode;
+ unsigned int port;
+ int io_direction;
int rc = 0;
/* Shadow copy of register state. Committed on successful emulation.
@@ -1680,6 +1685,16 @@ special_insn:
c-src.val = c-regs[VCPU_REGS_RCX];
emulate_grp2(ctxt);
break;
+ case 0xe4: /* inb */
+ case 0xe5: /* in */
+ port = insn_fetch(u8, 1, c-eip);
+ io_direction = 1;
+ goto do_io;
+ case 0xe6: /* outb */
+ case 0xe7: /* out */
+ port = insn_fetch(u8, 1, c-eip);
+ io_direction = 0;
+ goto do_io;
case 0xe8: /* call (near) */ {
long int rel;
switch (c-op_bytes) {
@@ -1730,6 +1745,22 @@ special_insn:
jmp_rel(c, c-src.val);
c-dst.type = OP_NONE; /* Disable writeback. */
break;
+ case 0xec: /* in al,dx */
+ case 0xed: /* in (e/r)ax,dx */
+ port = c-regs[VCPU_REGS_RDX];
+ io_direction = 1;
+ goto do_io;
+ case 0xee: /* out al,dx */
+ case 0xef: /* out (e/r)ax,dx */
+ port = c-regs[VCPU_REGS_RDX];
+ io_direction = 0;
+ do_io: if (kvm_emulate_pio(ctxt-vcpu, NULL, io_direction,
+ (c-d ByteOp) ? 1 : c-op_bytes,
+ port) != 0) {
+ c-eip = saved_eip;
+ goto cannot_emulate;
+ }
+ return 0;
case 0xf4: /* hlt */
ctxt-vcpu-arch.halt_request = 1;
break;
--
1.5.4.3
--
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] Work around dhclient brokenness
On Monday 18 August 2008 21:44:25 Herbert Xu wrote: On Mon, Aug 18, 2008 at 02:40:55PM +0300, Avi Kivity wrote: Isn't that turned on automatically for real hardware? And what's to prevent a broken dhclient together with the (presumably) hacked up initscripts that call ethtool? Well the idea is that only a fixed guest would even know about enabling this. For those not following closely: We already have a method for the guest to accept or reject features. Our problem is that the guest is already accepting the CSUM feature: but one critical userspace app (dhcp-client) can't actually handle it due to a bug. The proposal is to add another mechanism, whereby the host doesn't advertise CSUM, but advertises a new CSUM2 feature. The driver doesn't accept this by default: then guest userspace says hey, I *really can* handle CSUM. This would have to be done dby resetting the device in the ethtool callback (that's how we renegotiate features). And guests need a special virtio hack in their init scripts. This leaves the small number of current users without CSUM (and hence GSO etc). Yet they might not use dhcp with bridging anyway. Worst of all, we have to document this embarrassing workaround. Neither solution is good. But I don't think Anthony's hack looks so bad after this. Rusty. -- 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] Work around dhclient brokenness
On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote: For those not following closely: We already have a method for the guest to accept or reject features. Our problem is that the guest is already accepting the CSUM feature: but one critical userspace app (dhcp-client) can't actually handle it due to a bug. Can't we just get dhcp-client client fixed upstream and let the distro's update in a couple of months? The proposal is to add another mechanism, whereby the host doesn't advertise CSUM, but advertises a new CSUM2 feature. The driver doesn't accept this by default: then guest userspace says hey, I *really can* handle CSUM. This would have to be done dby resetting the device in the ethtool callback (that's how we renegotiate features). And guests need a special virtio hack in their init scripts. If guest can have modified scripts for virtio and what not, they can have a fixed dhcp-client. This leaves the small number of current users without CSUM (and hence GSO etc). Yet they might not use dhcp with bridging anyway. I think for now that's fine, it's a performance hit that people can tweak away explicitly without having to add something like a CSUM2 feature. -- 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] Work around dhclient brokenness
On Tuesday 19 August 2008 13:17:57 Chris Wedgwood wrote: On Tue, Aug 19, 2008 at 10:45:20AM +1000, Rusty Russell wrote: For those not following closely: We already have a method for the guest to accept or reject features. Our problem is that the guest is already accepting the CSUM feature: but one critical userspace app (dhcp-client) can't actually handle it due to a bug. Can't we just get dhcp-client client fixed upstream and let the distro's update in a couple of months? Herbert has already fixed the client, but it seems upstream hasn't released yet. The proposal is to add another mechanism, whereby the host doesn't advertise CSUM, but advertises a new CSUM2 feature. The driver doesn't accept this by default: then guest userspace says hey, I *really can* handle CSUM. This would have to be done dby resetting the device in the ethtool callback (that's how we renegotiate features). And guests need a special virtio hack in their init scripts. If guest can have modified scripts for virtio and what not, they can have a fixed dhcp-client. They need to do both. This way if they don't, it still works, but networking is at a penalty (no CSUM offload). Rusty. -- 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] Work around dhclient brokenness
On Tue, Aug 19, 2008 at 02:41:01PM +1000, Rusty Russell wrote: They need to do both. This way if they don't, it still works, but networking is at a penalty (no CSUM offload). CSUM2 sounds so ugly though. Features seem to get added and never removed how about if this had a documented short lifetime (if it really must go in)? -- 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] Work around dhclient brokenness
On Mon, Aug 18, 2008 at 10:13:55PM -0700, Chris Wedgwood wrote:
CSUM2 sounds so ugly though. Features seem to get added and never
removed how about if this had a documented short lifetime (if it
really must go in)?
All we need is a simple toggle to disable checksum offload. Every
NIC that offers receive checksum offload allows it to be disabled.
virtio shouldn't be any different.
Resetting the NIC seems a bit over the top.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] Work around dhclient brokenness
On Tue, Aug 19, 2008 at 03:17:08PM +1000, Herbert Xu wrote: All we need is a simple toggle to disable checksum offload. Every NIC that offers receive checksum offload allows it to be disabled. virtio shouldn't be any different. So why CSUM2 and not an ethtool interface then? -- 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
