All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori-NZpS4cJIG2HvQtjrzfazuQ@public.gmane.org>
To: lists-KflyTEd1h+K1Qrn1Bg8BZw@public.gmane.org
Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: KVM, AMD & Interrupts
Date: Wed, 24 Jan 2007 19:52:50 -0600	[thread overview]
Message-ID: <45B80D72.2040900@cs.utexas.edu> (raw)
In-Reply-To: <45B801C4.4060201-Etm38r6YSMlqcVXhcSD7Ah2eb7JE58TQ@public.gmane.org>

Matthew Hall wrote:
> Hi Avi,
>
> I spoke to you a while ago on #kvm on freenode - I had a problem with 
> ide ops on an amd svm host with kvm. The issues regarded the inability 
> to access ida devices (hda/hdc) under qemu & kvm on my host - if this 
> triggers your memory...
>
> The last point I got to was that it was kvm and amd specific. Id est, 
> the same image run under an intel vmx host with the *exact* same image, 
> kvm version and command options (svn 'trunk' from the $date).
> The issue seemed to be AMD and kvm specific (running with '-no-kvm' made 
> everything work ok, but slower, as you'd expect).
>
> I got word of a possible workaround, from one of your colleagues whilst 
> you've been away, to use the boot options 'noapic nolapic' on the host 
> o/s. Using these options solved my hd* op problems and I can boot ok now.
>   

I've seen a very similar problem on an IBM x460.  The main symptom I see 
is lost timer interrupts in the host.

I haven't spent much time looking into this but I suspect it's almost 
certainly related to the fact that KVM is using a different interrupt 
delivery method than Xen.  Xen doesn't seem to have an issue on this 
system.  I suspect that the interrupts being received that's causing a 
VMEXIT is not actually getting propagated to the host (the timer being 
the most frequent interrupt to cause a VMEXIT).  If we switch to not to 
acknowledging the interrupt before the VMEXIT and then regenerating it 
either with a software interrupt or delivering it directly in the host, 
it's possible this problem may go away.

This is all just speculation though.

regards,

Anthony Liguori

> It seems disabling the local apic was the fundamental part (iirc), as 
> without host support the guest would always start the dummy apic; so 
> running the guest with any 'special' options (ie. '-no-apic') should not 
> be required.
>
> I'm think this problem is specific to my particular cpu/motherboard 
> combination aswell.
> I also have box with a recent intel cpu (with the vmx extention) which 
> doesn't display this behaviour; and from talking with you it's not 
> purely amd specific (I believe your tests on amd cpu worked).
> Is it possible a slowdown in the interrupt controller between the guest 
> and host is a contributing factor?
> Iirc, with a 'dummy' apic, I experience a ~5% slowdown on disk and 
> network operations, which isn't so bad. I've yet to think about smp usage.
>
> Thought you might appreciate this info should you feel it deserve a wiki 
> entry. Point me in the direction of the appropriate page should you feel 
> I can put this info in myself.
>
>
> Best regards,
> Matt
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

  parent reply	other threads:[~2007-01-25  1:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25  1:03 KVM, AMD & Interrupts Matthew Hall
     [not found] ` <45B801C4.4060201-Etm38r6YSMlqcVXhcSD7Ah2eb7JE58TQ@public.gmane.org>
2007-01-25  1:52   ` Anthony Liguori [this message]
2007-01-25  7:49   ` Avi Kivity
2007-01-25 13:36   ` Joerg Roedel
     [not found]     ` <20070125133656.GA22891-5C7GfCeVMHo@public.gmane.org>
2007-01-26  6:42       ` Matthew Hall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45B80D72.2040900@cs.utexas.edu \
    --to=aliguori-nzps4cjig2hvqtjrzfazuq@public.gmane.org \
    --cc=kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org \
    --cc=lists-KflyTEd1h+K1Qrn1Bg8BZw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.