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 v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt
Date: Fri, 31 Mar 2017 07:01:57 +0800 [thread overview]
Message-ID: <20170330230157.GA13934@skl-2s3.sh.intel.com> (raw)
In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D190C87974@SHSMSX101.ccr.corp.intel.com>
On Fri, Mar 31, 2017 at 01:46:33PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Wednesday, March 29, 2017 1:12 PM
>>
>> return entry;
>> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
>> index d53976c..5dbfe53 100644
>> --- a/xen/drivers/passthrough/io.c
>> +++ b/xen/drivers/passthrough/io.c
>> @@ -618,6 +618,8 @@ int pt_irq_destroy_bind(
>> else
>> what = "bogus";
>> }
>> + else if ( iommu_intpost && pirq && pirq_dpci->gmsi.posted )
>
>No need to check iommu_intpost. Just keep later conditions.
ok. Is it for if posted is set, the iommu_intpost should be true?
>
>btw isn't the condition be " (pirq_dpci && pirq_dpci->gmsi.posted)"?
I don't think so. pirq, not pirq_dpci, is consumed by pi_update_irte.
Furthermore if pirq_dpci is null, pirq is also null. But it is not true
in turn.
>
>> + pi_update_irte(NULL, pirq, 0);
>>
>> if ( pirq_dpci && (pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) &&
>> list_empty(&pirq_dpci->digl_list) )
>> /*
>> * This function is used to update the IRTE for posted-interrupt
>> * when guest changes MSI/MSI-X information.
>> @@ -946,17 +912,9 @@ int pi_update_irte(const struct vcpu *v, const struct
>> pirq *pirq,
>> const uint8_t gvec)
>> {
>> struct irq_desc *desc;
>> - const struct msi_desc *msi_desc;
>> - int remap_index;
>> - int rc = 0;
>> - const struct pci_dev *pci_dev;
>> - const struct acpi_drhd_unit *drhd;
>> - struct iommu *iommu;
>> - struct ir_ctrl *ir_ctrl;
>> - struct iremap_entry *iremap_entries = NULL, *p = NULL;
>> - struct iremap_entry new_ire, old_ire;
>> - const struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
>> - __uint128_t ret;
>> + struct msi_desc *msi_desc;
>> + const struct pi_desc *pi_desc = v ? &v->arch.hvm_vmx.pi_desc : NULL;
>
>will there be a case that pi_update_desc is invoked with v==NULL?
The line behind your last comment above. It is to clear 'pi_desc' and 'gvec'
fields in msi_desc when guest destroies the binding with pt-irq.
>
>> + int rc;
>>
>> desc = pirq_spin_lock_irq_desc(pirq, NULL);
>> if ( !desc )
>> @@ -968,59 +926,13 @@ int pi_update_irte(const struct vcpu *v, const
>> struct pirq *pirq,
>> rc = -ENODEV;
>> goto unlock_out;
>> }
>> -
>> - pci_dev = msi_desc->dev;
>> - if ( !pci_dev )
>> - {
>> - rc = -ENODEV;
>> - goto unlock_out;
>> - }
>> -
>> - remap_index = msi_desc->remap_index;
>> + msi_desc->pi_desc = pi_desc;
>> + msi_desc->gvec = gvec;
>
>Is it possible to see pi_desc already assigned? the name of pi_update_irte
>looks it may be invoked multiple times. If we assume a new update should
>happen only when previous one is cleaned up, then some check code
>should be added here to prove that assumption.
We don't make this assumption. I just want to track the msi's binding with
guest. If guest updates it, we updates here. If guest clears it, then we clear
it accordingly.
Thanks
Chao
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-03-30 23:01 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 5:11 [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list Chao Gao
2017-03-29 5:11 ` [PATCH v11 1/6] passthrough: don't migrate pirq when it is delivered through VT-d PI Chao Gao
2017-03-31 5:28 ` Tian, Kevin
2017-03-30 23:10 ` Chao Gao
2017-03-31 10:27 ` Jan Beulich
2017-03-31 9:31 ` Jan Beulich
2017-03-31 2:42 ` Chao Gao
2017-03-31 10:06 ` Jan Beulich
2017-03-31 3:27 ` Chao Gao
2017-03-31 10:38 ` Jan Beulich
2017-04-05 0:20 ` Chao Gao
2017-04-05 8:03 ` Jan Beulich
2017-03-29 5:11 ` [PATCH v11 2/6] VT-d: Introduce new fields in msi_desc to track binding with guest interrupt Chao Gao
2017-03-31 5:46 ` Tian, Kevin
2017-03-30 23:01 ` Chao Gao [this message]
2017-03-31 8:11 ` Jan Beulich
2017-03-31 1:13 ` Chao Gao
2017-03-31 9:48 ` Jan Beulich
2017-03-29 5:11 ` [PATCH v11 3/6] VT-d: Some cleanups Chao Gao
2017-03-29 5:11 ` [PATCH v11 4/6] VMX: Fixup PI descriptor when cpu is offline Chao Gao
2017-03-29 5:11 ` [PATCH v11 5/6] VT-d: introduce update_irte to update irte safely Chao Gao
2017-03-31 6:03 ` Tian, Kevin
2017-03-31 10:01 ` Jan Beulich
2017-04-04 19:12 ` Chao Gao
2017-04-05 7:40 ` Jan Beulich
2017-03-29 5:11 ` [PATCH v11 6/6] passthrough/io: Fall back to remapping interrupt when we can't use VT-d PI Chao Gao
2017-03-31 5:13 ` [PATCH v11 0/6] VMX: Properly handle pi descriptor and per-cpu blocking list 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=20170330230157.GA13934@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).