mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Zhenzhong Duan <zhenzhong.duan@oracle.com>
To: Juergen Gross <jgross@suse.com>, linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de, mingo@kernel.org, bp@alien8.de,
	hpa@zytor.com, boris.ostrovsky@oracle.com,
	sstabellini@kernel.org, peterz@infradead.org,
	srinivas.eeda@oracle.com, Ingo Molnar <mingo@redhat.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 5/7] x86/xen: nopv parameter support for HVM guest
Date: Wed, 26 Jun 2019 16:56:46 +0800	[thread overview]
Message-ID: <f5478215-0e1a-8a2a-19ec-378ac5849936@oracle.com> (raw)
In-Reply-To: <99a28880-c2bf-e328-ee52-afc782af3b74@suse.com>


On 2019/6/25 20:31, Juergen Gross wrote:
> On 24.06.19 14:02, Zhenzhong Duan wrote:
>> PVH guest needs PV extentions to work, so nopv parameter is ignored
>> for PVH but not for HVM guest.
>>
>> In order for nopv parameter to take effect for HVM guest, we need to
>> distinguish between PVH and HVM guest early in hypervisor detection
>> code. By moving the detection of PVH in xen_platform_hvm(),
>> xen_pvh_domain() could be used for that purpose.
>>
>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: Stefano Stabellini <sstabellini@kernel.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: xen-devel@lists.xenproject.org
>> ---
>>   arch/x86/xen/enlighten_hvm.c | 18 ++++++++++++------
>>   1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
>> index 7fcb4ea..26939e7 100644
>> --- a/arch/x86/xen/enlighten_hvm.c
>> +++ b/arch/x86/xen/enlighten_hvm.c
>> @@ -25,6 +25,7 @@
>>   #include "mmu.h"
>>   #include "smp.h"
>>   +extern bool nopv;
>>   static unsigned long shared_info_pfn;
>>     void xen_hvm_init_shared_info(void)
>> @@ -226,20 +227,24 @@ static uint32_t __init xen_platform_hvm(void)
>>       if (xen_pv_domain())
>>           return 0;
>>   +#ifdef CONFIG_XEN_PVH
>> +    /* Test for PVH domain (PVH boot path taken overrides ACPI 
>> flags). */
>> +    if (!x86_platform.legacy.rtc && x86_platform.legacy.no_vga)
>> +        xen_pvh = true;
>
> Sorry, this won't work, as ACPI tables are scanned only some time later.
Hmm, right. Thanks for point out.
>
> You can test for xen_pvh being true here (for the case where the guest
> has been booted via the Xen-PVH boot entry) and handle that case, but
> the case of a PVH guest started via the normal boot entry (like via
> grub2) and nopv specified is difficult. The only idea I have right now
> would be to use another struct hypervisor_x86 for that case which will
> only be used for Xen HVM/PVH _and_ nopv specified. It should be a copy
> of the bare metal variant, but a special guest_late_init member issuing
> a big fat warning in case PVH is being detected.

After that warning, I guess PVH will run into hang finally? If it's 
true, BUG() is better?

Adding another hypervisor_x86 is a bit redundant, I think of below change.

I'll test it tomorrow. But appreciate your suggestion whether it's 
feasible. Thanks

--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -25,6 +25,7 @@
  #include "mmu.h"
  #include "smp.h"

+extern bool nopv;
  static unsigned long shared_info_pfn;

  void xen_hvm_init_shared_info(void)
@@ -221,11 +222,37 @@ bool __init xen_hvm_need_lapic(void)
         return true;
  }

+static __init void xen_hvm_nopv_guest_late_init(void)
+{
+#ifdef CONFIG_XEN_PVH
+       if (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga)
+               return;
+
+       /* PVH detected. */
+       xen_pvh = true;
+
+       printk(KERN_CRIT "nopv parameter isn't supported in PVH guest\n");
+       BUG();
+#endif
+}
+
+
  static uint32_t __init xen_platform_hvm(void)
  {
         if (xen_pv_domain())
                 return 0;

+       if (xen_pvh_domain() && nopv)
+       {
+       /* guest booting via the Xen-PVH boot entry goes here */
+               printk(KERN_INFO "nopv parameter is ignored in PVH 
guest\n");
+       }
+       else if (nopv)
+       {
+       /* guest booting via normal boot entry (like via grub2) goes here */
+               x86_init.hyper.guest_late_init = 
xen_hvm_nopv_guest_late_init;
+               return 0;
+       }
         return xen_cpuid_base();
  }

@@ -258,4 +285,5 @@ static __init void xen_hvm_guest_late_init(void)
         .init.init_mem_mapping  = xen_hvm_init_mem_mapping,
         .init.guest_late_init   = xen_hvm_guest_late_init,
         .runtime.pin_vcpu       = xen_pin_vcpu,
+       .ignore_nopv            = true,
  };


  reply	other threads:[~2019-06-26  8:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24 12:02 [PATCH v2 0/7] misc fixes to PV extentions code Zhenzhong Duan
2019-06-24 12:02 ` [PATCH v2 1/7] x86/xen: Mark xen_hvm_need_lapic() and xen_hvm_need_lapic() as __init Zhenzhong Duan
2019-06-24 12:02 ` [PATCH v2 2/7] x86/jailhouse: Mark jailhouse_x2apic_available " Zhenzhong Duan
2019-06-24 12:02 ` [PATCH v2 3/7] x86: Add nopv parameter to disable PV extensions Zhenzhong Duan
2019-06-26  9:38   ` Juergen Gross
2019-06-24 12:02 ` [PATCH v2 4/7] Revert "xen: Introduce 'xen_nopv' to disable PV extensions for HVM guests." Zhenzhong Duan
2019-06-26  9:39   ` Juergen Gross
2019-06-26 13:48     ` Thomas Gleixner
2019-06-24 12:02 ` [PATCH v2 5/7] x86/xen: nopv parameter support for HVM guest Zhenzhong Duan
2019-06-25 12:31   ` Juergen Gross
2019-06-26  8:56     ` Zhenzhong Duan [this message]
2019-06-26  9:03       ` Juergen Gross
2019-06-24 12:02 ` [PATCH v2 6/7] locking/spinlocks, paravirt, hyperv: Correct the hv_nopvspin case Zhenzhong Duan
2019-06-27 22:28   ` Sasha Levin
2019-06-28  0:53     ` Zhenzhong Duan
2019-06-24 12:02 ` [PATCH v2 7/7] Revert "x86/paravirt: Set up the virt_spin_lock_key after static keys get initialized" Zhenzhong Duan
2019-06-26 13:39 ` [PATCH v2 0/7] misc fixes to PV extentions code Thomas Gleixner
2019-06-27  8:47   ` Zhenzhong Duan
2019-06-27 12:24     ` Thomas Gleixner

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=f5478215-0e1a-8a2a-19ec-378ac5849936@oracle.com \
    --to=zhenzhong.duan@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=srinivas.eeda@oracle.com \
    --cc=sstabellini@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=xen-devel@lists.xenproject.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

all inboxes | Powered by JetHome®