From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <george.dunlap@eu.citrix.com>
Subject: Re: [PATCH v14 11/17] pvh: Set up more PV stuff in
	set_info_guest
Date: Thu, 7 Nov 2013 15:51:57 +0000
Message-ID: <527BB71D.8050103@eu.citrix.com>
References: <1383567306-6636-1-git-send-email-george.dunlap@eu.citrix.com>
	<1383567306-6636-12-git-send-email-george.dunlap@eu.citrix.com>
	<5277DF0C02000078000FF396@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <George.Dunlap@citrix.com>) id 1VeRsL-0002mu-Mh
	for xen-devel@lists.xenproject.org; Thu, 07 Nov 2013 15:52:05 +0000
In-Reply-To: <5277DF0C02000078000FF396@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

On 04/11/13 16:53, Jan Beulich wrote:
>>>> On 04.11.13 at 13:15, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> @@ -728,8 +740,21 @@ int arch_set_info_guest(
>>   
>>       if ( has_hvm_container_vcpu(v) )
>>       {
>> -        hvm_set_info_guest(v);
>> -        goto out;
>> +        hvm_set_info_guest(v, compat ? 0 : c.nat->gs_base_kernel);
> I'm afraid this isn't correct - so far gs_base_kernel didn't get used
> for HVM guests, i.e. you're changing behavior here (even if only
> in a - presumably - benign way).
>
>> +
>> +        if ( is_hvm_vcpu(v) || v->is_initialised )
>> +            goto out;
>> +
>> +        cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
> I'd recommend against using this PV construct - the 32-bit
> counterpart won't be correct to be used here once 32-bit
> support gets added.

So the plan would be that once we support 32-bit, I'd just copy the code 
from below:

     if ( !compat )
         cr3_gfn = xen_cr3_to_pfn(c.nat->ctrlreg[3]);
     else
         cr3_gfn = compat_cr3_to_pfn(c.cmp->ctrlreg[3]);

But since we know that compat is false here, it seems a bit silly to 
have the if() statement.

But there should be a "PVH 32bitfixme" here -- is that enough for now?

>
>> @@ -1426,6 +1426,11 @@ static void vmx_set_info_guest(struct vcpu *v)
>>           __vmwrite(GUEST_INTERRUPTIBILITY_INFO, intr_shadow);
>>       }
>>   
>> +    /* PVH 32bitfixme */
>> +    if ( is_pvh_vcpu(v) )
>> +        __vmwrite(GUEST_GS_BASE, gs_base_kernel);
> Oh, I see, you suppress this here. I'd really suggest adjusting the
> caller, then you don't need to do anything here afaict.

What do you mean "adjusting the caller"?  What we want for HVM guests is 
for this field to be entirely left alone, isn't it?

If we set GUEST_GS_BASE unconditionally here, the only way to effect "no 
change" is to read it and pass in the existing value, which seems kind 
of pointless.

  -George