public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Don Dutile <ddutile@redhat.com>,
	Sheng Yang <sheng@linux.intel.com>
Subject: Re: [PATCH 03/12] evtchn delivery on HVM
Date: Wed, 19 May 2010 11:19:11 -0700	[thread overview]
Message-ID: <4BF42B9F.3080201@goop.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1005191315160.11380@kaball-desktop>

On 05/19/2010 05:24 AM, Stefano Stabellini wrote:
> On Tue, 18 May 2010, Jeremy Fitzhardinge wrote:
>   
>> On 05/18/2010 03:22 AM, Stefano Stabellini wrote:
>>     
>>> From: Sheng Yang <sheng@linux.intel.com>
>>>
>>> Set the callback to receive evtchns from Xen, using the
>>> callback vector delivery mechanism.
>>>   
>>>       
>> Could you expand on this a little?  Like, why is this desireable?  What
>> functional difference does it make?  Is this patch useful in its own
>> right, or is it just laying the groundwork for something else?
>>
>>     
> In order to use PV frontends on HVM we need to receive notifications on
> event channel deliveries somehow.
>   
(OK, but I just meant update the commit comment on the patch itself.)

> Using the callback vector is the preferred way, because it is available
> independently from any (emulated) PCI device, all the vcpus can receive
> these callbacks and theoretically there is no need to interact with the
> emulated lapic (even though at the moment we are doing it anyway because
> we are using the IPI vector).
>   
> The other way is to receive interrupts from the xen platform pci device,
> but in that case interaction with the emulated lapic is unavoidable and
> we are limited to receive interrupts on vcpu 0.
>   

Perhaps you should mention this first, since it is the historical way of
doing it, and then talk about its limitations, and then talk about the
replacement to address those limitations.

    J


  reply	other threads:[~2010-05-19 18:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 10:22 [PATCH 0 of 12] PV on HVM Xen Stefano Stabellini
2010-05-18 10:22 ` [PATCH 01/12] Add support for hvm_op Stefano Stabellini
2010-05-18 10:22 ` [PATCH 02/12] early PV on HVM Stefano Stabellini
2010-05-18 10:22 ` [PATCH 03/12] evtchn delivery " Stefano Stabellini
2010-05-18 17:17   ` Jeremy Fitzhardinge
2010-05-19 12:24     ` Stefano Stabellini
2010-05-19 18:19       ` Jeremy Fitzhardinge [this message]
2010-05-18 17:43   ` Jeremy Fitzhardinge
2010-05-19 13:01     ` Stefano Stabellini
2010-05-18 18:10   ` Jeremy Fitzhardinge
2010-05-19 13:08     ` Stefano Stabellini
2010-05-18 10:22 ` [PATCH 04/12] Fix find_unbound_irq in presence of ioapic irqs Stefano Stabellini
2010-05-18 10:23 ` [PATCH 05/12] unplug emulated disks and nics Stefano Stabellini
2010-05-18 17:27   ` Jeremy Fitzhardinge
2010-05-19 13:00     ` Stefano Stabellini
2010-05-18 10:23 ` [PATCH 06/12] xen pci platform device driver Stefano Stabellini
2010-05-18 18:11   ` Jeremy Fitzhardinge
2010-05-19 13:50     ` Stefano Stabellini
2010-05-18 10:23 ` [PATCH 07/12] Add suspend\resume support for PV on HVM guests Stefano Stabellini
2010-05-18 18:11   ` Jeremy Fitzhardinge
2010-05-19 14:18     ` Stefano Stabellini
2010-05-18 10:23 ` [PATCH 08/12] Allow xen platform pci device to be compiled as a module Stefano Stabellini
2010-05-18 18:15   ` Jeremy Fitzhardinge
2010-05-19 14:19     ` Stefano Stabellini
2010-05-18 10:23 ` [PATCH 09/12] Fix possible NULL pointer dereference in print_IO_APIC Stefano Stabellini
2010-05-18 18:15   ` Jeremy Fitzhardinge
2010-05-19 14:25     ` Stefano Stabellini
2010-05-18 10:23 ` [PATCH 10/12] __setup_vector_irq: handle NULL chip_data Stefano Stabellini
2010-05-18 10:23 ` [PATCH 11/12] Support VIRQ_TIMER and pvclock on HVM Stefano Stabellini
2010-05-18 18:23   ` Jeremy Fitzhardinge
2010-05-18 10:23 ` [PATCH 12/12] Initialize xenbus device structs with ENODEV as default state Stefano Stabellini
2010-05-18 18:28   ` Jeremy Fitzhardinge
  -- strict thread matches above, loose matches on Subject: below --
2010-06-03 13:10 [PATCH 01/12] Add support for hvm_op stefano.stabellini
2010-06-03 13:10 ` [PATCH 03/12] evtchn delivery on HVM stefano.stabellini

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=4BF42B9F.3080201@goop.org \
    --to=jeremy@goop.org \
    --cc=ddutile@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sheng@linux.intel.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --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