From: Chao Gao <chao.gao@intel.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Feng Wu <feng.wu@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Dario Faggioli <dario.faggioli@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v10 1/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt
Date: Wed, 22 Mar 2017 08:18:57 +0800 [thread overview]
Message-ID: <20170322001857.GA8431@skl-2s3.sh.intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190C6B332@SHSMSX101.ccr.corp.intel.com>
On Wed, Mar 22, 2017 at 01:59:19PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Wednesday, March 15, 2017 1:11 PM
>>
>> Currently, msi_msg_to_remap_entry is buggy when the live IRTE is in posted
>> format. Straightforwardly, we can let caller specify which format of IRTE they
>> want update to. But the problem is current callers are not aware of the
>> binding with guest interrupt. Making all callers be aware of the binding with
>> guest interrupt will cause a far more complicated change. Also some callings
>> happen in interrupt context where they can't acquire d->event_lock to read
>> struct hvm_pirq_dpci.
>
>Above text is unclear to me. Are you trying to explain why current
>code is buggy (which I don't get the point) or simply for mitigation
>options which were once considered but dropped for some reasons?
>
the latter. I will divide them into two sections and add more description about
why current code is buggy.
>>
>> diff --git a/xen/drivers/passthrough/vtd/intremap.c
>> b/xen/drivers/passthrough/vtd/intremap.c
>> index bfd468b..6202ece 100644
>> --- a/xen/drivers/passthrough/vtd/intremap.c
>> +++ b/xen/drivers/passthrough/vtd/intremap.c
>> @@ -552,11 +552,12 @@ static int msi_msg_to_remap_entry(
>> struct msi_desc *msi_desc, struct msi_msg *msg) {
>> struct iremap_entry *iremap_entry = NULL, *iremap_entries;
>> - struct iremap_entry new_ire;
>> + struct iremap_entry new_ire = {{0}};
>> struct msi_msg_remap_entry *remap_rte;
>> unsigned int index, i, nr = 1;
>> unsigned long flags;
>> struct ir_ctrl *ir_ctrl = iommu_ir_ctrl(iommu);
>> + const struct pi_desc *pi_desc = msi_desc->pi_desc;
>>
>> if ( msi_desc->msi_attrib.type == PCI_CAP_ID_MSI )
>> nr = msi_desc->msi.nvec;
>> @@ -595,33 +596,35 @@ static int msi_msg_to_remap_entry(
>> GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
>> iremap_entries, iremap_entry);
>>
>> - memcpy(&new_ire, iremap_entry, sizeof(struct iremap_entry));
>> -
>> - /* Set interrupt remapping table entry */
>> - new_ire.remap.fpd = 0;
>> - new_ire.remap.dm = (msg->address_lo >> MSI_ADDR_DESTMODE_SHIFT)
>> & 0x1;
>> - new_ire.remap.tm = (msg->data >> MSI_DATA_TRIGGER_SHIFT) & 0x1;
>> - new_ire.remap.dlm = (msg->data >> MSI_DATA_DELIVERY_MODE_SHIFT)
>> & 0x1;
>> - /* Hardware require RH = 1 for LPR delivery mode */
>> - new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
>> - new_ire.remap.avail = 0;
>> - new_ire.remap.res_1 = 0;
>> - new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
>> - MSI_DATA_VECTOR_MASK;
>> - new_ire.remap.res_2 = 0;
>> - if ( x2apic_enabled )
>> - new_ire.remap.dst = msg->dest32;
>> + if ( !pi_desc )
>> + {
>> + new_ire.remap.dm = msg->address_lo >>
>> MSI_ADDR_DESTMODE_SHIFT;
>> + new_ire.remap.tm = msg->data >> MSI_DATA_TRIGGER_SHIFT;
>> + new_ire.remap.dlm = msg->data >>
>> MSI_DATA_DELIVERY_MODE_SHIFT;
>> + /* Hardware require RH = 1 for LPR delivery mode */
>> + new_ire.remap.rh = (new_ire.remap.dlm == dest_LowestPrio);
>> + new_ire.remap.vector = (msg->data >> MSI_DATA_VECTOR_SHIFT) &
>> + MSI_DATA_VECTOR_MASK;
>> + if ( x2apic_enabled )
>> + new_ire.remap.dst = msg->dest32;
>> + else
>> + new_ire.remap.dst =
>> + MASK_EXTR(msg->address_lo, MSI_ADDR_DEST_ID_MASK) << 8;
>> + new_ire.remap.p = 1;
>
>Old code also touches fpd, res_1/2/3/4, which are abandoned
>above. Can you elaborate?
>
We have initialized new_ire to zero so I remove all the lines that assign 0 to fields.
>> diff --git a/xen/include/asm-x86/msi.h b/xen/include/asm-x86/msi.h index
>> 9c02945..3286692 100644
>> --- a/xen/include/asm-x86/msi.h
>> +++ b/xen/include/asm-x86/msi.h
>> @@ -118,6 +118,8 @@ struct msi_desc {
>> struct msi_msg msg; /* Last set MSI message */
>>
>> int remap_index; /* index in interrupt remapping table
>> */
>> + const void *pi_desc; /* PDA, indicates msi is delivered via
>> VT-d PI */
>
>what's PDA?
Posted Descriptor Address which is recorded in posted format IRTE.
How about just use "Indicates msi is delivered via VT-d PI" because of the line width
limitation?
>
>> + uint8_t gvec; /* guest vector. valid when pi_desc
>> isn't NULL */
>> };
>>
>> /*
>> --
>> 1.8.3.1
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-03-22 0:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 5:11 [PATCH v10 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list Chao Gao
2017-03-15 5:11 ` [PATCH v10 1/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt Chao Gao
2017-03-15 16:41 ` Jan Beulich
2017-03-15 21:21 ` Chao Gao
2017-03-16 10:24 ` Jan Beulich
2017-03-22 5:59 ` Tian, Kevin
2017-03-22 0:18 ` Chao Gao [this message]
2017-03-22 8:32 ` Tian, Kevin
2017-03-15 5:11 ` [PATCH v10 2/6] VT-d: Some cleanups Chao Gao
2017-03-15 5:11 ` [PATCH v10 3/6] VMX: Fixup PI descriptor when cpu is offline Chao Gao
2017-03-15 5:11 ` [PATCH v10 4/6] VT-d: introduce update_irte to update irte safely Chao Gao
2017-03-15 16:48 ` Jan Beulich
2017-03-15 22:39 ` Chao Gao
2017-03-16 10:29 ` Jan Beulich
2017-03-17 1:52 ` Chao Gao
2017-03-17 9:08 ` Jan Beulich
2017-03-22 6:26 ` Tian, Kevin
2017-03-24 8:44 ` Tian, Kevin
2017-03-15 5:11 ` [PATCH v10 5/6] passthrough/io: don't migrate pirq when it is delivered through VT-d PI Chao Gao
2017-03-17 10:43 ` Jan Beulich
2017-03-20 1:59 ` Chao Gao
2017-03-20 9:18 ` Jan Beulich
2017-03-20 2:38 ` Chao Gao
2017-03-20 10:26 ` Jan Beulich
2017-03-20 5:22 ` Chao Gao
2017-03-20 12:50 ` Jan Beulich
2017-03-20 6:11 ` Chao Gao
2017-03-15 5:11 ` [PATCH v10 6/6] passthrough/io: Fall back to remapping interrupt when we can't use " Chao Gao
2017-03-17 10:48 ` Jan Beulich
2017-03-22 6:34 ` Tian, Kevin
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=20170322001857.GA8431@skl-2s3.sh.intel.com \
--to=chao.gao@intel.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=dario.faggioli@citrix.com \
--cc=feng.wu@intel.com \
--cc=jbeulich@suse.com \
--cc=jun.nakajima@intel.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.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 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).