linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: <pbonzini@redhat.com>, <joro@8bytes.org>, <bp@alien8.de>,
	<gleb@kernel.org>, <alex.williamson@redhat.com>,
	<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<wei@redhat.com>, <sherry.hurwitz@amd.com>
Subject: Re: [PART1 RFC v2 10/10] svm: Manage vcpu load/unload when enable AVIC
Date: Mon, 14 Mar 2016 18:48:51 +0700	[thread overview]
Message-ID: <56E6A523.7040701@amd.com> (raw)
In-Reply-To: <20160309214629.GE19459@potion.brq.redhat.com>

Hi,

On 03/10/2016 04:46 AM, Radim Krčmář wrote:
> 2016-03-04 14:46-0600, Suravee Suthikulpanit:
>> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>
>> When a vcpu is loaded/unloaded to a physical core, we need to update
>> information in the Physical APIC-ID table accordingly.
>>
>> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> ---
>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> @@ -1508,6 +1510,146 @@ static int avic_vcpu_init(struct kvm *kvm, struct vcpu_svm *svm, int id)
>> +static inline int
>> +avic_update_iommu(struct kvm_vcpu *vcpu, int cpu, phys_addr_t pa, bool r)
>> +{
>> +	if (!kvm_arch_has_assigned_device(vcpu->kvm))
>> +		return 0;
>> +
>> +	/* TODO: We will hook up with IOMMU API at later time */
>
> (It'd be best to drop avic_update_iommu from this series and introduce
>   it when merging iommu support.)
>

I just kept it there to make code merging b/w part1 and 2 that I have 
been testing simpler. I didn't think it would cause much confusion. But 
if you think that might be the case, I can drop it for now.

>> +	return 0;
>> +}
>> +
>> +static int avic_vcpu_load(struct kvm_vcpu *vcpu, int cpu, bool is_load)
>
> This function does a lot and there is only one thing that must be done
> in svm_vcpu_load:  change host physical APIC ID if the CPU changed.
> The rest can be done elsewhere:
>   - is_running when blocking.

I added the logic here to track if the is_running is set when unloading 
since I noticed the case when the vCPU is busy doing some work for the 
guest, then get unloaded and later on get loaded w/o 
blocking/unblocking. So, in theory, it should be be set to running 
during unloaded period, and it should restore this flag if it is loaded 
again.

>   - kb_pg_ptr when the pointer changes = only on initialization?

The reason I put this here mainly because it is a convenient place to 
set the vAPIC bakcing page address since we already have to set up the 
host physical APIC id. I guess I can try setting this separately during 
vcpu create. But I don't think it would make much difference.

>   - valid when the kb_pg_ptr is valid = always for existing VCPUs?

According to the programming manual, the valid bit is set when we set 
the host physical APIC ID. However, in theory, the vAPIC backing page 
address is required for AVIC hardware to set bits in IRR register, while 
the host physical APIC ID is needed for sending doorbell to the target 
physical core. So, I would actually interpret the valid bit as it should 
be set when the vAPIC backing address is set.

In the current implementation, the valid bit is set during vcpu load, 
but is not unset it when unload. This actually reflect the 
interpretation of the description above.

If we decide to move the setting of vAPIC backing page address to the 
vcpu create phrase, we would set the valid bit at that point as well.

Please let me know if you think differently.

>> +static int avic_set_running(struct kvm_vcpu *vcpu, bool is_run)
>
> avic_set_running should get address of the entry and write is_run to it.
> (No need to touch avic_bk_page, h_phy_apic_id or do bound checks.)
>
> I think you can cache the physical apic id table entry in *vcpu, so both
> functions are going to be very simple.
>

I was actually thinking about doing this. Lemme try to come up with the 
logic to cache this.

Thanks,
Suravee

  parent reply	other threads:[~2016-03-14 11:49 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 20:45 [PART1 RFC v2 00/10] KVM: x86: Introduce SVM AVIC support Suravee Suthikulpanit
2016-03-04 20:45 ` [PART1 RFC v2 01/10] KVM: x86: Misc LAPIC changes to exposes helper functions Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 02/10] KVM: x86: Introducing kvm_x86_ops VCPU blocking/unblocking Suravee Suthikulpanit
2016-03-07 15:42   ` Paolo Bonzini
2016-03-14  6:19     ` Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 03/10] svm: Introduce new AVIC VMCB registers Suravee Suthikulpanit
2016-03-07 15:44   ` Paolo Bonzini
2016-03-14  7:41     ` Suravee Suthikulpanit
2016-03-14 12:25       ` Paolo Bonzini
2016-03-15 12:51         ` Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 04/10] svm: clean up V_TPR, V_IRQ, V_INTR_PRIO, and V_INTR_MASKING Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 05/10] KVM: x86: Detect and Initialize AVIC support Suravee Suthikulpanit
2016-03-07 16:41   ` Paolo Bonzini
2016-03-15 17:09     ` Suravee Suthikulpanit
2016-03-15 17:22       ` Paolo Bonzini
2016-03-16  6:22         ` Suravee Suthikulpanit
2016-03-16  7:20           ` Paolo Bonzini
2016-03-16  8:21             ` Suravee Suthikulpanit
2016-03-16 11:12               ` Paolo Bonzini
2016-03-04 20:46 ` [PART1 RFC v2 06/10] svm: Add interrupt injection via AVIC Suravee Suthikulpanit
2016-03-07 15:36   ` Paolo Bonzini
2016-03-08 21:54     ` Radim Krčmář
2016-03-09 11:10       ` Paolo Bonzini
2016-03-09 16:00         ` Radim Krčmář
2016-03-14  9:41           ` Suravee Suthikulpanit
2016-03-14 12:27             ` Paolo Bonzini
2016-03-14  9:50         ` Suravee Suthikulpanit
2016-03-14  5:25     ` Suravee Suthikulpanit
2016-03-14  8:54       ` Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 07/10] svm: Add VMEXIT handlers for AVIC Suravee Suthikulpanit
2016-03-07 15:58   ` Paolo Bonzini
2016-03-08 22:05     ` Radim Krčmář
2016-03-09 10:56       ` Paolo Bonzini
2016-03-09 20:55   ` Radim Krčmář
2016-03-10 19:34     ` Radim Krčmář
2016-03-10 19:54       ` Paolo Bonzini
2016-03-10 20:44         ` Radim Krčmář
2016-03-17  3:58     ` Suravee Suthikulpanit
2016-03-17  9:35       ` Paolo Bonzini
2016-03-17 19:44     ` Suravee Suthikulpanit
2016-03-17 20:27       ` [PATCH] KVM: split kvm_vcpu_wake_up from kvm_vcpu_kick Radim Krčmář
2016-03-18  5:13         ` Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 08/10] svm: Do not expose x2APIC when enable AVIC Suravee Suthikulpanit
2016-03-04 20:46 ` [PART1 RFC v2 09/10] svm: Do not intercept CR8 " Suravee Suthikulpanit
2016-03-07 15:39   ` Paolo Bonzini
2016-03-14  6:09     ` Suravee Suthikulpanit
2016-03-14 12:28       ` Paolo Bonzini
2016-03-04 20:46 ` [PART1 RFC v2 10/10] svm: Manage vcpu load/unload " Suravee Suthikulpanit
2016-03-09 21:46   ` Radim Krčmář
2016-03-10 14:01     ` Radim Krčmář
2016-03-14 11:58       ` Suravee Suthikulpanit
2016-03-14 16:54         ` Radim Krčmář
2016-03-14 11:48     ` Suravee Suthikulpanit [this message]
2016-03-14 16:40       ` Radim Krčmář

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=56E6A523.7040701@amd.com \
    --to=suravee.suthikulpanit@amd.com \
    --cc=alex.williamson@redhat.com \
    --cc=bp@alien8.de \
    --cc=gleb@kernel.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=sherry.hurwitz@amd.com \
    --cc=wei@redhat.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 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).