xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: X86 <x86@kernel.org>, Jeremy Fitzhardinge <jeremy@goop.org>,
	Greg Kroah-Hartman <gregkh@suse.de>, KVM <kvm@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>,
	Virtualization <virtualization@lists.linux-foundation.org>,
	Ingo Molnar <mingo@redhat.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	Sasha Levin <levinsasha928@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Xen <xen-devel@lists.xensource.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks
Date: Sun, 29 Apr 2012 16:52:27 +0300	[thread overview]
Message-ID: <20120429135227.GC15413@redhat.com> (raw)
In-Reply-To: <4F9D417D.1050105@redhat.com>

On Sun, Apr 29, 2012 at 04:26:21PM +0300, Avi Kivity wrote:
> On 04/29/2012 04:20 PM, Gleb Natapov wrote:
> > > > This is too similar to kvm_irq_delivery_to_apic(). Why not reuse it. We
> > > > can use one of reserved delivery modes as PV delivery mode. We will
> > > > disallow guest to trigger it through apic interface, so this will not be
> > > > part of ABI and can be changed at will.
> > > >
> > > 
> > > I'm not thrilled about this.  Those delivery modes will eventually
> > > become unreserved.  We can have a kvm_lookup_apic_id() that is shared
> > > among implementations.
> > > 
> > This is only internal implementation. If they become unreserved we will
> > use something else.
> >
> 
> Yeah, I'm thinking of that time.  Why do something temporary and fragile?
> 
Why is it fragile? Just by unreserving the value Intel will not break
KVM. Only when KVM will implement apic feature that unreserves the value
we will have to change internal implementation and use another value,
but this will be done by the same patch that does unreserving. The
unreserving may even never happen. Meanwhile kvm_irq_delivery_to_apic()
will likely be optimized to use hash for unicast delivery and unhalt
hypercall will benefit from it immediately.

--
			Gleb.

  reply	other threads:[~2012-04-29 13:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-23  9:59 [PATCH RFC V6 0/5] kvm : Paravirt-spinlock support for KVM guests Raghavendra K T
2012-04-23  9:59 ` [PATCH RFC V6 1/5] kvm hypervisor : Add a hypercall to KVM hypervisor to support pv-ticketlocks Raghavendra K T
2012-04-24  9:59   ` Gleb Natapov
2012-04-26  8:11     ` Raghavendra K T
2012-04-27 10:45     ` Raghavendra K T
2012-04-27 15:53       ` Gleb Natapov
2012-06-28 18:17         ` Raghavendra K T
2012-04-29 13:18     ` Avi Kivity
2012-04-29 13:20       ` Gleb Natapov
2012-04-29 13:26         ` Avi Kivity
2012-04-29 13:52           ` Gleb Natapov [this message]
2012-04-30  8:22             ` Avi Kivity
2012-04-30  8:38               ` Gleb Natapov
2012-04-29 13:25   ` Avi Kivity
2012-04-30  7:44     ` Raghavendra K T
2012-04-30  8:19       ` Avi Kivity
2012-05-01 20:20       ` Raghavendra K T
2012-04-23 10:00 ` [PATCH RFC V6 2/5] kvm : Fold pv_unhalt flag into GET_MP_STATE ioctl to aid migration Raghavendra K T
2012-04-29 13:27   ` Avi Kivity
2012-04-30  7:45     ` Raghavendra K T
2012-04-23 10:00 ` [PATCH RFC V6 3/5] kvm guest : Add configuration support to enable debug information for KVM Guests Raghavendra K T
2012-04-23 10:00 ` [PATCH RFC V6 4/5] kvm : pv-ticketlocks support for linux guests running on KVM hypervisor Raghavendra K T
2012-04-23 10:00 ` [PATCH RFC V6 5/5] Documentation/kvm : Add documentation on Hypercalls and features used for PV spinlock Raghavendra K T
2012-04-26 15:57   ` Rob Landley
2012-04-26 16:04     ` Raghavendra K T

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=20120429135227.GC15413@redhat.com \
    --to=gleb@redhat.com \
    --cc=avi@redhat.com \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=raghavendra.kt@linux.vnet.ibm.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=vatsa@linux.vnet.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=x86@kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).