This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] use of struct hvm_mirq_dpci_mapping.gmsi vs. HVM_IRQ_DPC

To: "Allen M Kay" <allen.m.kay@xxxxxxxxx>
Subject: Re: [Xen-devel] use of struct hvm_mirq_dpci_mapping.gmsi vs. HVM_IRQ_DPCI_*_MSI flags
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 26 Apr 2011 09:48:14 +0100
Cc: Haitao Shan <maillists.shan@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 26 Apr 2011 01:48:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BANLkTinVcOUqDst2nOj8xfzNFbHnEtwCJg@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D94A88C0200007800039637@xxxxxxxxxxxxxxxxxx> <BANLkTinVcOUqDst2nOj8xfzNFbHnEtwCJg@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 21.04.11 at 09:14, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
> See comments below.
> 2011/3/31 Jan Beulich <JBeulich@xxxxxxxxxx>
>> pt_irq_create_bind_vtd() initializes this substructure only when setting
>> PT_IRQ_TYPE_MSI case), while the other path will not set
>> Yet hvm_dpci_msi_eoi() and hvm_migrate_pirqs() check for
>> HVM_IRQ_DPCI_MACH_MSI, i.e. may run into an uninitialized
>> .gmsi.* field. What am I missing here?
> I think these fields are introduced by MSI-to-gINTx patch. MACH_MSI means
> the host (physical) is using MSI, while GUEST_MSI is just what we can guess
> from its name.
> I agree only checking MACH_MSI is not enough.
>> I'm largely asking because I think struct hvm_mirq_dpci_mapping.dom
>> and .digl_list could actually overlay .gmsi, as much as struct
>> hvm_irq_dpci.hvm_timer could actually rather be folded into struct
>> hvm_mirq_dpci_mapping (and then also overlay .gmsi). The overlay
>> distinction bit would, based on initialization, be HVM_IRQ_DPCI_GUEST_MSI,
>> but according to use it wouldn't be clear which of the two
>> HVM_IRQ_DPCI_*_MSI bits is actually the correct one.
>> Having a single structure only would make it a lot easier to
>> convert struct hvm_mirq_dpci_mapping * in struct hvm_irq_dpci to
>> a sparse struct hvm_mirq_dpci_mapping ** (populating slots only
>> as they get used), thus shrinking the currently two d->nr_pirqs
>> sized array allocations in pt_irq_create_bind_vtd() to a single one
>> with only pointer size array elements (allowing up to about 512
>> domain pirqs rather than currently slightly above 80 without
>> exceeding PAGE_SIZE on allocation).
> I also agree. But  I think better Allen could do the final judgement.


> Thanks!
>> Also I'm wondering why the PT_IRQ_TYPE_MSI path of
>> pt_irq_create_bind_vtd() checks that on re-use of an IRQ the
>> flags are indicating the same kind of interrupt, while the other
>> path doesn't bother doing so.
> The purpuse is described in the check in notes:
> # HG changeset patch
> # User Keir Fraser <keir.fraser@xxxxxxxxxx>
> # Date 1239806337 -3600
> # Node ID 3e64dfebabd7340f5852ad112c858efcebc9cae5
> # Parent  b2c43b0fba713912d8ced348b5d628743e52d8be
> passthrough: allow pt_bind_irq for msi update
> Extend pt_bind_irq to handle the update of msi guest
> vector and flag.
> Unbind and rebind using separate hypercalls may not be viable
> sometime.
> For example, the guest may update MSI address/data on fly without
> disabling it first (e.g. change delivery/destination), implement these
> updates in such a way may result in interrupt loss.
> Signed-off-by: Qing He <qing.he@xxxxxxxxx>
>> Thanks, Jan
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx 
>> http://lists.xensource.com/xen-devel 

Xen-devel mailing list