From: Dario Faggioli <dario.faggioli@citrix.com>
To: Feng Wu <feng.wu@intel.com>, xen-devel@lists.xen.org
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Kevin Tian <kevin.tian@intel.com>, Keir Fraser <keir@xen.org>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling
Date: Wed, 23 Dec 2015 03:21:08 +0100 [thread overview]
Message-ID: <1450837268.19320.192.camel@citrix.com> (raw)
In-Reply-To: <1449131734-3578-7-git-send-email-feng.wu@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 5179 bytes --]
Here I am,
On Thu, 2015-12-03 at 16:35 +0800, Feng Wu wrote:
> This is the core logic handling for VT-d posted-interrupts. Basically
> it
> deals with how and when to update posted-interrupts during the
> following
> scenarios:
> - vCPU is preempted
> - vCPU is slept
> - vCPU is blocked
>
> [..]
>
Thanks for changing the changelog, making it look like much more an
high level description of what happens and why.
> v10:
> - Check iommu_intpost first
> - Remove pointless checking of has_hvm_container_vcpu(v)
> - Rename 'vmx_pi_state_change' to 'vmx_pi_state_to_normal'
> - Since vcpu_unblock() doesn't acquire 'pi_blocked_vcpu_lock', we
> don't need use another list to save the vCPUs with 'ON' set, just
> directly call vcpu_unblock(v).
>
This were all my comments to v9 and, I've verified in the patch, they
actually have been all addressed... Thanks for this.
This patch looks fine to me now. There are a few minor issues that I'll
raise inline, but in general, I think this is a good design, and the
patch does it job fine at implementing it.
Here they are the detailed comments.
First of all, trying to apply it, I got:
<stdin>:105: trailing whitespace.
void arch_vcpu_block(struct vcpu *v)
<stdin>:106: trailing whitespace.
{
<stdin>:107: trailing whitespace.
if ( v->arch.vcpu_block )
<stdin>:108: trailing whitespace.
v->arch.vcpu_block(v);
<stdin>:109: trailing whitespace.
}
It may not be accurate, though (i.e., it may be due to what I used for
applying the patches), so, please, double check.
And there are also a couple of long lines, which you should split.
> +void vmx_vcpu_block(struct vcpu *v)
> +{
> + unsigned long flags;
> + struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> + if ( !has_arch_pdevs(v->domain) )
> + return;
> +
> + ASSERT(v->arch.hvm_vmx.pi_block_cpu == NR_CPUS);
> +
> + /*
> + * The vCPU is blocking, we need to add it to one of the per
> pCPU lists.
> + * We save v->processor to v->arch.hvm_vmx.pi_block_cpu and use
> it for
> + * the per-CPU list, we also save it to posted-interrupt
> descriptor and
> + * make it as the destination of the wake-up notification event.
> + */
> + v->arch.hvm_vmx.pi_block_cpu = v->processor;
> +
> + spin_lock_irqsave(&per_cpu(pi_blocked_vcpu_lock,
> + v->arch.hvm_vmx.pi_block_cpu), flags);
> + list_add_tail(&v->arch.hvm_vmx.pi_blocked_vcpu_list,
> + &per_cpu(pi_blocked_vcpu, v-
> >arch.hvm_vmx.pi_block_cpu));
> + spin_unlock_irqrestore(&per_cpu(pi_blocked_vcpu_lock,
> + v->arch.hvm_vmx.pi_block_cpu), flags);
> +
> + ASSERT(!pi_test_sn(pi_desc));
> +
> + /*
> + * We don't need to set the 'NDST' field, since it should point
> to
> + * the same pCPU as v->processor.
> + */
> +
So, maybe we can ASSERT() that?
> + write_atomic(&pi_desc->nv, pi_wakeup_vector);
> +}
> +static void vmx_pi_switch_from(struct vcpu *v)
> +{
> + struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> + if ( !iommu_intpost || !has_arch_pdevs(v->domain) ||
> + test_bit(_VPF_blocked, &v->pause_flags) )
> + return;
> +
> + /*
> + * The vCPU has been preempted or went to sleep. We don't need
> to send
> + * notification event to a non-running vcpu, the interrupt
> information
> + * will be delivered to it before VM-ENTRY when the vcpu is
> scheduled
> + * to run next time.
> + */
> + pi_set_sn(pi_desc);
> +}
> +
> +static void vmx_pi_switch_to(struct vcpu *v)
> +{
> + struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> + if ( !iommu_intpost || !has_arch_pdevs(v->domain) )
> + return;
> +
> + if ( x2apic_enabled )
> + write_atomic(&pi_desc->ndst, cpu_physical_id(v->processor));
> + else
> + write_atomic(&pi_desc->ndst,
> + MASK_INSR(cpu_physical_id(v->processor),
> + PI_xAPIC_NDST_MASK));
> +
> + pi_clear_sn(pi_desc);
>
No comment matching the one above (for pi_set_sn(), in
vmx_pi_switch_from())? I don't feel too strong about this, but it would
be nice to have both (or none, but I'd prefer both! :-D).
> +}
> +
> +static void vmx_pi_state_to_normal(struct vcpu *v)
> +{
>
I'm still a bit puzzled about the name... But it's better than in the
previous round, and I can't suggest a solution that I would like myself
better... so I'm fine with this one.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2015-12-23 2:21 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-03 8:35 [PATCH v10 0/7] Add VT-d Posted-Interrupts support Feng Wu
2015-12-03 8:35 ` [PATCH v10 1/7] VT-d Posted-intterrupt (PI) design Feng Wu
2015-12-03 8:35 ` [PATCH v10 2/7] vmx: Suppress posting interrupts when 'SN' is set Feng Wu
2015-12-03 8:35 ` [PATCH v10 3/7] vt-d: Add API to update IRTE when VT-d PI is used Feng Wu
2015-12-10 10:52 ` Tian, Kevin
2015-12-03 8:35 ` [PATCH v10 4/7] Update IRTE according to guest interrupt config changes Feng Wu
2015-12-10 10:53 ` Tian, Kevin
2015-12-03 8:35 ` [PATCH v10 5/7] vmx: Properly handle notification event when vCPU is running Feng Wu
2015-12-03 8:35 ` [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling Feng Wu
2015-12-10 11:40 ` Tian, Kevin
2015-12-11 1:58 ` Wu, Feng
2015-12-11 2:27 ` Tian, Kevin
2015-12-11 3:12 ` Wu, Feng
2015-12-21 6:43 ` Wu, Feng
2015-12-21 9:03 ` Dario Faggioli
2015-12-21 9:26 ` Wu, Feng
2015-12-23 2:21 ` Dario Faggioli [this message]
2015-12-23 2:28 ` Wu, Feng
2015-12-23 5:16 ` Tian, Kevin
2015-12-23 5:18 ` Wu, Feng
2015-12-23 4:58 ` Wu, Feng
2015-12-23 10:09 ` Jan Beulich
2016-01-18 1:20 ` Wu, Feng
2016-01-18 8:40 ` Jan Beulich
2016-01-18 8:45 ` Wu, Feng
2016-01-18 9:03 ` Jan Beulich
2016-01-19 8:48 ` Wu, Feng
2016-01-18 15:14 ` Jan Beulich
2016-01-20 7:49 ` Wu, Feng
2016-01-20 8:35 ` Jan Beulich
2016-01-20 11:12 ` Dario Faggioli
2016-01-20 11:18 ` Wu, Feng
2016-01-20 11:20 ` Wu, Feng
2016-01-20 11:35 ` Jan Beulich
2016-01-20 13:30 ` Dario Faggioli
2016-01-20 13:42 ` Wu, Feng
2016-01-25 5:26 ` Wu, Feng
2016-01-25 13:59 ` Jan Beulich
2016-01-20 13:48 ` Wu, Feng
2016-01-20 14:03 ` Jan Beulich
2016-01-21 9:05 ` Wu, Feng
2016-01-21 10:34 ` Jan Beulich
2015-12-03 8:35 ` [PATCH v10 7/7] Add a command line parameter for VT-d posted-interrupts Feng Wu
2015-12-03 11:19 ` [PATCH v10 0/7] Add VT-d Posted-Interrupts support Jan Beulich
2015-12-03 13:54 ` Wu, Feng
2015-12-10 10:48 ` Tian, Kevin
2015-12-10 13:40 ` Wu, Feng
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=1450837268.19320.192.camel@citrix.com \
--to=dario.faggioli@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=feng.wu@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--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).