From: Marcelo Tosatti <mtosatti@redhat.com>
To: "Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: Gleb Natapov <gleb@redhat.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"Shan, Haitao" <haitao.shan@intel.com>,
"Zhang, Xiantao" <xiantao.zhang@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Anvin, H Peter" <h.peter.anvin@intel.com>
Subject: Re: [PATCH 2/2] x86, apicv: Add Posted Interrupt supporting
Date: Wed, 6 Feb 2013 23:23:31 -0200 [thread overview]
Message-ID: <20130207012331.GA18150@amt.cnet> (raw)
In-Reply-To: <A9667DDFB95DB7438FA9D7D576C3D87E0999B4FA@SHSMSX101.ccr.corp.intel.com>
> >>>>>>>> According the SDM, software should not touch the IRR when target
> > vcpu
> >>> is
> >>>>>>> running. Instead, use locked way to access PIR. So your solution may
> >>>>>>> wrong. Then your apicv patches are broken, because they do exactly
> >>>>>>> that.
> >>>>>> Which code is broken?
> >>>>>>
> >>>>> The one that updates IRR directly on the apic page.
> >>>> No, all the updates are ensuring the target vcpu is not running. So
> >>>> it's safe to touch IRR.
> >>>>
> >>> Not at all. Read the code.
> >> Sorry. I still cannot figure out which code is wrong. All the places
> >> call sync_pir_to_irr() are on target vcpu. Can you point out the code?
> >> Thanks.
> >>
> > I am taking about vapic patches which are already in, not pir patches.
> Yes, but the issue will be fixed with pir patches. With posted interrupt, it will touch PIR instead IRR and access PIR is allowed by HW.
>
> Best regards,
> Yang
>
>From http://www.mail-archive.com/kvm@vger.kernel.org/msg82824.html:
"
> 2. Section 29.6 mentions that "Use of the posted-interrupt descriptor
> differs from that of other data structures that are referenced by
> pointers in a VMCS. There is a general requirement that software
> ensure
> that each such data structure is modified only when no logical
> processor
> with a current VMCS that references it is in VMX non-root operation.
> That requirement does not apply to the posted-interrupt descriptor.
> There is a requirement, however, that such modifications be done using
> locked read-modify-write instructions."
>
> The APIC virtual page is being modified by a CPU while a logical
> processor with current VMCS that references it is in VMX non-root
> operation, in fact even modifying the APIC virtual page with EOI
> virtualizaton, virtual interrupt delivery, etc. What are the
> requirements in this case?
It should be same with posted interrupt. Software must ensure to use
atomic access to virtual apic page.
"
Can this point be clarified? Software can or cannot access virtual APIC
page while VMCS that references it is in VMX non-root operation?
Because if it cannot, then it means the current code is broken and
VID usage without PIR should not be allowed.
next prev parent reply other threads:[~2013-02-07 1:24 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-13 7:29 [PATCH 0/2] KVM: Add posted interrupt supporting Yang Zhang
2012-12-13 7:29 ` [PATCH 1/2] x86: Enable ack interrupt on vmexit Yang Zhang
2012-12-13 7:51 ` Gleb Natapov
2012-12-13 7:54 ` Zhang, Yang Z
2012-12-13 7:58 ` Gleb Natapov
2012-12-13 8:03 ` Zhang, Yang Z
2012-12-13 8:05 ` Gleb Natapov
2012-12-13 8:19 ` Zhang, Yang Z
2012-12-13 8:22 ` Gleb Natapov
2012-12-13 8:23 ` Zhang, Yang Z
2012-12-16 13:26 ` Zhang, Yang Z
2012-12-18 9:11 ` Gleb Natapov
2012-12-13 7:29 ` [PATCH 2/2] x86, apicv: Add Posted Interrupt supporting Yang Zhang
2013-01-22 22:59 ` Marcelo Tosatti
2013-01-23 5:09 ` Zhang, Yang Z
2013-01-24 23:43 ` Marcelo Tosatti
2013-01-25 0:40 ` Zhang, Yang Z
2013-01-30 23:03 ` Marcelo Tosatti
2013-01-30 23:57 ` Marcelo Tosatti
2013-01-31 7:35 ` Gleb Natapov
2013-01-31 9:43 ` Gleb Natapov
2013-01-31 13:32 ` Marcelo Tosatti
2013-01-31 13:38 ` Gleb Natapov
2013-01-31 13:44 ` Marcelo Tosatti
2013-01-31 13:55 ` Gleb Natapov
2013-02-04 0:57 ` Marcelo Tosatti
2013-02-04 9:10 ` Zhang, Yang Z
2013-02-04 9:55 ` Gleb Natapov
2013-02-04 14:43 ` Marcelo Tosatti
2013-02-04 17:13 ` Gleb Natapov
2013-02-04 19:59 ` Marcelo Tosatti
2013-02-04 20:47 ` Marcelo Tosatti
2013-02-05 5:57 ` Zhang, Yang Z
2013-02-05 8:00 ` Gleb Natapov
2013-02-05 10:35 ` Zhang, Yang Z
2013-02-05 10:54 ` Gleb Natapov
2013-02-05 10:58 ` Zhang, Yang Z
2013-02-05 11:16 ` Gleb Natapov
2013-02-05 13:26 ` Zhang, Yang Z
2013-02-05 13:29 ` Gleb Natapov
2013-02-05 13:40 ` Zhang, Yang Z
2013-02-05 13:43 ` Gleb Natapov
2013-02-07 1:23 ` Marcelo Tosatti [this message]
2013-02-05 7:32 ` Gleb Natapov
2013-02-06 22:49 ` Marcelo Tosatti
2013-02-07 0:24 ` Marcelo Tosatti
2013-02-07 13:52 ` Gleb Natapov
2013-02-08 2:07 ` Marcelo Tosatti
2013-02-08 12:18 ` Gleb Natapov
2013-02-07 14:01 ` Gleb Natapov
2013-02-07 21:49 ` Marcelo Tosatti
2013-02-08 12:28 ` Gleb Natapov
2013-02-08 13:46 ` Marcelo Tosatti
2013-01-31 9:37 ` Gleb Natapov
2013-02-04 9:11 ` Zhang, Yang Z
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=20130207012331.GA18150@amt.cnet \
--to=mtosatti@redhat.com \
--cc=gleb@redhat.com \
--cc=h.peter.anvin@intel.com \
--cc=haitao.shan@intel.com \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=xiantao.zhang@intel.com \
--cc=yang.z.zhang@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.