Re: [PATCH 15/15] KVM: Fix racy in kvm_free_assigned_irq
On Friday 02 January 2009 08:10:37 Marcelo Tosatti wrote: > On Wed, Dec 31, 2008 at 01:43:54PM +0800, Sheng Yang wrote: > > On Wednesday 31 December 2008 00:45:51 Marcelo Tosatti wrote: > > > On Tue, Dec 30, 2008 at 10:14:09AM +0800, Sheng Yang wrote: > > > > > There is one remaining issue: > > > > > kvm_assigned_dev_interrupt_work_handler can re-enable the interrupt > > > > > for KVM_ASSIGNED_DEV_GUEST_MSI case. Perhaps you need a new flag to > > > > > indicate shutdown (so the host IRQ won't be reenabled). > > > > > > > > Is it already covered by disable_irq_no_sync() before > > > > cancel_work_sync()? I've noted this in my comment: the irq may be > > > > disabled nested(once for MSI and twice for INTx), but I think it's > > > > fine for we're going to free it. > > > > > > The problem is that the irq can be re-enabled in > > > kvm_assigned_dev_interrupt_work_handler: > > > > > > > > > context 1 |context 2 > > > > > > disable_irq_nosync > > > kvm_assigned_dev_interrupt_work_handler > > > enable_irq > > > cancel_work_sync > > > > > > free_irq > > > > Um... My understanding is a little different... > > > > Before context1 execute disable_irq_nosync(), in irq handler, > > disable_irq_nosync() would also been executed. So only one enable_irq() > > is not really enable irq here, which can cover the window at all. That's > > what I means nested disable irq... > > You're right. There have been two disable_irq calls. > > OK, looks good to me. So Avi, can you check in the patchset? Thanks. -- regards Yang, Sheng -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] KVM: Interrupt mask notifiers for ioapic
On Monday 05 January 2009 00:14:44 Avi Kivity wrote:
> Allow clients to request notifications when the guest masks or unmasks a
> particular irq line. This complements irq ack notifications, as the guest
> will not ack an irq line that is masked.
>
> Currently implemented for the ioapic only.
Hi Avi
Need a lock for this list? Seems kvm_fire_mask_notifiers() implicit holding
kvm->lock, but register/unregister didn't. And I think we need some comments
for the necessary of lock.
--
regards
Yang, Sheng
>
> Signed-off-by: Avi Kivity
> ---
> include/linux/kvm_host.h | 17 +
> virt/kvm/ioapic.c|7 ++-
> virt/kvm/irq_comm.c | 24
> virt/kvm/kvm_main.c |3 +++
> 4 files changed, 50 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 545a133..43385fa 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -127,6 +127,10 @@ struct kvm {
> struct kvm_coalesced_mmio_ring *coalesced_mmio_ring;
> #endif
>
> +#ifdef CONFIG_HAVE_KVM_IRQCHIP
> + struct hlist_head mask_notifier_list;
> +#endif
> +
> #ifdef KVM_ARCH_WANT_MMU_NOTIFIER
> struct mmu_notifier mmu_notifier;
> unsigned long mmu_notifier_seq;
> @@ -320,6 +324,19 @@ struct kvm_assigned_dev_kernel {
> struct pci_dev *dev;
> struct kvm *kvm;
> };
> +
> +struct kvm_irq_mask_notifier {
> + void (*func)(struct kvm_irq_mask_notifier *kimn, int masked);
> + int irq;
> + struct hlist_node link;
> +};
> +
> +void kvm_register_irq_mask_notifier(struct kvm *kvm, int irq,
> + struct kvm_irq_mask_notifier *kimn);
> +void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int irq,
> + struct kvm_irq_mask_notifier *kimn);
> +void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, int mask);
> +
> void kvm_set_irq(struct kvm *kvm, int irq_source_id, int irq, int level);
> void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi);
> void kvm_register_irq_ack_notifier(struct kvm *kvm,
> diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
> index 23b81cf..15b9ddd 100644
> --- a/virt/kvm/ioapic.c
> +++ b/virt/kvm/ioapic.c
> @@ -100,7 +100,7 @@ static void ioapic_service(struct kvm_ioapic *ioapic,
> unsigned int idx)
>
> static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val)
> {
> - unsigned index;
> + unsigned index, mask_before, mask_after;
>
> switch (ioapic->ioregsel) {
> case IOAPIC_REG_VERSION:
> @@ -120,6 +120,7 @@ static void ioapic_write_indirect(struct kvm_ioapic
> *ioapic, u32 val) ioapic_debug("change redir index %x val %x\n", index,
> val);
> if (index >= IOAPIC_NUM_PINS)
> return;
> + mask_before = ioapic->redirtbl[index].fields.mask;
> if (ioapic->ioregsel & 1) {
> ioapic->redirtbl[index].bits &= 0x;
> ioapic->redirtbl[index].bits |= (u64) val << 32;
> @@ -128,6 +129,9 @@ static void ioapic_write_indirect(struct kvm_ioapic
> *ioapic, u32 val) ioapic->redirtbl[index].bits |= (u32) val;
> ioapic->redirtbl[index].fields.remote_irr = 0;
> }
> + mask_after = ioapic->redirtbl[index].fields.mask;
> + if (mask_before != mask_after)
> + kvm_fire_mask_notifiers(ioapic->kvm, index, mask_after);
> if (ioapic->irr & (1 << index))
> ioapic_service(ioapic, index);
> break;
> @@ -426,3 +430,4 @@ int kvm_ioapic_init(struct kvm *kvm)
> kvm_io_bus_register_dev(&kvm->mmio_bus, &ioapic->dev);
> return 0;
> }
> +
> diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
> index aa5d1e5..2cbde68 100644
> --- a/virt/kvm/irq_comm.c
> +++ b/virt/kvm/irq_comm.c
> @@ -99,3 +99,27 @@ void kvm_free_irq_source_id(struct kvm *kvm, int
> irq_source_id) clear_bit(irq_source_id, &kvm->arch.irq_states[i]);
> clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
> }
> +
> +void kvm_register_irq_mask_notifier(struct kvm *kvm, int irq,
> + struct kvm_irq_mask_notifier *kimn)
> +{
> + kimn->irq = irq;
> + hlist_add_head(&kimn->link, &kvm->mask_notifier_list);
> +}
> +
> +void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int irq,
> + struct kvm_irq_mask_notifier *kimn)
> +{
> + hlist_del(&kimn->link);
> +}
> +
> +void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, int mask)
> +{
> + struct kvm_irq_mask_notifier *kimn;
> + struct hlist_node *n;
> +
> + hlist_for_each_entry(kimn, n, &kvm->mask_notifier_list, link)
> + if (kimn->irq == irq)
> + kimn->func(kimn, mask);
> +}
> +
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 5703557..dcd58d6 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
>
How to send keyboard signal to guest vm?
Hi, how do you send keyboard signal to guest vm? eg: ctrl+alt+del, ctrl+alt+back, ctrl+alt+f1 And which keyboard driver should i use on linux/bsd guest vm, i can not make the number pad work on linux/bsd guest vm, it work on winxp guest vm. Can anyone share your Xorg.conf configure file here? Thank you. I use ubuntu/amd64 2.6.27-11-generic kernel, and kvm 0.82 my cpu is: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2482759 ] Windows SCSI errors
Bugs item #2482759, was opened at 2009-01-02 13:03 Message generated for change (Comment added) made by ryan_harper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: Windows SCSI errors Initial Comment: When starting up a fresh install of Windows Server 2003 R2 x64, I get errors similar to the following... scsi-disk: Command: lun=0 tag=0x0 data=0x12 0x01 0x00 0x00 0xff 0x00 scsi-disk: Inquiry (len 255) scsi-disk: Inquiry EVPD[Supported pages] buffer size 255 scsi-disk: Read buf_len=7 scsi-disk: Read sector_count=0 scsi-disk: Command complete tag=0x0 status=0 sense=0 lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 While these errors are happening on boot, the animated bar continues to scroll. The errors continue for about a minute and then everything suddenly kicks into gear and the machine continues to boot. This also happens while trying to get partition information through the device properties in the device manager and through the disk management mmc snapin. I'm running kvm-82 on Debian Lenny AMD64. The disk is a 20GB virtual SCSI, raw format. Here's the command I'm using to run KVM. kvm -m 1024 -smp 2 -drive file=system.img,if=scsi,boot=on -localtime --vnc 127.0.0.1:0 &> ../win2k3x64.log -- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-04 20:11 Message: Yeah, it's worth keeping open so we at least track that it is an open issue. It is harmless AFAICT, so no plans to implement the eeprom interface unless it prevents functionality. We've got lots of other issues to fix in the scsi layer. -- Comment By: Ryan Bair (ryandbair) Date: 2009-01-04 20:05 Message: Thanks, as far as I can see this is the first time the bug has been reported on the tracker so I will keep this bug open. Are there any workarounds or a planned fixes for this issue? -- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-04 19:44 Message: lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 These are known error messages. Looks like the windows driver is poking at the serial eeprom interface for loading SSVID/SSID but that's not implemented, hence the error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2482759 ] Windows SCSI errors
Bugs item #2482759, was opened at 2009-01-02 14:03 Message generated for change (Comment added) made by ryandbair You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: Windows SCSI errors Initial Comment: When starting up a fresh install of Windows Server 2003 R2 x64, I get errors similar to the following... scsi-disk: Command: lun=0 tag=0x0 data=0x12 0x01 0x00 0x00 0xff 0x00 scsi-disk: Inquiry (len 255) scsi-disk: Inquiry EVPD[Supported pages] buffer size 255 scsi-disk: Read buf_len=7 scsi-disk: Read sector_count=0 scsi-disk: Command complete tag=0x0 status=0 sense=0 lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 While these errors are happening on boot, the animated bar continues to scroll. The errors continue for about a minute and then everything suddenly kicks into gear and the machine continues to boot. This also happens while trying to get partition information through the device properties in the device manager and through the disk management mmc snapin. I'm running kvm-82 on Debian Lenny AMD64. The disk is a 20GB virtual SCSI, raw format. Here's the command I'm using to run KVM. kvm -m 1024 -smp 2 -drive file=system.img,if=scsi,boot=on -localtime --vnc 127.0.0.1:0 &> ../win2k3x64.log -- >Comment By: Ryan Bair (ryandbair) Date: 2009-01-04 21:05 Message: Thanks, as far as I can see this is the first time the bug has been reported on the tracker so I will keep this bug open. Are there any workarounds or a planned fixes for this issue? -- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-04 20:44 Message: lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 These are known error messages. Looks like the windows driver is poking at the serial eeprom interface for loading SSVID/SSID but that's not implemented, hence the error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2482759 ] Windows SCSI errors
Bugs item #2482759, was opened at 2009-01-02 13:03 Message generated for change (Comment added) made by ryan_harper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryan Bair (ryandbair) Assigned to: Nobody/Anonymous (nobody) Summary: Windows SCSI errors Initial Comment: When starting up a fresh install of Windows Server 2003 R2 x64, I get errors similar to the following... scsi-disk: Command: lun=0 tag=0x0 data=0x12 0x01 0x00 0x00 0xff 0x00 scsi-disk: Inquiry (len 255) scsi-disk: Inquiry EVPD[Supported pages] buffer size 255 scsi-disk: Read buf_len=7 scsi-disk: Read sector_count=0 scsi-disk: Command complete tag=0x0 status=0 sense=0 lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 While these errors are happening on boot, the animated bar continues to scroll. The errors continue for about a minute and then everything suddenly kicks into gear and the machine continues to boot. This also happens while trying to get partition information through the device properties in the device manager and through the disk management mmc snapin. I'm running kvm-82 on Debian Lenny AMD64. The disk is a 20GB virtual SCSI, raw format. Here's the command I'm using to run KVM. kvm -m 1024 -smp 2 -drive file=system.img,if=scsi,boot=on -localtime --vnc 127.0.0.1:0 &> ../win2k3x64.log -- Comment By: Ryan Harper (ryan_harper) Date: 2009-01-04 19:44 Message: lsi_scsi: error: Unhandled writeb 0xff = 0x0 lsi_scsi: error: Unhandled writeb 0x100 = 0x0 lsi_scsi: error: Unhandled writeb 0x101 = 0x0 lsi_scsi: error: Unhandled writeb 0x102 = 0x0 These are known error messages. Looks like the windows driver is poking at the serial eeprom interface for loading SSVID/SSID but that's not implemented, hence the error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2482759&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor Write I/O Performance on KVM-79
On Sun, Jan 4, 2009 at 5:48 PM, Avi Kivity wrote: > Rodrigo Campos wrote: >>> >>> qcow2 will surely lead to miserable performance. raw files are better. >>> best is to use lvm. >>> >>> >> >> What do you mean with best is to use lvm ? >> You just say to use raw images on an lvm partition because you can >> easily resize it ? Or somehow images only use the used space of the >> raw file when used with lvm ? Or there's some trick to make it ? >> > > Using lvm directly (-drive file=/dev/vg/volume) is both most efficient and > most reliable, as there are only a small amount of layers involved. > However, you need to commit space in advance (you can grow your volume, but > that takes guest involvement and cannot be done online at the moment). > > Using a raw file over a filesystem will be slow since the host filesystem > will be exercised, and due to fragmentation. Raw files only occupy storage > as they are used, but they are difficult to manage compared to qcow2 files. > > Qcow2 files are most flexible, but the least performing. Ahhh. Thanks a lot for the explanation :) Rodrigo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mouse motion lags
nuit...@melchior.nuitari.net wrote: I've noticed that issue on guest load, no swapping. But even just moving the mouse around feels more laggy then under vmware. I've tried mine with just 1 guest cpu. What sort of guest load? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mouse motion lags
Hi everybody, I switched to KVM some time ago from vmware and VB. Everything works great but there are noticeable lags in mouse motion in comparison with other VMs. Is this a known issue? Are there any optimizations for that? KVM: 79 Distr: Ubuntu Intrepid & Jaunty Command line: QEMU_AUDIO_DRV=sdl; kvm -net nic -net user -soundhw es1370 -m 750 -smp 2 win.qcow Is this under guest or host load? Or just moving the mouse around? Is the host swapping by any chance? I've noticed that issue on guest load, no swapping. But even just moving the mouse around feels more laggy then under vmware. I've tried mine with just 1 guest cpu. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Leendert van Doorn wrote: With a switch, please. Default behaviour should be to virtualize. One way to implement it is to pass pci devfn -> BAR hints through the firmware interface. This way you can choose which BARs to place where, and where to allow the default placement. I'm already providing the hints, but you are proposing that the default behavior for the BIOS should be to allocate BARs and when given a flag it should try to preserve the host BAR mappings. I can do that. It's a general policy -- isolate the guest from the host wherever possible. In a few cases it isn't possible (time) and it really hurts. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. Not Windows drivers. Well, at least I have a fighting chance to change the ATI windows drivers :-) :-) -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [v2] KVM: PowerPC: Disarm old guest debug interface
On Sun, 2009-01-04 at 12:54 +0200, Avi Kivity wrote:
>
> This doesn't apply. What was it diffed against?
Hmm, looks like a slightly older tree. This should apply.
kvm: ppc: remove debug support broken by KVM debug rewrite
After the rewrite of KVM's debug support, this code doesn't even build any
more.
Signed-off-by: Hollis Blanchard
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 1c61876..dfdf13c 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -111,11 +111,6 @@ struct kvm_arch {
struct kvm_vcpu_arch {
u32 host_stack;
u32 host_pid;
- u32 host_dbcr0;
- u32 host_dbcr1;
- u32 host_dbcr2;
- u32 host_iac[4];
- u32 host_msr;
u64 fpr[32];
ulong gpr[32];
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index 6052779..2c6ee34 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -77,9 +77,6 @@ extern int kvmppc_core_vcpu_translate(struct kvm_vcpu *vcpu,
extern void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
extern void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu);
-
extern void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu);
extern int kvmppc_core_pending_dec(struct kvm_vcpu *vcpu);
extern void kvmppc_core_queue_program(struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 8383603..0cef809 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -28,72 +28,6 @@
#include "44x_tlb.h"
-/* Note: clearing MSR[DE] just means that the debug interrupt will not be
- * delivered *immediately*. Instead, it simply sets the appropriate DBSR bits.
- * If those DBSR bits are still set when MSR[DE] is re-enabled, the interrupt
- * will be delivered as an "imprecise debug event" (which is indicated by
- * DBSR[IDE].
- */
-static void kvm44x_disable_debug_interrupts(void)
-{
- mtmsr(mfmsr() & ~MSR_DE);
-}
-
-void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu)
-{
- kvm44x_disable_debug_interrupts();
-
- mtspr(SPRN_IAC1, vcpu->arch.host_iac[0]);
- mtspr(SPRN_IAC2, vcpu->arch.host_iac[1]);
- mtspr(SPRN_IAC3, vcpu->arch.host_iac[2]);
- mtspr(SPRN_IAC4, vcpu->arch.host_iac[3]);
- mtspr(SPRN_DBCR1, vcpu->arch.host_dbcr1);
- mtspr(SPRN_DBCR2, vcpu->arch.host_dbcr2);
- mtspr(SPRN_DBCR0, vcpu->arch.host_dbcr0);
- mtmsr(vcpu->arch.host_msr);
-}
-
-void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
-{
- struct kvm_guest_debug *dbg = &vcpu->guest_debug;
- u32 dbcr0 = 0;
-
- vcpu->arch.host_msr = mfmsr();
- kvm44x_disable_debug_interrupts();
-
- /* Save host debug register state. */
- vcpu->arch.host_iac[0] = mfspr(SPRN_IAC1);
- vcpu->arch.host_iac[1] = mfspr(SPRN_IAC2);
- vcpu->arch.host_iac[2] = mfspr(SPRN_IAC3);
- vcpu->arch.host_iac[3] = mfspr(SPRN_IAC4);
- vcpu->arch.host_dbcr0 = mfspr(SPRN_DBCR0);
- vcpu->arch.host_dbcr1 = mfspr(SPRN_DBCR1);
- vcpu->arch.host_dbcr2 = mfspr(SPRN_DBCR2);
-
- /* set registers up for guest */
-
- if (dbg->bp[0]) {
- mtspr(SPRN_IAC1, dbg->bp[0]);
- dbcr0 |= DBCR0_IAC1 | DBCR0_IDM;
- }
- if (dbg->bp[1]) {
- mtspr(SPRN_IAC2, dbg->bp[1]);
- dbcr0 |= DBCR0_IAC2 | DBCR0_IDM;
- }
- if (dbg->bp[2]) {
- mtspr(SPRN_IAC3, dbg->bp[2]);
- dbcr0 |= DBCR0_IAC3 | DBCR0_IDM;
- }
- if (dbg->bp[3]) {
- mtspr(SPRN_IAC4, dbg->bp[3]);
- dbcr0 |= DBCR0_IAC4 | DBCR0_IDM;
- }
-
- mtspr(SPRN_DBCR0, dbcr0);
- mtspr(SPRN_DBCR1, 0);
- mtspr(SPRN_DBCR2, 0);
-}
-
void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
kvmppc_44x_tlb_load(vcpu);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 13226f1..2100c27 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -217,41 +217,18 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
- if (vcpu->guest_debug.enabled)
- kvmppc_core_load_guest_debugstate(vcpu);
-
kvmppc_core_vcpu_load(vcpu, cpu);
}
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
{
- if (vcpu->guest_debug.enabled)
- kvmppc_core_load_host_debugstate(vcpu);
-
- /* Don't leave guest TLB entries resident when being de-scheduled. */
- /* XXX It would be nice to differentiate between heavyweight exit and
-* sched_out here, since we could avoid the TLB flush for heavyweight
-* exits. */
- _tlbil_all();
kvmppc_core_vcpu_put(vcpu);
}
int kvm_a
Re: Poor Write I/O Performance on KVM-79
Rodrigo Campos wrote: qcow2 will surely lead to miserable performance. raw files are better. best is to use lvm. What do you mean with best is to use lvm ? You just say to use raw images on an lvm partition because you can easily resize it ? Or somehow images only use the used space of the raw file when used with lvm ? Or there's some trick to make it ? Using lvm directly (-drive file=/dev/vg/volume) is both most efficient and most reliable, as there are only a small amount of layers involved. However, you need to commit space in advance (you can grow your volume, but that takes guest involvement and cannot be done online at the moment). Using a raw file over a filesystem will be slow since the host filesystem will be exercised, and due to fragmentation. Raw files only occupy storage as they are used, but they are difficult to manage compared to qcow2 files. Qcow2 files are most flexible, but the least performing. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor Write I/O Performance on KVM-79
Rodrigo, KVM can use Logical Volume as a field of bytes to store the back-end of the guest HDD. Doing this, the overhead of the partition format is avoided at host side and things should be faster. - Florent -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor Write I/O Performance on KVM-79
On Sun, Jan 4, 2009 at 11:24 AM, Avi Kivity wrote: > Alexander Atticus wrote: >> >> Hello! >> >> I have been experimenting with KVM and have been experiencing poor write >> I/O >> performance. I'm not sure whether I'm doing something wrong or if this is >> just the current state of things. >> >> While writing to the local array on the node running the guests I get >> about >> 200MB/s from dd (bs=1M count=1000) or about 90MB/s write performance from >> iozone (sequencial) when I write to a 2G file with a 16M record length. >> The >> node is an 8 disk system using 3ware in a RAID50 configuration. It has >> 8GB >> of RAM. >> >> The guests get much slower disk access. The guests are using file based >> backends (tried both qcow2 and raw) with virtio support. With no other >> activity on the machine, I get about 6 to 7MB/s write performance from >> iozone with the same test. Guests are running Debian lenny/sid with >> 2.6.26-1-686. >> > > qcow2 will surely lead to miserable performance. raw files are better. > best is to use lvm. > What do you mean with best is to use lvm ? You just say to use raw images on an lvm partition because you can easily resize it ? Or somehow images only use the used space of the raw file when used with lvm ? Or there's some trick to make it ? Thanks a lot, Rodrigo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
On Sun, Jan 04, 2009 at 07:28:50PM +0200, Avi Kivity wrote: > Leendert van Doorn wrote: >> Avi wrote: >>> This is worrying as it will cause us to diverge from upstream bochs bios. >> Yep. I'll create a less invasive patch. I've been looking at SEABIOS which >> seems a much better alternative but the GPLv3 license worries me, especially >> when you have proprietary guests that calls back into it. > Surely, the BIOS call interface is a GPL boundary, just like the Linux > syscall interface. Kevin, is that not the case? If it is a GPL > interface, can you add an explicit exception to make it clear? I would not want the SeaBIOS license to extend to an emulator that deploys SeaBIOS nor to any regular real-mode apps that call SeaBIOS handlers. I'd be happy to make this explicit. -Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Avi wrote: > Surely, the BIOS call interface is a GPL boundary, just like the Linux > syscall interface. Kevin, is that not the case? If it is a GPL > interface, can you add an explicit exception to make it clear? At IBM we had many discussions about what precisely constitutes a GPL boundary. Especially when you are examining internal BIOS data structures (which most kernels do when accessing the BIOS). In the end Legal advised us that LGPL was ok and GPL was not. This was all in the context of v2 so things may have changed with v3. I don't want this to turn into a GPL versus LGPL argument because I'm not a lawyer either. If the KVM project picks up SEABIOS I'm all for it because it is much cleaner and easier to maintain. >> Ensuring >> the same mappings was much cleaner. > With a switch, please. Default behaviour should be to virtualize. > > One way to implement it is to pass pci devfn -> BAR hints through the > firmware interface. This way you can choose which BARs to place where, > and where to allow the default placement. I'm already providing the hints, but you are proposing that the default behavior for the BIOS should be to allocate BARs and when given a flag it should try to preserve the host BAR mappings. I can do that. >> Of course, my goal is to run unmodified BIOS/drivers. You could always >> change the drivers. > > Not Windows drivers. Well, at least I have a fighting chance to change the ATI windows drivers :-) Leendert -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Avi Kivity wrote: Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? s/GPL interface/GPL boundary/. Must be clear on this lawyer talk. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Leendert van Doorn wrote: Avi wrote: This is worrying as it will cause us to diverge from upstream bochs bios. Yep. I'll create a less invasive patch. I've been looking at SEABIOS which seems a much better alternative but the GPLv3 license worries me, especially when you have proprietary guests that calls back into it. Surely, the BIOS call interface is a GPL boundary, just like the Linux syscall interface. Kevin, is that not the case? If it is a GPL interface, can you add an explicit exception to make it clear? Can you elaborate? Since we're running the card's bios again, won't it initialize correctly? The problem is that the device-assignment code doesn't update the cards BARs, it just emulates them and maps the guest BARs onto the correct host BARs. Unfortunately, the graphics card has undocumented interfaces for obtaining the memory regions (faster than a full PCI lookup) and they of course return the host mappings as opposed to the guest mappings. !...@#$%^. My first attempt was to implement a state machine that would emulate these interfaces and rewrite them but this got pretty ugly pretty fast. No doubt. And it wouldn't work for cards where we don't know about these interfaces, or where we directly assign the mmio regions that implement these interfaces. Ensuring the same mappings was much cleaner. With a switch, please. Default behaviour should be to virtualize. One way to implement it is to pass pci devfn -> BAR hints through the firmware interface. This way you can choose which BARs to place where, and where to allow the default placement. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. Not Windows drivers. I'll clean things up and resubmit. 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Avi wrote: >This is worrying as it will cause us to diverge from upstream bochs bios. Yep. I'll create a less invasive patch. I've been looking at SEABIOS which seems a much better alternative but the GPLv3 license worries me, especially when you have proprietary guests that calls back into it. >> #if BX_ROMBIOS32 >>call rombios32_init >> #else >> @@ -10665,7 +10661,12 @@ post_default_ints: >>call pcibios_init_iomem_bases >>call pcibios_init_irqs >> #endif //BX_PCIBIOS >> -#endif >> + mov cx, #0xc000 ;; init vga bios >> + mov ax, #0xc780 >> + call rom_scan >> +#endif //BX_ROMBIOS32 >> + >> + call _print_bios_banner > >If one assigns a graphics card, it should replace the cirrus vga bios; >that should make this change unnecessary. You have to initialize the PCI subsystem before you can initialize the VGABIOS. The PCI bus scan may have discovered the primary graphics adapter and copied its BIOS to 0xC. By convention the primary VGA adapter ROM always resides at 0xC. I also have a patch for the cirrus-vga emulation so that it properly emulates the PCI ROM BAR. I'll clean that up and submit it. >> +/* >> + * Some complex PCI devices (such as graphic controllers) >> + * keep lots of internal state, including their PCI mappings >> + * that were determined at initial PCI configuration. >> + * To make them work under QEMU/KVM, we preserve the host's >> + * PCI mappings in the guest. >> + * (we have to do this twice to ensure we update the >> mappings) >> + */ >Can you elaborate? Since we're running the card's bios again, won't it >initialize correctly? The problem is that the device-assignment code doesn't update the cards BARs, it just emulates them and maps the guest BARs onto the correct host BARs. Unfortunately, the graphics card has undocumented interfaces for obtaining the memory regions (faster than a full PCI lookup) and they of course return the host mappings as opposed to the guest mappings. My first attempt was to implement a state machine that would emulate these interfaces and rewrite them but this got pretty ugly pretty fast. Ensuring the same mappings was much cleaner. Of course, my goal is to run unmodified BIOS/drivers. You could always change the drivers. >Keeping the same mapping in the host and guest may not be possible in >some circumstances (differently sized pci holes, or using a 64-bit BAR >in a 64-bit host but running a 32-bit guest that cannot utilize 64-bit >BARs). Yes but that all depends on what the host BIOS does. Most of my experiments have been on a Dell optiplex 755 where all the PCI BARs are allocated at the top of the 32-bit range (I run a 64-bit host and 32-bit guest). Arguably, my rombios patch should do more validation than it does today. >Other than that, the patch looks pretty good. It will need some >massaging before merging, but nothing serious. I'll clean things up and resubmit. Leendert -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] KVM: Interrupt mask notifiers for ioapic
Allow clients to request notifications when the guest masks or unmasks a
particular irq line. This complements irq ack notifications, as the guest
will not ack an irq line that is masked.
Currently implemented for the ioapic only.
Signed-off-by: Avi Kivity
---
include/linux/kvm_host.h | 17 +
virt/kvm/ioapic.c|7 ++-
virt/kvm/irq_comm.c | 24
virt/kvm/kvm_main.c |3 +++
4 files changed, 50 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 545a133..43385fa 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -127,6 +127,10 @@ struct kvm {
struct kvm_coalesced_mmio_ring *coalesced_mmio_ring;
#endif
+#ifdef CONFIG_HAVE_KVM_IRQCHIP
+ struct hlist_head mask_notifier_list;
+#endif
+
#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
struct mmu_notifier mmu_notifier;
unsigned long mmu_notifier_seq;
@@ -320,6 +324,19 @@ struct kvm_assigned_dev_kernel {
struct pci_dev *dev;
struct kvm *kvm;
};
+
+struct kvm_irq_mask_notifier {
+ void (*func)(struct kvm_irq_mask_notifier *kimn, int masked);
+ int irq;
+ struct hlist_node link;
+};
+
+void kvm_register_irq_mask_notifier(struct kvm *kvm, int irq,
+ struct kvm_irq_mask_notifier *kimn);
+void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int irq,
+ struct kvm_irq_mask_notifier *kimn);
+void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, int mask);
+
void kvm_set_irq(struct kvm *kvm, int irq_source_id, int irq, int level);
void kvm_notify_acked_irq(struct kvm *kvm, unsigned gsi);
void kvm_register_irq_ack_notifier(struct kvm *kvm,
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index 23b81cf..15b9ddd 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/ioapic.c
@@ -100,7 +100,7 @@ static void ioapic_service(struct kvm_ioapic *ioapic,
unsigned int idx)
static void ioapic_write_indirect(struct kvm_ioapic *ioapic, u32 val)
{
- unsigned index;
+ unsigned index, mask_before, mask_after;
switch (ioapic->ioregsel) {
case IOAPIC_REG_VERSION:
@@ -120,6 +120,7 @@ static void ioapic_write_indirect(struct kvm_ioapic
*ioapic, u32 val)
ioapic_debug("change redir index %x val %x\n", index, val);
if (index >= IOAPIC_NUM_PINS)
return;
+ mask_before = ioapic->redirtbl[index].fields.mask;
if (ioapic->ioregsel & 1) {
ioapic->redirtbl[index].bits &= 0x;
ioapic->redirtbl[index].bits |= (u64) val << 32;
@@ -128,6 +129,9 @@ static void ioapic_write_indirect(struct kvm_ioapic
*ioapic, u32 val)
ioapic->redirtbl[index].bits |= (u32) val;
ioapic->redirtbl[index].fields.remote_irr = 0;
}
+ mask_after = ioapic->redirtbl[index].fields.mask;
+ if (mask_before != mask_after)
+ kvm_fire_mask_notifiers(ioapic->kvm, index, mask_after);
if (ioapic->irr & (1 << index))
ioapic_service(ioapic, index);
break;
@@ -426,3 +430,4 @@ int kvm_ioapic_init(struct kvm *kvm)
kvm_io_bus_register_dev(&kvm->mmio_bus, &ioapic->dev);
return 0;
}
+
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index aa5d1e5..2cbde68 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -99,3 +99,27 @@ void kvm_free_irq_source_id(struct kvm *kvm, int
irq_source_id)
clear_bit(irq_source_id, &kvm->arch.irq_states[i]);
clear_bit(irq_source_id, &kvm->arch.irq_sources_bitmap);
}
+
+void kvm_register_irq_mask_notifier(struct kvm *kvm, int irq,
+ struct kvm_irq_mask_notifier *kimn)
+{
+ kimn->irq = irq;
+ hlist_add_head(&kimn->link, &kvm->mask_notifier_list);
+}
+
+void kvm_unregister_irq_mask_notifier(struct kvm *kvm, int irq,
+ struct kvm_irq_mask_notifier *kimn)
+{
+ hlist_del(&kimn->link);
+}
+
+void kvm_fire_mask_notifiers(struct kvm *kvm, int irq, int mask)
+{
+ struct kvm_irq_mask_notifier *kimn;
+ struct hlist_node *n;
+
+ hlist_for_each_entry(kimn, n, &kvm->mask_notifier_list, link)
+ if (kimn->irq == irq)
+ kimn->func(kimn, mask);
+}
+
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 5703557..dcd58d6 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -806,6 +806,9 @@ static struct kvm *kvm_create_vm(void)
if (IS_ERR(kvm))
goto out;
+#ifdef CONFIG_HAVE_KVM_IRQCHIP
+ INIT_HLIST_HEAD(&kvm->mask_notifier_list);
+#endif
#ifdef KVM_COALESCED_MMIO_PAGE_OFFSET
page = alloc_page(GFP_KERNEL | __GFP_ZERO);
--
1.6.0.6
--
To unsubscribe from this list: send the line "unsubs
[PATCH 3/3] KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked
While the PIT is masked the guest cannot ack the irq, so the reinject logic
will never allow the interrupt to be injected.
Fix by resetting the reinjection counters on unmask.
Unbreaks Xen.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/i8254.c | 15 +++
arch/x86/kvm/i8254.h |1 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 528daad..d78d430 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -539,6 +539,16 @@ void kvm_pit_reset(struct kvm_pit *pit)
pit->pit_state.irq_ack = 1;
}
+static void pit_mask_notifer(struct kvm_irq_mask_notifier *kimn, int mask)
+{
+ struct kvm_pit *pit = container_of(kimn, struct kvm_pit, mask_notifier);
+
+ if (!mask) {
+ atomic_set(&pit->pit_state.pit_timer.pending, 0);
+ pit->pit_state.irq_ack = 1;
+ }
+}
+
struct kvm_pit *kvm_create_pit(struct kvm *kvm)
{
struct kvm_pit *pit;
@@ -588,6 +598,9 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm)
kvm_pit_reset(pit);
+ pit->mask_notifier.func = pit_mask_notifer;
+ kvm_register_irq_mask_notifier(kvm, 0, &pit->mask_notifier);
+
return pit;
}
@@ -596,6 +609,8 @@ void kvm_free_pit(struct kvm *kvm)
struct hrtimer *timer;
if (kvm->arch.vpit) {
+ kvm_unregister_irq_mask_notifier(kvm, 0,
+ &kvm->arch.vpit->mask_notifier);
mutex_lock(&kvm->arch.vpit->pit_state.lock);
timer = &kvm->arch.vpit->pit_state.pit_timer.timer;
hrtimer_cancel(timer);
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index 76959c4..6acbe4b 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -46,6 +46,7 @@ struct kvm_pit {
struct kvm *kvm;
struct kvm_kpit_state pit_state;
int irq_source_id;
+ struct kvm_irq_mask_notifier mask_notifier;
};
#define KVM_PIT_BASE_ADDRESS 0x40
--
1.6.0.6
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] KVM: Add CONFIG_HAVE_KVM_IRQCHIP
Two KVM archs support irqchips and two don't. Add a Kconfig item to make selecting between the two models easier. Signed-off-by: Avi Kivity --- arch/ia64/kvm/Kconfig|4 arch/powerpc/kvm/Kconfig |3 +++ arch/s390/kvm/Kconfig|3 +++ arch/x86/kvm/Kconfig |4 4 files changed, 14 insertions(+), 0 deletions(-) diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig index f833a0b..0a2d6b8 100644 --- a/arch/ia64/kvm/Kconfig +++ b/arch/ia64/kvm/Kconfig @@ -4,6 +4,10 @@ config HAVE_KVM bool +config HAVE_KVM_IRQCHIP + bool + default y + menuconfig VIRTUALIZATION bool "Virtualization" depends on HAVE_KVM || IA64 diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig index 1465705..5a152a5 100644 --- a/arch/powerpc/kvm/Kconfig +++ b/arch/powerpc/kvm/Kconfig @@ -2,6 +2,9 @@ # KVM configuration # +config HAVE_KVM_IRQCHIP + bool + menuconfig VIRTUALIZATION bool "Virtualization" ---help--- diff --git a/arch/s390/kvm/Kconfig b/arch/s390/kvm/Kconfig index e051cad..3e260b7 100644 --- a/arch/s390/kvm/Kconfig +++ b/arch/s390/kvm/Kconfig @@ -4,6 +4,9 @@ config HAVE_KVM bool +config HAVE_KVM_IRQCHIP + bool + menuconfig VIRTUALIZATION bool "Virtualization" default y diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig index b81125f..0a303c3 100644 --- a/arch/x86/kvm/Kconfig +++ b/arch/x86/kvm/Kconfig @@ -4,6 +4,10 @@ config HAVE_KVM bool +config HAVE_KVM_IRQCHIP + bool + default y + menuconfig VIRTUALIZATION bool "Virtualization" depends on HAVE_KVM || X86 -- 1.6.0.6 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Reset PIT reinjection logic on irq unmask
Currently, when a guest has the pit running but masked, it will accumulate pending irq injection requests but will never ack them (as the interrupts are masked). When the interrupt is finally unmasked, the reinject logic ignores pending interrupts since it sees unacked pending irqs. Add a notifier on irq unmasking, and use that in the PIT to clear the reinject logic. Currently only ioapic mask notifications are implemented. This could be used to disable the hrtimer if the guest masks the PIT and uses some other timer. Please review. Avi Kivity (3): KVM: Add CONFIG_HAVE_KVM_IRQCHIP KVM: Interrupt mask notifiers for ioapic KVM: Reset PIT irq injection logic when the PIT IRQ is unmasked arch/ia64/kvm/Kconfig|4 arch/powerpc/kvm/Kconfig |3 +++ arch/s390/kvm/Kconfig|3 +++ arch/x86/kvm/Kconfig |4 arch/x86/kvm/i8254.c | 15 +++ arch/x86/kvm/i8254.h |1 + include/linux/kvm_host.h | 17 + virt/kvm/ioapic.c|7 ++- virt/kvm/irq_comm.c | 24 virt/kvm/kvm_main.c |3 +++ 10 files changed, 80 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: gdbstub: packet reply is too long
Jamie Lokier wrote: > Jan Kiszka wrote: >> You need CR0.PE to detect if you are in real or protected mode. And then >> you need GDTR/LDTR to find the descriptor CS is pointing at, parsing it >> to detect if you are running 16, 32 or 64 bit code (by default). Those >> extensions would also be useful in order to decode memory addresses in >> case descriptor.base != 0 (or if it's CS >> 4, ie. you are in real >> mode). > > If you're going to decode segment descriptors (great idea, btw, and > helpful for threaded code), it might be better to supply the CPU's > internal segment state, if that's possible, instead of looking at the > LDT/GDT in memory, since the CPU's state can differ from the memory > version when the latter is written to. Good point. I included this in an initial suggestion of an extended register set, see [1]. Providing this information will likely remain VM-business, but that doesn't mean we shouldn't use it when available. Jan [1] http://sourceware.org/ml/gdb/2009-01/msg8.html signature.asc Description: OpenPGP digital signature
Re: USB Printer does not work
André Roth wrote:
Hello List,
I'm using kvm-82 and I'm trying to attach a HP 1200 per USB to my guest system (Debian/lenny, 2.6.26-1-amd64). This works so far, the usblp module is loaded and I get a /dev/usb/lp0. I can print text/plain by catting text to the device.
But using CUPS, the device is not detected due to a failing ioctl:
# strace /usr/lib/cups/backend/usb 2>&1 | grep error\\\|lp0 -i
...
open("/dev/usb/lp0", O_RDWR|O_EXCL) = 3
ioctl(3, SNDCTL_DSP_SYNC, 0x7fff90018760) = -1 EIO (Input/output error)
Specifying the device manually does not work either. On the host system
this works without problems. The CPU is an Intel Core2 Quad Q9300.
How can I further debug this ?
An messages in dmesg?
Though I'm afraid I know very little about USB. You might try the qemu
list.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bios: Remove duplicate call to qemu_cfg_port_probe()
Sebastian Herbszt wrote: qemu_cfg_port_probe is called twice in rombios32.c. Remove the second call. Applied, thanks. Please add signoff lines in the future. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mouse motion lags
Volodymyr Buell wrote: Hi everybody, I switched to KVM some time ago from vmware and VB. Everything works great but there are noticeable lags in mouse motion in comparison with other VMs. Is this a known issue? Are there any optimizations for that? KVM: 79 Distr: Ubuntu Intrepid & Jaunty Command line: QEMU_AUDIO_DRV=sdl; kvm -net nic -net user -soundhw es1370 -m 750 -smp 2 win.qcow Is this under guest or host load? Or just moving the mouse around? Is the host swapping by any chance? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor Write I/O Performance on KVM-79
Alexander Atticus wrote: Hello! I have been experimenting with KVM and have been experiencing poor write I/O performance. I'm not sure whether I'm doing something wrong or if this is just the current state of things. While writing to the local array on the node running the guests I get about 200MB/s from dd (bs=1M count=1000) or about 90MB/s write performance from iozone (sequencial) when I write to a 2G file with a 16M record length. The node is an 8 disk system using 3ware in a RAID50 configuration. It has 8GB of RAM. The guests get much slower disk access. The guests are using file based backends (tried both qcow2 and raw) with virtio support. With no other activity on the machine, I get about 6 to 7MB/s write performance from iozone with the same test. Guests are running Debian lenny/sid with 2.6.26-1-686. qcow2 will surely lead to miserable performance. raw files are better. best is to use lvm. I don't know whether this is because of context switching or what. Again, I'm wondering how I can improve this performance or if there is something I am doing wrong. As a side note, I have also noticed some weirdness with qcow2 files; some windows installations freeze and some disk corruption running iozone on Linux guests. All problems go away when I switch to raw image files though. I realize I take a hit by running file-based backends, and that the tests aren't altogether accurate because with 8GB of RAM, I'm not saturating the cache but they are still very disparate in numbers which concerns me. Finally, does anyone know if KVM is now fully supporting SCSI pass-through in KVM-79? Does this mean that I would vastly reduce context switching by using an LVM backend device for guests or am I misunderstanding the benefits of pass-through? scsi is much improved in kvm-82 though it still needs a lot more testing. scsi pass-through is almost completely untested. What is the kernel version in the guest? IIRC there were some serious limitations on the request size that were recently removed. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xen-in-kvm doesn't work with kvm-81.
Avi Kivity wrote: Yiyi Hu wrote: Host info: h...@hs ~ $ uname -a Linux Hs 2.6.27-gentoo-r6 #1 SMP Mon Dec 15 11:43:12 CST 2008 x86_64 AMD Athlon(tm) X2 Dual Core Processor BE-2350 AuthenticAMD GNU/Linux KVM is version 81. Installed from portage. The guest is 64bit debian lenny, Within guest, we install the xen system. The xen-in-kvm won't boot fine after upgraded to kvm-81. Can you find the last version of kvm that worked? that will speed up isolating the problem. It seems to work with -no-kvm-pit-reinjection. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 'make' is no longer producing *.ko files?
Michael Park wrote: Hi there, Sorry for the delay.. Very strange. Can you add 'V=1' to the line that starts with $(MAKE) -C $(KERNELDIR) in kernel/Makefile and rerun? post the log. ..sure thing, I've attached it inline below. I'm guessing this is some sort of autoconf-related error (something mis-detected or something)?.. Or could it be related to my most recent updated kernel + relevant sources (2.6.27.9-73.fc9.x86_64)? kvm-82 doesn't even compile for me on this kernel version due to some hrtimer backports. Are you throwing stderr somewhere and losing the error messages? I suggest going back to the previous kernel, or waiting for kvm-83 which will have this fixed. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00 of 16] port KVM to PowerPC e500
Hollis Blanchard wrote: Hi Avi, these patches add support for Freescale's e500 (v2) core. I did some refactoring, but the actual port was done by Liu Yu at Freescale. Please apply. e500 is a 32-bit PowerPC "Book E" core (as is IBM/AMCC's 440) found in a variety of Freescale SoCs. It uses a software-managed TLB and no hardware tablewalk. (These patches do not contain support for Freescale's announced e500mc core, which implements virtualization features in hardware.) 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: PowerPC: Disarm old guest debug interface
Hollis Blanchard wrote:
kvm: ppc: remove debug support broken by KVM debug rewrite
After the rewrite of KVM's debug support, this code doesn't even build any
more.
Signed-off-by: Hollis Blanchard
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -118,11 +118,6 @@ struct kvm_arch {
struct kvm_vcpu_arch {
u32 host_stack;
u32 host_pid;
- u32 host_dbcr0;
- u32 host_dbcr1;
- u32 host_dbcr2;
- u32 host_iac[4];
- u32 host_msr;
u64 fpr[32];
ulong gpr[32];
@@ -200,10 +195,4 @@ struct kvm_vcpu_arch {
unsigned long pending_exceptions;
};
-struct kvm_guest_debug {
- int enabled;
- unsigned long bp[4];
- int singlestep;
-};
-
#endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -71,9 +71,6 @@ extern int kvmppc_core_vcpu_translate(st
extern void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
extern void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu);
-extern void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu);
-
extern void kvmppc_core_deliver_interrupts(struct kvm_vcpu *vcpu);
extern int kvmppc_core_pending_dec(struct kvm_vcpu *vcpu);
extern void kvmppc_core_queue_program(struct kvm_vcpu *vcpu);
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -28,72 +28,6 @@
#include "44x_tlb.h"
-/* Note: clearing MSR[DE] just means that the debug interrupt will not be
- * delivered *immediately*. Instead, it simply sets the appropriate DBSR bits.
- * If those DBSR bits are still set when MSR[DE] is re-enabled, the interrupt
- * will be delivered as an "imprecise debug event" (which is indicated by
- * DBSR[IDE].
- */
-static void kvm44x_disable_debug_interrupts(void)
-{
- mtmsr(mfmsr() & ~MSR_DE);
-}
-
-void kvmppc_core_load_host_debugstate(struct kvm_vcpu *vcpu)
-{
- kvm44x_disable_debug_interrupts();
-
- mtspr(SPRN_IAC1, vcpu->arch.host_iac[0]);
- mtspr(SPRN_IAC2, vcpu->arch.host_iac[1]);
- mtspr(SPRN_IAC3, vcpu->arch.host_iac[2]);
- mtspr(SPRN_IAC4, vcpu->arch.host_iac[3]);
- mtspr(SPRN_DBCR1, vcpu->arch.host_dbcr1);
- mtspr(SPRN_DBCR2, vcpu->arch.host_dbcr2);
- mtspr(SPRN_DBCR0, vcpu->arch.host_dbcr0);
- mtmsr(vcpu->arch.host_msr);
-}
-
-void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
-{
- struct kvm_guest_debug *dbg = &vcpu->guest_debug;
- u32 dbcr0 = 0;
-
- vcpu->arch.host_msr = mfmsr();
- kvm44x_disable_debug_interrupts();
-
- /* Save host debug register state. */
- vcpu->arch.host_iac[0] = mfspr(SPRN_IAC1);
- vcpu->arch.host_iac[1] = mfspr(SPRN_IAC2);
- vcpu->arch.host_iac[2] = mfspr(SPRN_IAC3);
- vcpu->arch.host_iac[3] = mfspr(SPRN_IAC4);
- vcpu->arch.host_dbcr0 = mfspr(SPRN_DBCR0);
- vcpu->arch.host_dbcr1 = mfspr(SPRN_DBCR1);
- vcpu->arch.host_dbcr2 = mfspr(SPRN_DBCR2);
-
- /* set registers up for guest */
-
- if (dbg->bp[0]) {
- mtspr(SPRN_IAC1, dbg->bp[0]);
- dbcr0 |= DBCR0_IAC1 | DBCR0_IDM;
- }
- if (dbg->bp[1]) {
- mtspr(SPRN_IAC2, dbg->bp[1]);
- dbcr0 |= DBCR0_IAC2 | DBCR0_IDM;
- }
- if (dbg->bp[2]) {
- mtspr(SPRN_IAC3, dbg->bp[2]);
- dbcr0 |= DBCR0_IAC3 | DBCR0_IDM;
- }
- if (dbg->bp[3]) {
- mtspr(SPRN_IAC4, dbg->bp[3]);
- dbcr0 |= DBCR0_IAC4 | DBCR0_IDM;
- }
-
- mtspr(SPRN_DBCR0, dbcr0);
- mtspr(SPRN_DBCR1, 0);
- mtspr(SPRN_DBCR2, 0);
-}
-
void kvmppc_core_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
kvmppc_44x_tlb_load(vcpu);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -216,36 +216,18 @@ void kvm_arch_vcpu_uninit(struct kvm_vcp
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
- if (vcpu->guest_debug.enabled)
- kvmppc_core_load_guest_debugstate(vcpu);
-
kvmppc_core_vcpu_load(vcpu, cpu);
}
void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
{
- if (vcpu->guest_debug.enabled)
- kvmppc_core_load_host_debugstate(vcpu);
-
kvmppc_core_vcpu_put(vcpu);
}
int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
- struct kvm_guest_debug *dbg)
+struct kvm_guest_debug *dbg)
{
- int i;
-
- vcpu->guest_debug.enabled = dbg->enabled;
- if (vcpu->guest_debug.enabled) {
- for (i=0; i
Re: [PATCH][v2] kvm-userspace: Load PCI option ROMs
Leendert van Doorn wrote:
I've been experimenting with passthru graphics for KVM and for that I needed
to add PCI ROM support to QEMU. I went a slightly different route than
Haitoa, I enabled the BIOS to do the PCI ROM mapping and initialization and
added support for QEMU to fully implement the ROM BAR. This patch also uses
the host BAR addresses in the guest for direct assigned devices, because (as
Avi already pointed out) this is needed for more complex PCI cards such as
graphics adapters. My patch also allows you to optionally specify the ROM
image, which I found very useful for debugging.
My ROMBIOS patches are probably more invasive than necessary. I found it
cleaner (==easier to understand) to call the rombios from 32-bit mode than
leave some droppings (option rom address, bdf) in the BIOS extended data
segment. The other thing you notice is that I initialize the primary VGA ROM
last. I found that this was necessary when emulating dual headed displays
(one display on qemu's emulation window, the other the actual device).
I've attached my patches.
Note that I have not included the full graphics passthru patches yet. I have
that working for the xorg ati drivers (and ATI's ATOMBIOS) but not for the
closed sourced or Windows drivers yet. Let me know if you are interested in
those patches.
This is very interesting.
@@ -10194,6 +10195,7 @@ no_serial:
pop dx
ret
+#if !BX_ROMBIOS32
rom_checksum:
push ax
push bx
@@ -10266,7 +10268,6 @@ block_count_rounded:
mov ax, #0xf000
mov es, ax
lea di, pnp_string
-
mov bp, sp ;; Call ROM init routine using seg:off on stack
db 0xff ;; call_far ss:[bp+0]
db 0x5e
@@ -10348,6 +10349,7 @@ rom_scan_increment:
xor ax, ax ;; Restore DS back to :
mov ds, ax
ret
+#endif /* !BX_ROMBIOS32 */
This is worrying as it will cause us to diverge from upstream bochs bios.
post_enable_cache:
;; enable cache
@@ -10652,12 +10654,6 @@ post_default_ints:
;; PIC
call post_init_pic
- mov cx, #0xc000 ;; init vga bios
- mov ax, #0xc780
- call rom_scan
-
- call _print_bios_banner
-
#if BX_ROMBIOS32
call rombios32_init
#else
@@ -10665,7 +10661,12 @@ post_default_ints:
call pcibios_init_iomem_bases
call pcibios_init_irqs
#endif //BX_PCIBIOS
-#endif
+ mov cx, #0xc000 ;; init vga bios
+ mov ax, #0xc780
+ call rom_scan
+#endif //BX_ROMBIOS32
+
+ call _print_bios_banner
If one assigns a graphics card, it should replace the cirrus vga bios;
that should make this change unnecessary.
@@ -953,18 +955,21 @@ static void pci_bios_init_device(PCIDevice *d)
default_map:
/* default memory mappings */
for(i = 0; i < PCI_NUM_REGIONS; i++) {
+uint32_t orig, addr, val, size;
int ofs;
-uint32_t val, size ;
if (i == PCI_ROM_SLOT)
ofs = 0x30;
else
ofs = 0x10 + i * 4;
+orig = pci_config_readl(d, ofs);
pci_config_writel(d, ofs, 0x);
val = pci_config_readl(d, ofs);
if (val != 0) {
size = (~(val & ~0xf)) + 1;
-if (val & PCI_ADDRESS_SPACE_IO)
+ if (i == PCI_ROM_SLOT)
+ paddr = &pci_bios_mem_addr;
+ else if (val & PCI_ADDRESS_SPACE_IO)
paddr = &pci_bios_io_addr;
else if (size >= 0x0400)
paddr = &pci_bios_bigmem_addr;
@@ -972,7 +977,24 @@ static void pci_bios_init_device(PCIDevice *d)
paddr = &pci_bios_mem_addr;
*paddr = (*paddr + size - 1) & ~(size - 1);
pci_set_io_region_addr(d, i, *paddr);
+ BX_INFO("PCI: region %d: paddr 0x%x, size 0x%x\n",
+ i, *paddr, size);
*paddr += size;
+
+ /*
+* Some complex PCI devices (such as graphic controllers)
+* keep lots of internal state, including their PCI mappings
+* that were determined at initial PCI configuration.
+* To make them work under QEMU/KVM, we preserve the host's
+* PCI mappings in the guest.
+* (we have to do this twice to ensure we update the
mappings)
+*/
Can you elaborate? Since we're running the card's bios again, won't it
initialize correctly?
Keeping the same mapping in the host and guest may not be possible in
some circumstances (differently sized pci holes, or using a 64-bit BAR
in a 64-bit host but running a 32-bit guest that cannot utilize 64-bit
BARs).
Other than that, the patch looks pretty good. It will need some
massaging before merging, but nothing serious.
--
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 majord...@vger.kernel.org
More majordomo info at
