* Re: [PATCH] video: hyperv_fb: Add the support of hibernation
From: Sasha Levin @ 2019-10-01 18:38 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
b.zolnierkie@samsung.com, linux-hyperv@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Kelley
In-Reply-To: <1568244833-66476-1-git-send-email-decui@microsoft.com>
On Wed, Sep 11, 2019 at 11:34:10PM +0000, Dexuan Cui wrote:
>This patch depends on the vmbus side change of the definition of
>struct hv_driver.
>
>Signed-off-by: Dexuan Cui <decui@microsoft.com>
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] scsi: storvsc: Add the support of hibernation
From: Sasha Levin @ 2019-10-01 18:38 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Dexuan Cui, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
jejb@linux.ibm.com, linux-hyperv@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <yq1zhj7byph.fsf@oracle.com>
On Fri, Sep 13, 2019 at 06:47:38PM -0400, Martin K. Petersen wrote:
>
>Dexuan,
>
>> When we're in storvsc_suspend(), we're sure the SCSI layer has
>> quiesced the scsi device by scsi_bus_suspend() -> ... ->
>> scsi_device_quiesce(), so the low level SCSI adapter driver only needs
>> to suspend/resume its own state.
>
>Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] HID: hyperv: Add the support of hibernation
From: Sasha Levin @ 2019-10-01 18:40 UTC (permalink / raw)
To: Dexuan Cui
Cc: Jiri Kosina, KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
benjamin.tissoires@redhat.com, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <PU1P153MB01698048162343130F34DAE0BF830@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Sun, Sep 29, 2019 at 05:44:09PM +0000, Dexuan Cui wrote:
>> From: Sasha Levin <sashal@kernel.org>
>> Dexuan, I've been silently ignoring your patches for the past few weeks
>> for the same reason as Jiri has mentioned. I'll pick them all up once
>> the 5.4 merge window closes in a few days.
>
>Thanks, Sasha!
>
>BTW, I'll post a v2 for this patch, as IMO I may be able to get rid of the
>mousevsc_pm_notify in this patch by disabling the channel callback
>in the suspend function.
Okay, I'm ignoring this patch for now then.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2] hv_sock: Add the support of hibernation
From: Sasha Levin @ 2019-10-01 18:42 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
davem@davemloft.net, linux-hyperv@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <1569447243-27433-1-git-send-email-decui@microsoft.com>
On Wed, Sep 25, 2019 at 09:34:13PM +0000, Dexuan Cui wrote:
>Add the necessary dummy callbacks for hibernation.
>
>Signed-off-by: Dexuan Cui <decui@microsoft.com>
>Acked-by: David S. Miller <davem@davemloft.net>
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Sasha Levin @ 2019-10-01 18:45 UTC (permalink / raw)
To: Wei Hu
Cc: Michael Kelley, rdunlap@infradead.org, shc_work@mail.ru,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
alexandre.belloni@bootlin.com, baijiaju1990@gmail.com,
fthain@telegraphics.com.au, info@metux.net,
linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Stephen Hemminger, Haiyang Zhang, KY Srinivasan, Dexuan Cui
In-Reply-To: <20190913060209.3604-1-weh@microsoft.com>
On Fri, Sep 13, 2019 at 06:02:55AM +0000, Wei Hu wrote:
>Without deferred IO support, hyperv_fb driver informs the host to refresh
>the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
>is screen update or not. This patch supports deferred IO for screens in
>graphics mode and also enables the frame buffer on-demand refresh. The
>highest refresh rate is still set at 20Hz.
>
>Currently Hyper-V only takes a physical address from guest as the starting
>address of frame buffer. This implies the guest must allocate contiguous
>physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
>accept address from MMIO region as frame buffer address. Due to these
>limitations on Hyper-V host, we keep a shadow copy of frame buffer
>in the guest. This means one more copy of the dirty rectangle inside
>guest when doing the on-demand refresh. This can be optimized in the
>future with help from host. For now the host performance gain from deferred
>IO outweighs the shadow copy impact in the guest.
>
>Signed-off-by: Wei Hu <weh@microsoft.com>
What tree is this based on? I can't get it to apply.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Sasha Levin @ 2019-10-01 18:48 UTC (permalink / raw)
To: Michael Kelley
Cc: Wei Hu, rdunlap@infradead.org, shc_work@mail.ru,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
alexandre.belloni@bootlin.com, baijiaju1990@gmail.com,
info@metux.net, linux-hyperv@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Hemminger, Haiyang Zhang,
KY Srinivasan, Dexuan Cui
In-Reply-To: <DM5PR21MB01375E8543451D4550D622CDD7880@DM5PR21MB0137.namprd21.prod.outlook.com>
On Fri, Sep 20, 2019 at 05:26:34PM +0000, Michael Kelley wrote:
>From: Michael Kelley <mikelley@microsoft.com> Sent: Wednesday, September 18, 2019 2:48 PM
>> >
>> > Without deferred IO support, hyperv_fb driver informs the host to refresh
>> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
>> > is screen update or not. This patch supports deferred IO for screens in
>> > graphics mode and also enables the frame buffer on-demand refresh. The
>> > highest refresh rate is still set at 20Hz.
>> >
>> > Currently Hyper-V only takes a physical address from guest as the starting
>> > address of frame buffer. This implies the guest must allocate contiguous
>> > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
>> > accept address from MMIO region as frame buffer address. Due to these
>> > limitations on Hyper-V host, we keep a shadow copy of frame buffer
>> > in the guest. This means one more copy of the dirty rectangle inside
>> > guest when doing the on-demand refresh. This can be optimized in the
>> > future with help from host. For now the host performance gain from deferred
>> > IO outweighs the shadow copy impact in the guest.
>> >
>> > Signed-off-by: Wei Hu <weh@microsoft.com>
>
>Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer
>driver should be ready. Both patches affect only the Hyper-V frame buffer
>driver so can go through the Hyper-V tree. Can you pick these up? Thx.
I can't get this to apply anywhere, what tree is it based on?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3] Drivers: hv: vmbus: Fix harmless building warnings without CONFIG_PM_SLEEP
From: Sasha Levin @ 2019-10-01 18:50 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley, arnd@arndb.de
In-Reply-To: <1569436998-130708-1-git-send-email-decui@microsoft.com>
On Wed, Sep 25, 2019 at 06:43:57PM +0000, Dexuan Cui wrote:
>If CONFIG_PM_SLEEP is not set, we can comment out these functions to avoid
>the below warnings:
>
>drivers/hv/vmbus_drv.c:2208:12: warning: ‘vmbus_bus_resume’ defined but not used [-Wunused-function]
>drivers/hv/vmbus_drv.c:2128:12: warning: ‘vmbus_bus_suspend’ defined but not used [-Wunused-function]
>drivers/hv/vmbus_drv.c:937:12: warning: ‘vmbus_resume’ defined but not used [-Wunused-function]
>drivers/hv/vmbus_drv.c:918:12: warning: ‘vmbus_suspend’ defined but not used [-Wunused-function]
>
>Fixes: 271b2224d42f ("Drivers: hv: vmbus: Implement suspend/resume for VSC drivers for hibernation")
>Fixes: f53335e3289f ("Drivers: hv: vmbus: Suspend/resume the vmbus itself for hibernation")
>Reported-by: Arnd Bergmann <arnd@arndb.de>
>Reviewed-by: Michael Kelley <mikelley@microsoft.com>
>Signed-off-by: Dexuan Cui <decui@microsoft.com>
I've queued this up for hyperv-fixes.
>In v3:
> Add Michael's Reviewed-by.
> No other change.
There's really no need to re-spin just to add tags :)
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2] scsi: storvsc: Add the support of hibernation
From: Sasha Levin @ 2019-10-01 18:51 UTC (permalink / raw)
To: Dexuan Cui
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
jejb@linux.ibm.com, martin.petersen@oracle.com,
linux-hyperv@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Kelley
In-Reply-To: <1569442244-16726-1-git-send-email-decui@microsoft.com>
On Wed, Sep 25, 2019 at 08:11:08PM +0000, Dexuan Cui wrote:
>When we're in storvsc_suspend(), we're sure the SCSI layer has quiesced the
>scsi device by scsi_bus_suspend() -> ... -> scsi_device_quiesce(), so the
>low level SCSI adapter driver only needs to suspend/resume its own state.
>
>Signed-off-by: Dexuan Cui <decui@microsoft.com>
>Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
>
>---
>
>This patch is basically a pure Hyper-V specific change and it has a
>build dependency on the commit 271b2224d42f ("Drivers: hv: vmbus: Implement
>suspend/resume for VSC drivers for hibernation"), which is on Sasha Levin's
>Hyper-V tree's hyperv-next branch:
>https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git/log/?h=hyperv-next
>
>I request this patch should go through Sasha's tree rather than the
>SCSI tree.
>
>In v2:
> Added Acked-by from Martin.
>
> @Sasha: I think the patch can go through the hyper-v tree, since
> we have the Ack from Martin. :-)
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2][PATCH net] hv_netvsc: Add the support of hibernation
From: Sasha Levin @ 2019-10-01 18:59 UTC (permalink / raw)
To: Haiyang Zhang
Cc: Dexuan Cui, KY Srinivasan, Stephen Hemminger, davem@davemloft.net,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Michael Kelley
In-Reply-To: <DM6PR21MB1337194387A53DF549398F1ACA870@DM6PR21MB1337.namprd21.prod.outlook.com>
On Wed, Sep 25, 2019 at 10:23:28PM +0000, Haiyang Zhang wrote:
>
>
>> -----Original Message-----
>> From: Dexuan Cui <decui@microsoft.com>
>> Sent: Wednesday, September 25, 2019 6:04 PM
>> To: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
>> <haiyangz@microsoft.com>; Stephen Hemminger
>> <sthemmin@microsoft.com>; sashal@kernel.org; davem@davemloft.net;
>> linux-hyperv@vger.kernel.org; netdev@vger.kernel.org; linux-
>> kernel@vger.kernel.org; Michael Kelley <mikelley@microsoft.com>
>> Cc: Dexuan Cui <decui@microsoft.com>
>> Subject: [PATCH v2][PATCH net] hv_netvsc: Add the support of hibernation
>>
>> The existing netvsc_detach() and netvsc_attach() APIs make it easy to
>> implement the suspend/resume callbacks.
>>
>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>
>Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH net v3] vsock: Fix a lockdep warning in __vsock_release()
From: David Miller @ 2019-10-02 1:23 UTC (permalink / raw)
To: decui
Cc: kys, haiyangz, sthemmin, sashal, stefanha, gregkh, arnd,
deepa.kernel, ytht.net, tglx, netdev, linux-kernel, linux-hyperv,
kvm, virtualization, mikelley, sgarzare, jhansen
In-Reply-To: <1569868998-56603-1-git-send-email-decui@microsoft.com>
From: Dexuan Cui <decui@microsoft.com>
Date: Mon, 30 Sep 2019 18:43:50 +0000
> Lockdep is unhappy if two locks from the same class are held.
>
> Fix the below warning for hyperv and virtio sockets (vmci socket code
> doesn't have the issue) by using lock_sock_nested() when __vsock_release()
> is called recursively:
...
> Tested-by: Stefano Garzarella <sgarzare@redhat.com>
> Signed-off-by: Dexuan Cui <decui@microsoft.com>
Applied, thanks.
^ permalink raw reply
* RE: [PATCH v5] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Dexuan Cui @ 2019-10-02 7:52 UTC (permalink / raw)
To: Sasha Levin, Wei Hu
Cc: Michael Kelley, rdunlap@infradead.org, shc_work@mail.ru,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
alexandre.belloni@bootlin.com, baijiaju1990@gmail.com,
fthain@telegraphics.com.au, info@metux.net,
linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Stephen Hemminger, Haiyang Zhang, KY Srinivasan
In-Reply-To: <20191001184526.GE8171@sasha-vm>
> From: Sasha Levin <sashal@kernel.org>
> Sent: Tuesday, October 1, 2019 11:45 AM
> To: Wei Hu <weh@microsoft.com>
>
> On Fri, Sep 13, 2019 at 06:02:55AM +0000, Wei Hu wrote:
> >Without deferred IO support, hyperv_fb driver informs the host to refresh
> >the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> >is screen update or not. This patch supports deferred IO for screens in
> >graphics mode and also enables the frame buffer on-demand refresh. The
> >highest refresh rate is still set at 20Hz.
> >
> >Currently Hyper-V only takes a physical address from guest as the starting
> >address of frame buffer. This implies the guest must allocate contiguous
> >physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
> >accept address from MMIO region as frame buffer address. Due to these
> >limitations on Hyper-V host, we keep a shadow copy of frame buffer
> >in the guest. This means one more copy of the dirty rectangle inside
> >guest when doing the on-demand refresh. This can be optimized in the
> >future with help from host. For now the host performance gain from deferred
> >IO outweighs the shadow copy impact in the guest.
> >
> >Signed-off-by: Wei Hu <weh@microsoft.com>
>
> What tree is this based on? I can't get it to apply.
>
> Thanks,
> Sasha
Please use Wei's v6 patch, which can apply on today's hyperv/linux.git/s hyperv-next branch.
Thanks,
-- Dexuan
^ permalink raw reply
* RE: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Dexuan Cui @ 2019-10-02 8:09 UTC (permalink / raw)
To: Sasha Levin, Michael Kelley
Cc: Wei Hu, rdunlap@infradead.org, shc_work@mail.ru,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
alexandre.belloni@bootlin.com, baijiaju1990@gmail.com,
info@metux.net, linux-hyperv@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Hemminger, Haiyang Zhang,
KY Srinivasan
In-Reply-To: <20191001184828.GF8171@sasha-vm>
> -----Original Message-----
> From: Sasha Levin <sashal@kernel.org>
> Sent: Tuesday, October 1, 2019 11:48 AM
>
> On Fri, Sep 20, 2019 at 05:26:34PM +0000, Michael Kelley wrote:
> >From: Michael Kelley <mikelley@microsoft.com> Sent: Wednesday,
> September 18, 2019 2:48 PM
> >> >
> >> > Without deferred IO support, hyperv_fb driver informs the host to refresh
> >> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> >> > is screen update or not. This patch supports deferred IO for screens in
> >> > graphics mode and also enables the frame buffer on-demand refresh. The
> >> > highest refresh rate is still set at 20Hz.
> >> >
> >> > Currently Hyper-V only takes a physical address from guest as the starting
> >> > address of frame buffer. This implies the guest must allocate contiguous
> >> > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
> >> > accept address from MMIO region as frame buffer address. Due to these
> >> > limitations on Hyper-V host, we keep a shadow copy of frame buffer
> >> > in the guest. This means one more copy of the dirty rectangle inside
> >> > guest when doing the on-demand refresh. This can be optimized in the
> >> > future with help from host. For now the host performance gain from
> deferred
> >> > IO outweighs the shadow copy impact in the guest.
> >> >
> >> > Signed-off-by: Wei Hu <weh@microsoft.com>
> >
> >Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer
> >driver should be ready. Both patches affect only the Hyper-V frame buffer
> >driver so can go through the Hyper-V tree. Can you pick these up? Thx.
>
> I can't get this to apply anywhere, what tree is it based on?
>
> --
> Thanks,
> Sasha
Hi Sasha,
Today's hyperv/linux.git's hyperv-next branch's top commit is
48b72a2697d5 ("hv_netvsc: Add the support of hibernation").
Please pick up two patches from Wei Hu:
#1: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host
#2: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
I can apply the 2 patches on the hyperv-next branch (the top commit is 48b72a2697d5):
[decui@localhost linux]$ patch -p1 < 1.diff
patching file drivers/video/fbdev/hyperv_fb.c
Hunk #2 succeeded at 53 (offset 1 line).
Hunk #3 succeeded at 95 (offset 1 line).
Hunk #4 succeeded at 124 (offset 1 line).
Hunk #5 succeeded at 222 (offset 1 line).
Hunk #6 succeeded at 262 (offset 2 lines).
Hunk #7 succeeded at 394 (offset 2 lines).
Hunk #8 succeeded at 441 (offset 2 lines).
Hunk #9 succeeded at 480 (offset 2 lines).
Hunk #10 succeeded at 558 (offset 2 lines).
Hunk #11 succeeded at 590 (offset 2 lines).
Hunk #12 succeeded at 785 (offset 2 lines).
Hunk #13 succeeded at 823 (offset 2 lines).
[decui@localhost linux]$ patch -p1 < 2.diff
patching file drivers/video/fbdev/Kconfig
Hunk #1 succeeded at 2214 (offset -27 lines).
patching file drivers/video/fbdev/hyperv_fb.c
Hunk #1 succeeded at 238 (offset 1 line).
Hunk #2 succeeded at 259 (offset 2 lines).
Hunk #3 succeeded at 277 (offset 2 lines).
Hunk #4 succeeded at 364 (offset 2 lines).
Hunk #5 succeeded at 692 (offset 2 lines).
Hunk #6 succeeded at 702 (offset 2 lines).
Hunk #7 succeeded at 719 (offset 2 lines).
Hunk #8 succeeded at 801 (offset 2 lines).
Hunk #9 succeeded at 863 (offset 2 lines).
Hunk #10 succeeded at 876 (offset 2 lines).
Hunk #11 succeeded at 889 (offset 2 lines).
Hunk #12 succeeded at 951 (offset 2 lines).
Hunk #13 succeeded at 988 (offset 2 lines).
Hunk #14 succeeded at 1007 (offset 2 lines).
Hunk #15 succeeded at 1041 (offset 2 lines).
Thanks,
-- Dexuan
^ permalink raw reply
* [PATCH v2] x86/hyperv: make vapic support x2apic mode
From: Roman Kagan @ 2019-10-02 10:19 UTC (permalink / raw)
To: Michael Kelley, Lan Tianyu, Joerg Roedel, K. Y. Srinivasan,
Haiyang Zhang, Stephen Hemminger, Sasha Levin, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86@kernel.org,
linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: kvm@vger.kernel.org
Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode
when supported by the vcpus.
However, the apic access functions for Hyper-V enlightened apic assume
xapic mode only.
As a result, Linux fails to bring up secondary cpus when run as a guest
in QEMU/KVM with both hv_apic and x2apic enabled.
I didn't manage to make my instance of Hyper-V expose x2apic to the
guest; nor does Hyper-V spec document the expected behavior. However,
a Windows guest running in QEMU/KVM with hv_apic and x2apic and a big
number of vcpus (so that it turns on x2apic mode) does use enlightened
apic MSRs passing unshifted 32bit destination id and falls back to the
regular x2apic MSRs for less frequently used apic fields.
So implement the same behavior, by replacing enlightened apic access
functions (only those where it makes a difference) with their
x2apic-aware versions when x2apic is in use.
Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
Cc: stable@vger.kernel.org
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
---
v1 -> v2:
- add ifdefs to handle !CONFIG_X86_X2APIC
arch/x86/hyperv/hv_apic.c | 54 ++++++++++++++++++++++++++++++++++++---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 5c056b8aebef..eb1434ae9e46 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -84,6 +84,44 @@ static void hv_apic_write(u32 reg, u32 val)
}
}
+#ifdef CONFIG_X86_X2APIC
+static void hv_x2apic_icr_write(u32 low, u32 id)
+{
+ wrmsr(HV_X64_MSR_ICR, low, id);
+}
+
+static u32 hv_x2apic_read(u32 reg)
+{
+ u32 reg_val, hi;
+
+ switch (reg) {
+ case APIC_EOI:
+ rdmsr(HV_X64_MSR_EOI, reg_val, hi);
+ return reg_val;
+ case APIC_TASKPRI:
+ rdmsr(HV_X64_MSR_TPR, reg_val, hi);
+ return reg_val;
+
+ default:
+ return native_apic_msr_read(reg);
+ }
+}
+
+static void hv_x2apic_write(u32 reg, u32 val)
+{
+ switch (reg) {
+ case APIC_EOI:
+ wrmsr(HV_X64_MSR_EOI, val, 0);
+ break;
+ case APIC_TASKPRI:
+ wrmsr(HV_X64_MSR_TPR, val, 0);
+ break;
+ default:
+ native_apic_msr_write(reg, val);
+ }
+}
+#endif /* CONFIG_X86_X2APIC */
+
static void hv_apic_eoi_write(u32 reg, u32 val)
{
struct hv_vp_assist_page *hvp = hv_vp_assist_page[smp_processor_id()];
@@ -262,9 +300,19 @@ void __init hv_apic_init(void)
if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
pr_info("Hyper-V: Using MSR based APIC access\n");
apic_set_eoi_write(hv_apic_eoi_write);
- apic->read = hv_apic_read;
- apic->write = hv_apic_write;
- apic->icr_write = hv_apic_icr_write;
+#ifdef CONFIG_X86_X2APIC
+ if (x2apic_enabled()) {
+ apic->read = hv_x2apic_read;
+ apic->write = hv_x2apic_write;
+ apic->icr_write = hv_x2apic_icr_write;
+ } else {
+#endif
+ apic->read = hv_apic_read;
+ apic->write = hv_apic_write;
+ apic->icr_write = hv_apic_icr_write;
+#ifdef CONFIG_X86_X2APIC
+ }
+#endif
apic->icr_read = hv_apic_icr_read;
}
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host
From: Sasha Levin @ 2019-10-02 12:38 UTC (permalink / raw)
To: Dexuan Cui
Cc: Michael Kelley, Wei Hu, b.zolnierkie@samsung.com,
linux-hyperv@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Stephen Hemminger, Haiyang Zhang, KY Srinivasan, Iouri Tarassov
In-Reply-To: <PU1P153MB0169656B3EC48BFCF4D8C134BFB30@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Fri, Sep 13, 2019 at 06:38:42AM +0000, Dexuan Cui wrote:
>> From: Michael Kelley <mikelley@microsoft.com>
>> Sent: Thursday, September 5, 2019 7:06 AM
>>
>> From: Wei Hu <weh@microsoft.com> Sent: Thursday, September 5, 2019 2:12
>> AM
>> >
>> > Beginning from Windows 10 RS5+, VM screen resolution is obtained from
>> host.
>> > The "video=hyperv_fb" boot time option is not needed, but still can be
>> > used to overwrite what the host specifies. The VM resolution on the host
>> > could be set by executing the powershell "set-vmvideo" command.
>> >
>> > Signed-off-by: Iouri Tarassov <iourit@microsoft.com>
>> > Signed-off-by: Wei Hu <weh@microsoft.com>
>> > ---
>> > v2:
>> > - Implemented fallback when version negotiation failed.
>> > - Defined full size for supported_resolution array.
>> >
>> > v3:
>> > - Corrected the synthvid major and minor version comparison problem.
>> >
>> > v4:
>> > - Changed function name to synthvid_ver_ge().
>> >
>> > drivers/video/fbdev/hyperv_fb.c | 159
>> +++++++++++++++++++++++++++++---
>> > 1 file changed, 147 insertions(+), 12 deletions(-)
>> >
>>
>> Reviewed-by: Michael Kelley <mikelley@microsoft.com>
>
>Looks good to me.
>
>Reviewed-by: Dexuan Cui <decui@microsoft.com>
Queued up for hyperv-next, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Sasha Levin @ 2019-10-02 12:40 UTC (permalink / raw)
To: Dexuan Cui
Cc: Michael Kelley, Wei Hu, rdunlap@infradead.org, shc_work@mail.ru,
gregkh@linuxfoundation.org, lee.jones@linaro.org,
alexandre.belloni@bootlin.com, baijiaju1990@gmail.com,
info@metux.net, linux-hyperv@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Stephen Hemminger, Haiyang Zhang,
KY Srinivasan
In-Reply-To: <PU1P153MB0169811097EA55DF795888B2BF9C0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
On Wed, Oct 02, 2019 at 08:09:41AM +0000, Dexuan Cui wrote:
>> -----Original Message-----
>> From: Sasha Levin <sashal@kernel.org>
>> Sent: Tuesday, October 1, 2019 11:48 AM
>>
>> On Fri, Sep 20, 2019 at 05:26:34PM +0000, Michael Kelley wrote:
>> >From: Michael Kelley <mikelley@microsoft.com> Sent: Wednesday,
>> September 18, 2019 2:48 PM
>> >> >
>> >> > Without deferred IO support, hyperv_fb driver informs the host to refresh
>> >> > the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
>> >> > is screen update or not. This patch supports deferred IO for screens in
>> >> > graphics mode and also enables the frame buffer on-demand refresh. The
>> >> > highest refresh rate is still set at 20Hz.
>> >> >
>> >> > Currently Hyper-V only takes a physical address from guest as the starting
>> >> > address of frame buffer. This implies the guest must allocate contiguous
>> >> > physical memory for frame buffer. In addition, Hyper-V Gen 2 VMs only
>> >> > accept address from MMIO region as frame buffer address. Due to these
>> >> > limitations on Hyper-V host, we keep a shadow copy of frame buffer
>> >> > in the guest. This means one more copy of the dirty rectangle inside
>> >> > guest when doing the on-demand refresh. This can be optimized in the
>> >> > future with help from host. For now the host performance gain from
>> deferred
>> >> > IO outweighs the shadow copy impact in the guest.
>> >> >
>> >> > Signed-off-by: Wei Hu <weh@microsoft.com>
>> >
>> >Sasha -- this patch and one other from Wei Hu for the Hyper-V frame buffer
>> >driver should be ready. Both patches affect only the Hyper-V frame buffer
>> >driver so can go through the Hyper-V tree. Can you pick these up? Thx.
>>
>> I can't get this to apply anywhere, what tree is it based on?
>>
>> --
>> Thanks,
>> Sasha
>
>Hi Sasha,
>Today's hyperv/linux.git's hyperv-next branch's top commit is
> 48b72a2697d5 ("hv_netvsc: Add the support of hibernation").
>
>Please pick up two patches from Wei Hu:
>#1: [PATCH v4] video: hyperv: hyperv_fb: Obtain screen resolution from Hyper-V host
>#2: [PATHC v6] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
Ah, I guess I was missing the first one. I've queued both for
hyperv-next, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v3 1/4] x86/kvm: Add "nopvspin" parameter to disable PV spinlocks
From: Sean Christopherson @ 2019-10-02 17:10 UTC (permalink / raw)
To: Zhenzhong Duan
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Jonathan Corbet,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Paolo Bonzini, Radim Krcmar, Wanpeng Li, Jim Mattson,
Joerg Roedel, Peter Zijlstra, Will Deacon
In-Reply-To: <1569847479-13201-2-git-send-email-zhenzhong.duan@oracle.com>
On Mon, Sep 30, 2019 at 08:44:36PM +0800, Zhenzhong Duan wrote:
> There are cases where a guest tries to switch spinlocks to bare metal
> behavior (e.g. by setting "xen_nopvspin" on XEN platform and
> "hv_nopvspin" on HYPER_V).
>
> That feature is missed on KVM, add a new parameter "nopvspin" to disable
> PV spinlocks for KVM guest.
>
> This new parameter is also used to replace "xen_nopvspin" and
> "hv_nopvspin".
This is confusing as there are no Xen or Hyper-V changes in this patch.
Please make it clear that you're talking about future patches, e.g.:
The new 'nopvspin' parameter will also replace Xen and Hyper-V specific
parameters in future patches.
>
> The global variable pvspin isn't defined as __initdata as it's used at
> runtime by XEN guest.
Same comment as above regarding what this patch is doing versus what will
be done in the future. Arguably you should even mark it __initdata in
this patch and deal with conflict in the Xen patch, e.g. use it only to
set the existing xen_pvspin variable.
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Krcmar <rkrcmar@redhat.com>
> Cc: Sean Christopherson <sean.j.christopherson@intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Will Deacon <will@kernel.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 4 ++++
> arch/x86/include/asm/qspinlock.h | 1 +
> arch/x86/kernel/kvm.c | 7 +++++++
> kernel/locking/qspinlock.c | 7 +++++++
> 4 files changed, 19 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index c7ac2f3..4b956d8 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5330,6 +5330,10 @@
> as generic guest with no PV drivers. Currently support
> XEN HVM, KVM, HYPER_V and VMWARE guest.
>
> + nopvspin [X86,KVM] Disables the qspinlock slow path
> + using PV optimizations which allow the hypervisor to
> + 'idle' the guest on lock contention.
> +
> xirc2ps_cs= [NET,PCMCIA]
> Format:
> <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
> diff --git a/arch/x86/include/asm/qspinlock.h b/arch/x86/include/asm/qspinlock.h
> index 444d6fd..34a4484 100644
> --- a/arch/x86/include/asm/qspinlock.h
> +++ b/arch/x86/include/asm/qspinlock.h
> @@ -32,6 +32,7 @@ static __always_inline u32 queued_fetch_set_pending_acquire(struct qspinlock *lo
> extern void __pv_init_lock_hash(void);
> extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
> extern void __raw_callee_save___pv_queued_spin_unlock(struct qspinlock *lock);
> +extern bool pvspin;
>
> #define queued_spin_unlock queued_spin_unlock
> /**
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index e820568..a4f108d 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -842,6 +842,13 @@ void __init kvm_spinlock_init(void)
> if (num_possible_cpus() == 1)
> return;
>
> + if (!pvspin) {
> + pr_info("PV spinlocks disabled\n");
> + static_branch_disable(&virt_spin_lock_key);
> + return;
> + }
> + pr_info("PV spinlocks enabled\n");
These prints could be confusing as KVM also disables PV spinlocks when it
sees KVM_HINTS_REALTIME.
> +
> __pv_init_lock_hash();
> pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
> pv_ops.lock.queued_spin_unlock =
> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
> index 2473f10..945b510 100644
> --- a/kernel/locking/qspinlock.c
> +++ b/kernel/locking/qspinlock.c
> @@ -580,4 +580,11 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
> #include "qspinlock_paravirt.h"
> #include "qspinlock.c"
>
> +bool pvspin = true;
This can be __ro_after_init, or probably better __initdata and have Xen
snapshot the value for its use case.
Personal preference: I'd invert the bool and name it nopvspin to make it
easier to connect the variable to the kernel param.
> +static __init int parse_nopvspin(char *arg)
> +{
> + pvspin = false;
> + return 0;
> +}
> +early_param("nopvspin", parse_nopvspin);
> #endif
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v3 2/4] x86/kvm: Change print code to use pr_*() format
From: Sean Christopherson @ 2019-10-02 17:15 UTC (permalink / raw)
To: Zhenzhong Duan
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Paolo Bonzini,
Radim Krcmar, Wanpeng Li, Jim Mattson, Joerg Roedel,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <1569847479-13201-3-git-send-email-zhenzhong.duan@oracle.com>
On Mon, Sep 30, 2019 at 08:44:37PM +0800, Zhenzhong Duan wrote:
> pr_*() is preferred than printk(KERN_* ...), after change all the print
> in arch/x86/kernel/kvm.c will have "KVM: xxx" style.
>
> No functional change.
>
> Suggested-by: Vitaly Kuznetsov <vkuznets@redhat.com>
This wasn't really suggested by Vitaly, he just requested it be done in a
separate patch.
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: Radim Krcmar <rkrcmar@redhat.com>
> Cc: Sean Christopherson <sean.j.christopherson@intel.com>
> Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
> Cc: Wanpeng Li <wanpengli@tencent.com>
> Cc: Jim Mattson <jmattson@google.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> ---
> arch/x86/kernel/kvm.c | 24 ++++++++++++------------
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index a4f108d..ce4f578 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -7,6 +7,8 @@
> * Authors: Anthony Liguori <aliguori@us.ibm.com>
> */
>
> +#define pr_fmt(fmt) "KVM: " fmt
Not a fan of "KVM" as the prefix as it's easily confused with KVM the
hypervisor. Maybe "kvm_guest"?
> +
> #include <linux/context_tracking.h>
> #include <linux/init.h>
> #include <linux/kernel.h>
> @@ -286,8 +288,8 @@ static void kvm_register_steal_time(void)
> return;
>
> wrmsrl(MSR_KVM_STEAL_TIME, (slow_virt_to_phys(st) | KVM_MSR_ENABLED));
> - pr_info("kvm-stealtime: cpu %d, msr %llx\n",
> - cpu, (unsigned long long) slow_virt_to_phys(st));
> + pr_info("stealtime: cpu %d, msr %llx\n", cpu,
> + (unsigned long long) slow_virt_to_phys(st));
> }
>
> static DEFINE_PER_CPU_DECRYPTED(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;
> @@ -321,8 +323,7 @@ static void kvm_guest_cpu_init(void)
>
> wrmsrl(MSR_KVM_ASYNC_PF_EN, pa);
> __this_cpu_write(apf_reason.enabled, 1);
> - printk(KERN_INFO"KVM setup async PF for cpu %d\n",
> - smp_processor_id());
> + pr_info("setup async PF for cpu %d\n", smp_processor_id());
> }
>
> if (kvm_para_has_feature(KVM_FEATURE_PV_EOI)) {
> @@ -347,8 +348,7 @@ static void kvm_pv_disable_apf(void)
> wrmsrl(MSR_KVM_ASYNC_PF_EN, 0);
> __this_cpu_write(apf_reason.enabled, 0);
>
> - printk(KERN_INFO"Unregister pv shared memory for cpu %d\n",
> - smp_processor_id());
> + pr_info("Unregister pv shared memory for cpu %d\n", smp_processor_id());
> }
>
> static void kvm_pv_guest_cpu_reboot(void *unused)
> @@ -509,7 +509,7 @@ static void kvm_setup_pv_ipi(void)
> {
> apic->send_IPI_mask = kvm_send_ipi_mask;
> apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
> - pr_info("KVM setup pv IPIs\n");
> + pr_info("setup pv IPIs\n");
> }
>
> static void kvm_smp_send_call_func_ipi(const struct cpumask *mask)
> @@ -639,11 +639,11 @@ static void __init kvm_guest_init(void)
> !kvm_para_has_hint(KVM_HINTS_REALTIME) &&
> kvm_para_has_feature(KVM_FEATURE_STEAL_TIME)) {
> smp_ops.send_call_func_ipi = kvm_smp_send_call_func_ipi;
> - pr_info("KVM setup pv sched yield\n");
> + pr_info("setup pv sched yield\n");
> }
> if (cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "x86/kvm:online",
> kvm_cpu_online, kvm_cpu_down_prepare) < 0)
> - pr_err("kvm_guest: Failed to install cpu hotplug callbacks\n");
> + pr_err("failed to install cpu hotplug callbacks\n");
> #else
> sev_map_percpu_data();
> kvm_guest_cpu_init();
> @@ -746,7 +746,7 @@ static __init int kvm_setup_pv_tlb_flush(void)
> zalloc_cpumask_var_node(per_cpu_ptr(&__pv_tlb_mask, cpu),
> GFP_KERNEL, cpu_to_node(cpu));
> }
> - pr_info("KVM setup pv remote TLB flush\n");
> + pr_info("setup pv remote TLB flush\n");
> }
>
> return 0;
> @@ -879,8 +879,8 @@ static void kvm_enable_host_haltpoll(void *i)
> void arch_haltpoll_enable(unsigned int cpu)
> {
> if (!kvm_para_has_feature(KVM_FEATURE_POLL_CONTROL)) {
> - pr_err_once("kvm: host does not support poll control\n");
> - pr_err_once("kvm: host upgrade recommended\n");
> + pr_err_once("host does not support poll control\n");
> + pr_err_once("host upgrade recommended\n");
> return;
> }
>
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v3 3/4] xen: Mark "xen_nopvspin" parameter obsolete and map it to "nopvspin"
From: Sean Christopherson @ 2019-10-02 17:18 UTC (permalink / raw)
To: Zhenzhong Duan
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Jonathan Corbet,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <1569847479-13201-4-git-send-email-zhenzhong.duan@oracle.com>
On Mon, Sep 30, 2019 at 08:44:38PM +0800, Zhenzhong Duan wrote:
> Fix stale description of "xen_nopvspin" as we use qspinlock now.
>
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Reviewed-by: Juergen Gross <jgross@suse.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> 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: "H. Peter Anvin" <hpa@zytor.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 7 ++++---
> arch/x86/xen/spinlock.c | 13 +++++++------
> 2 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 4b956d8..1f0a62f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5303,8 +5303,9 @@
> never -- do not unplug even if version check succeeds
>
> xen_nopvspin [X86,XEN]
> - Disables the ticketlock slowpath using Xen PV
> - optimizations.
> + Disables the qspinlock slowpath using Xen PV optimizations.
> + This parameter is obsoleted by "nopvspin" parameter, which
> + has equivalent effect for XEN platform.
>
> xen_nopv [X86]
> Disables the PV optimizations forcing the HVM guest to
> @@ -5330,7 +5331,7 @@
> as generic guest with no PV drivers. Currently support
> XEN HVM, KVM, HYPER_V and VMWARE guest.
>
> - nopvspin [X86,KVM] Disables the qspinlock slow path
> + nopvspin [X86,XEN,KVM] Disables the qspinlock slow path
> using PV optimizations which allow the hypervisor to
> 'idle' the guest on lock contention.
>
> diff --git a/arch/x86/xen/spinlock.c b/arch/x86/xen/spinlock.c
> index 6deb490..092a53f 100644
> --- a/arch/x86/xen/spinlock.c
> +++ b/arch/x86/xen/spinlock.c
> @@ -18,7 +18,6 @@
> static DEFINE_PER_CPU(int, lock_kicker_irq) = -1;
> static DEFINE_PER_CPU(char *, irq_name);
> static DEFINE_PER_CPU(atomic_t, xen_qlock_wait_nest);
> -static bool xen_pvspin = true;
>
> static void xen_qlock_kick(int cpu)
> {
> @@ -68,7 +67,7 @@ void xen_init_lock_cpu(int cpu)
> int irq;
> char *name;
>
> - if (!xen_pvspin)
> + if (!pvspin)
> return;
>
> WARN(per_cpu(lock_kicker_irq, cpu) >= 0, "spinlock on CPU%d exists on IRQ%d!\n",
> @@ -93,7 +92,7 @@ void xen_init_lock_cpu(int cpu)
>
> void xen_uninit_lock_cpu(int cpu)
> {
> - if (!xen_pvspin)
> + if (!pvspin)
> return;
>
> unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
> @@ -117,9 +116,9 @@ void __init xen_init_spinlocks(void)
>
> /* Don't need to use pvqspinlock code if there is only 1 vCPU. */
> if (num_possible_cpus() == 1)
> - xen_pvspin = false;
> + pvspin = false;
As suggested in the other patch, if you incorporate pvspin (or nopvspin)
into xen_pvspin then the param can be __initdata and the diff for this
patch will be smaller, e.g. you wouldn't need the xen_domain() shenanigans
in xen_parse_nopvspin().
> - if (!xen_pvspin) {
> + if (!pvspin) {
> printk(KERN_DEBUG "xen: PV spinlocks disabled\n");
> static_branch_disable(&virt_spin_lock_key);
> return;
> @@ -137,7 +136,9 @@ void __init xen_init_spinlocks(void)
>
> static __init int xen_parse_nopvspin(char *arg)
> {
> - xen_pvspin = false;
> + pr_notice("\"xen_nopvspin\" is deprecated, please use \"nopvspin\" instead\n");
> + if (xen_domain())
> + pvspin = false;
> return 0;
> }
> early_param("xen_nopvspin", xen_parse_nopvspin);
> --
> 1.8.3.1
>
^ permalink raw reply
* Re: [PATCH v3 4/4] x86/hyperv: Mark "hv_nopvspin" parameter obsolete and map it to "nopvspin"
From: Sean Christopherson @ 2019-10-02 17:19 UTC (permalink / raw)
To: Zhenzhong Duan
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Jonathan Corbet,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <1569847479-13201-5-git-send-email-zhenzhong.duan@oracle.com>
On Mon, Sep 30, 2019 at 08:44:39PM +0800, Zhenzhong Duan wrote:
> Includes asm/hypervisor.h in order to reference x86_hyper_type.
>
> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: "K. Y. Srinivasan" <kys@microsoft.com>
> Cc: Haiyang Zhang <haiyangz@microsoft.com>
> Cc: Stephen Hemminger <sthemmin@microsoft.com>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 +++++-
> arch/x86/hyperv/hv_spinlock.c | 9 +++++----
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1f0a62f..43f922c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -1436,6 +1436,10 @@
> hv_nopvspin [X86,HYPER_V] Disables the paravirt spinlock optimizations
> which allow the hypervisor to 'idle' the
> guest on lock contention.
> + This parameter is obsoleted by "nopvspin"
> + parameter, which has equivalent effect for
> + HYPER_V platform.
> +
>
> keep_bootcon [KNL]
> Do not unregister boot console at start. This is only
> @@ -5331,7 +5335,7 @@
> as generic guest with no PV drivers. Currently support
> XEN HVM, KVM, HYPER_V and VMWARE guest.
>
> - nopvspin [X86,XEN,KVM] Disables the qspinlock slow path
> + nopvspin [X86,XEN,KVM,HYPER_V] Disables the qspinlock slow path
> using PV optimizations which allow the hypervisor to
> 'idle' the guest on lock contention.
>
> diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
> index 07f21a0..e00e319 100644
> --- a/arch/x86/hyperv/hv_spinlock.c
> +++ b/arch/x86/hyperv/hv_spinlock.c
> @@ -12,12 +12,11 @@
>
> #include <linux/spinlock.h>
>
> +#include <asm/hypervisor.h>
> #include <asm/mshyperv.h>
> #include <asm/paravirt.h>
> #include <asm/apic.h>
>
> -static bool __initdata hv_pvspin = true;
> -
> static void hv_qlock_kick(int cpu)
> {
> apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
> @@ -64,7 +63,7 @@ __visible bool hv_vcpu_is_preempted(int vcpu)
>
> void __init hv_init_spinlocks(void)
> {
> - if (!hv_pvspin || !apic ||
> + if (!pvspin || !apic ||
> !(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
> !(ms_hyperv.features & HV_X64_MSR_GUEST_IDLE_AVAILABLE)) {
> pr_info("PV spinlocks disabled\n");
> @@ -82,7 +81,9 @@ void __init hv_init_spinlocks(void)
>
> static __init int hv_parse_nopvspin(char *arg)
> {
> - hv_pvspin = false;
> + pr_notice("\"hv_nopvspin\" is deprecated, please use \"nopvspin\" instead\n");
> + if (x86_hyper_type == X86_HYPER_MS_HYPERV)
> + pvspin = false;
Personal preference would be to keep the hv_pvspin variable and add the
extra check in hv_init_spinlocks().
> return 0;
> }
> early_param("hv_nopvspin", hv_parse_nopvspin);
> --
> 1.8.3.1
>
^ permalink raw reply
* RE: [PATCH] Input: hyperv-keyboard: Add the support of hibernation
From: Dexuan Cui @ 2019-10-03 5:35 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <20190930230652.GW237523@dtor-ws>
> From: dmitry.torokhov@gmail.com <dmitry.torokhov@gmail.com>
> Sent: Monday, September 30, 2019 4:07 PM
>
> On Mon, Sep 30, 2019 at 10:09:27PM +0000, Dexuan Cui wrote:
> > > From: dmitry.torokhov@gmail.com <dmitry.torokhov@gmail.com>
> > > Sent: Friday, September 27, 2019 5:32 PM
> > > > ...
> > > > pm_wakeup_pending() is tested in a lot of places in the suspend
> > > > process and eventually an unintentional keystroke (or mouse movement,
> > > > when it comes to the Hyper-V mouse driver drivers/hid/hid-hyperv.c)
> > > > causes the whole hibernation process to be aborted. Usually this
> > > > behavior is not expected by the user, I think.
> > >
> > > Why not? If a device is configured as wakeup source, then it activity
> > > should wake up the system, unless you disable it.
> >
> > Generally speaking, I agree, but compared to a physical machine, IMO
> > the scenario is a little different when it comes to a VM running on Hyper-V:
> > on the host there is a window that represents the VM, and the user can
> > unintentionally switch the keyboard input focus to the window (or move
> > the mouse/cursor over the window) and then the host automatically
> > sends some special keystrokes (and mouse events) , and this aborts the
> > hibernation process.
> >
> > And, when it comes to the Hyper-V mouse device, IMO it's easy for the
> > user to unintentionally move the mouse after the "hibernation" button
> > is clicked. I suppose a physical machine would have the same issue, though.
>
> If waking the machine up by mouse/keyboard activity is not desired in
> Hyper-V environment, then simply disable them as wakeup sources.
Sorry for the late reply! I have been sidetracked by something else...
Several years ago, we marked Hyper-V mouse/keyboard devices as wake
sources to fix such a bug: the VM can not be woken up after we run
"echo freeze > /sys/power/state". IMO we should keep the mouse/keyboard
as wakeup sources.
> >
> > > > So, I use the notifier to set the flag variable and with it the driver can
> > > > know when it should not call pm_wakeup_hard_event().
> > >
> > > No, please implement hibernation support properly, as notifier + flag is
> > > a hack.
> >
> > The keyboard/mouse driver can avoid the flag by disabling the
> > keyboard/mouse event handling, but the problem is that they don't know
> > when exactly they should disable the event handling. I think the PM
> > notifier is the only way to tell the drivers a hibernation process is ongoing.
>
> Whatever initiates hibernation (in userspace) can adjust wakeup sources
> as needed if you want them disabled completely.
Good to know this! I just found the userspace is able to disable the Hyper-V
mouse/keyboard as wakeup sources by something like:
echo disabled > /sys/bus/vmbus/devices/XXX/power/wakeup
(XXX is the device GUID).
> >
> > Do you think this idea (notifier + disabling event handling) is acceptable?
>
> No, I believe this a hack, that is why I am pushing back on this.
Ok, I think we can get rid of the notifier completely, and tell the users to disable
the 2 wakeup sources, if they think the wakeup behavior is undesired.
> >
> > If not, then I'll have to remove the notifier completely, and document this as
> > a known issue to the user: when a hibernation process is started, be careful
> > to not switch input focus and not touch the keyboard/mouse until the
> > hibernation process is finished. :-)
> >
> > > In this particular case you do not want to have your
> > > hv_kbd_resume() to be called in place of pm_ops->thaw() as that is what
> > > reenables the keyboard vmbus channel and causes the undesired wakeup
> > > events.
> >
> > This is only part of the issues. Another example: before the
> > pm_ops()->freeze()'s of all the devices are called, pm_wakeup_pending()
> > is already tested in a lot of places (e.g. in try_to_freeze_tasks ()) in the
> > suspend process, and can abort the whole suspend process upon the user's
> > unintentional input focus switch, keystroke and mouse movement.
>
> How long is the prepare() phase on your systems?
I have no specific data, but I know it's fast.
> User may wiggle mouse at any time really, even before the notifier fires up.
This doesn't matter, because the counter "pm_abort_suspend" is cleared at
a later place. The code path is:
hibernate() ->
__pm_notifier_call_chain(PM_HIBERNATION_PREPARE, -1, &nr_calls)
freeze_processes() ->
pm_wakeup_clear() ->
atomic_set(&pm_abort_suspend, 0);
This patch sets the flag in the PM_HIBERNATION_PREPARE notifier, so
there is no race.
Since I'm going to get rid of the notifier, we don't care at all about this now.
> >
> > > Your vmbus implementation should allow individual drivers to
> > > control the set of PM operations that they wish to use, instead of
> > > forcing everything through suspend/resume.
> > >
> > > Dmitry
> >
> > Since the devices are pure software-emulated devices, no PM operation was
> > supported in the past, and now suspend/resume are the only two PM
> operations
> > we're going to support. If the idea (notifier + disabling event handling) is not
> > good enough, we'll have to document the issue to the user, as I described
> above.
>
> ¯\_(ツ)_/¯ If you do not want to implement hibernation properly in vmbus
> code that is totally up to you (have you read in pm.h how freeze() is
> different from suspend()?).
> Dmitry
I understand freeze() is different from suspend(). Here I treat suspend() as a
heavyweight freeze() for simplicity and IMHO the extra cost of time is
neglectable considering the long hibernation process, which can take
5~10+ seconds.
Even if I implement all the pm ops, IMO the issue we're talking about
(i.e. the hibernation process can be aborted by user's keyboard/mouse
activities) still exists. Actually I think a physical Linux machine should have
the same issue.
In practice, IMO the issue is not a big concern, as the VM usually runs in
a remote data center, and the user has no access to the VM's
keyboard/mouse. :-)
I hope I understood your comments. I'll post a v2 without the notifier.
Please Ack the v2 if it looks good to you.
Thanks,
-- Dexuan
^ permalink raw reply
* RE: [PATCH] Input: hyperv-keyboard: Add the support of hibernation
From: Dexuan Cui @ 2019-10-03 6:44 UTC (permalink / raw)
To: dmitry.torokhov@gmail.com
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
sashal@kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Kelley
In-Reply-To: <PU1P153MB01696258D9983DF59D68E748BF9F0@PU1P153MB0169.APCP153.PROD.OUTLOOK.COM>
> From: Dexuan Cui
> Sent: Wednesday, October 2, 2019 10:35 PM
> > ...
> >
> > ¯\_(ツ)_/¯ If you do not want to implement hibernation properly in vmbus
> > code that is totally up to you (have you read in pm.h how freeze() is
> > different from suspend()?).
> > Dmitry
>
> I understand freeze() is different from suspend(). Here I treat suspend() as a
> heavyweight freeze() for simplicity and IMHO the extra cost of time is
> neglectable considering the long hibernation process, which can take
> 5~10+ seconds.
>
> Even if I implement all the pm ops, IMO the issue we're talking about
> (i.e. the hibernation process can be aborted by user's keyboard/mouse
> activities) still exists. Actually I think a physical Linux machine should have
> the same issue.
>
> In practice, IMO the issue is not a big concern, as the VM usually runs in
> a remote data center, and the user has no access to the VM's
> keyboard/mouse. :-)
>
> I hope I understood your comments. I'll post a v2 without the notifier.
> Please Ack the v2 if it looks good to you.
>
> -- Dexuan
I think I understood now: it looks the vmbus driver should implement
a prepare() or freeze(), which calls the hyperv_keyboard driver's
prepare() or freeze(), which can set the flag or disable the keyboard
event handling. This way we don't need the notifier.
Please let me know if I still don't get it right.
Thanks,
-- Dexuan
^ permalink raw reply
* Re: [PATCH v3 1/4] x86/kvm: Add "nopvspin" parameter to disable PV spinlocks
From: Zhenzhong Duan @ 2019-10-03 10:30 UTC (permalink / raw)
To: Sean Christopherson
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Jonathan Corbet,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Paolo Bonzini, Radim Krcmar, Wanpeng Li, Jim Mattson,
Joerg Roedel, Peter Zijlstra, Will Deacon
In-Reply-To: <20191002171006.GB9615@linux.intel.com>
On 2019/10/3 1:10, Sean Christopherson wrote:
> On Mon, Sep 30, 2019 at 08:44:36PM +0800, Zhenzhong Duan wrote:
>> There are cases where a guest tries to switch spinlocks to bare metal
>> behavior (e.g. by setting "xen_nopvspin" on XEN platform and
>> "hv_nopvspin" on HYPER_V).
>>
>> That feature is missed on KVM, add a new parameter "nopvspin" to disable
>> PV spinlocks for KVM guest.
>>
>> This new parameter is also used to replace "xen_nopvspin" and
>> "hv_nopvspin".
> This is confusing as there are no Xen or Hyper-V changes in this patch.
> Please make it clear that you're talking about future patches, e.g.:
>
> The new 'nopvspin' parameter will also replace Xen and Hyper-V specific
> parameters in future patches.
Will fix
>
>> The global variable pvspin isn't defined as __initdata as it's used at
>> runtime by XEN guest.
> Same comment as above regarding what this patch is doing versus what will
> be done in the future. Arguably you should even mark it __initdata in
> this patch and deal with conflict in the Xen patch, e.g. use it only to
> set the existing xen_pvspin variable.
Will fix
>
>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@oracle.com>
......snip
>> /**
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index e820568..a4f108d 100644
>> --- a/arch/x86/kernel/kvm.c
>> +++ b/arch/x86/kernel/kvm.c
>> @@ -842,6 +842,13 @@ void __init kvm_spinlock_init(void)
>> if (num_possible_cpus() == 1)
>> return;
>>
>> + if (!pvspin) {
>> + pr_info("PV spinlocks disabled\n");
>> + static_branch_disable(&virt_spin_lock_key);
>> + return;
>> + }
>> + pr_info("PV spinlocks enabled\n");
> These prints could be confusing as KVM also disables PV spinlocks when it
> sees KVM_HINTS_REALTIME.
What about below:
pr_info("PV spinlocks disabled forced by \"nopvspin\" parameter.\n");
Or you prefer separate print for each disabling like below?
/* Does host kernel support KVM_FEATURE_PV_UNHALT? */
if (!kvm_para_has_feature(KVM_FEATURE_PV_UNHALT)) {
pr_info("PV spinlocks disabled, KVM_FEATURE_PV_UNHALT feature needed.\n");
return;
}
if (kvm_para_has_hint(KVM_HINTS_REALTIME)) {
pr_info("PV spinlocks disabled, having non-preemption hints.\n");
return;
}
/* Don't use the pvqspinlock code if there is only 1 vCPU. */
if (num_possible_cpus() == 1) {
pr_info("PV spinlocks disabled on UP.\n");
return;
}
if (!pvspin) {
pr_info("PV spinlocks disabled forced by \"nopvspin\" parameter.\n");
static_branch_disable(&virt_spin_lock_key);
return;
}
pr_info("PV spinlocks enabled\n");
>
>> +
>> __pv_init_lock_hash();
>> pv_ops.lock.queued_spin_lock_slowpath = __pv_queued_spin_lock_slowpath;
>> pv_ops.lock.queued_spin_unlock =
>> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
>> index 2473f10..945b510 100644
>> --- a/kernel/locking/qspinlock.c
>> +++ b/kernel/locking/qspinlock.c
>> @@ -580,4 +580,11 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
>> #include "qspinlock_paravirt.h"
>> #include "qspinlock.c"
>>
>> +bool pvspin = true;
> This can be __ro_after_init, or probably better __initdata and have Xen
> snapshot the value for its use case.
I will use __initdata
>
> Personal preference: I'd invert the bool and name it nopvspin to make it
> easier to connect the variable to the kernel param.
OK, will do that. Thanks for review for all the patches.
Zhenzhong
^ permalink raw reply
* Re: [PATCH v3 2/4] x86/kvm: Change print code to use pr_*() format
From: Zhenzhong Duan @ 2019-10-03 10:32 UTC (permalink / raw)
To: Sean Christopherson
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Paolo Bonzini,
Radim Krcmar, Wanpeng Li, Jim Mattson, Joerg Roedel,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20191002171551.GC9615@linux.intel.com>
On 2019/10/3 1:15, Sean Christopherson wrote:
> On Mon, Sep 30, 2019 at 08:44:37PM +0800, Zhenzhong Duan wrote:
>> pr_*() is preferred than printk(KERN_* ...), after change all the print
>> in arch/x86/kernel/kvm.c will have "KVM: xxx" style.
>>
>> No functional change.
>>
>> Suggested-by: Vitaly Kuznetsov<vkuznets@redhat.com>
> This wasn't really suggested by Vitaly, he just requested it be done in a
> separate patch.
Will fix.
>
>> Signed-off-by: Zhenzhong Duan<zhenzhong.duan@oracle.com>
>> Cc: Paolo Bonzini<pbonzini@redhat.com>
>> Cc: Radim Krcmar<rkrcmar@redhat.com>
>> Cc: Sean Christopherson<sean.j.christopherson@intel.com>
>> Cc: Vitaly Kuznetsov<vkuznets@redhat.com>
>> Cc: Wanpeng Li<wanpengli@tencent.com>
>> Cc: Jim Mattson<jmattson@google.com>
>> Cc: Joerg Roedel<joro@8bytes.org>
>> Cc: Thomas Gleixner<tglx@linutronix.de>
>> Cc: Ingo Molnar<mingo@redhat.com>
>> Cc: Borislav Petkov<bp@alien8.de>
>> Cc: "H. Peter Anvin"<hpa@zytor.com>
>> ---
>> arch/x86/kernel/kvm.c | 24 ++++++++++++------------
>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index a4f108d..ce4f578 100644
>> --- a/arch/x86/kernel/kvm.c
>> +++ b/arch/x86/kernel/kvm.c
>> @@ -7,6 +7,8 @@
>> * Authors: Anthony Liguori<aliguori@us.ibm.com>
>> */
>>
>> +#define pr_fmt(fmt) "KVM: " fmt
> Not a fan of "KVM" as the prefix as it's easily confused with KVM the
> hypervisor. Maybe "kvm_guest"?
Yeah, looks better, will change to"kvm_guest". Thanks
Zhenzhong
^ permalink raw reply
* Re: [PATCH v2] x86/hyperv: make vapic support x2apic mode
From: Vitaly Kuznetsov @ 2019-10-03 10:54 UTC (permalink / raw)
To: Roman Kagan
Cc: kvm@vger.kernel.org, Michael Kelley, Lan Tianyu, Joerg Roedel,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Sasha Levin,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
x86@kernel.org, linux-hyperv@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20191002101923.4981-1-rkagan@virtuozzo.com>
Roman Kagan <rkagan@virtuozzo.com> writes:
> Now that there's Hyper-V IOMMU driver, Linux can switch to x2apic mode
> when supported by the vcpus.
>
> However, the apic access functions for Hyper-V enlightened apic assume
> xapic mode only.
>
> As a result, Linux fails to bring up secondary cpus when run as a guest
> in QEMU/KVM with both hv_apic and x2apic enabled.
>
> I didn't manage to make my instance of Hyper-V expose x2apic to the
> guest; nor does Hyper-V spec document the expected behavior. However,
> a Windows guest running in QEMU/KVM with hv_apic and x2apic and a big
> number of vcpus (so that it turns on x2apic mode) does use enlightened
> apic MSRs passing unshifted 32bit destination id and falls back to the
> regular x2apic MSRs for less frequently used apic fields.
>
> So implement the same behavior, by replacing enlightened apic access
> functions (only those where it makes a difference) with their
> x2apic-aware versions when x2apic is in use.
>
> Fixes: 29217a474683 ("iommu/hyper-v: Add Hyper-V stub IOMMU driver")
> Fixes: 6b48cb5f8347 ("X86/Hyper-V: Enlighten APIC access")
> Cc: stable@vger.kernel.org
> Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
> ---
> v1 -> v2:
> - add ifdefs to handle !CONFIG_X86_X2APIC
>
> arch/x86/hyperv/hv_apic.c | 54 ++++++++++++++++++++++++++++++++++++---
> 1 file changed, 51 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
> index 5c056b8aebef..eb1434ae9e46 100644
> --- a/arch/x86/hyperv/hv_apic.c
> +++ b/arch/x86/hyperv/hv_apic.c
> @@ -84,6 +84,44 @@ static void hv_apic_write(u32 reg, u32 val)
> }
> }
>
> +#ifdef CONFIG_X86_X2APIC
> +static void hv_x2apic_icr_write(u32 low, u32 id)
> +{
> + wrmsr(HV_X64_MSR_ICR, low, id);
> +}
AFAIU you're trying to mirror native_x2apic_icr_write() here but this is
different from what hv_apic_icr_write() does
(SET_APIC_DEST_FIELD(id)). Is it actually correct? (I think you've
tested this and it is but) Michael, could you please shed some light
here?
> +
> +static u32 hv_x2apic_read(u32 reg)
> +{
> + u32 reg_val, hi;
> +
> + switch (reg) {
> + case APIC_EOI:
> + rdmsr(HV_X64_MSR_EOI, reg_val, hi);
> + return reg_val;
> + case APIC_TASKPRI:
> + rdmsr(HV_X64_MSR_TPR, reg_val, hi);
> + return reg_val;
> +
> + default:
> + return native_apic_msr_read(reg);
> + }
> +}
> +
> +static void hv_x2apic_write(u32 reg, u32 val)
> +{
> + switch (reg) {
> + case APIC_EOI:
> + wrmsr(HV_X64_MSR_EOI, val, 0);
> + break;
> + case APIC_TASKPRI:
> + wrmsr(HV_X64_MSR_TPR, val, 0);
> + break;
> + default:
> + native_apic_msr_write(reg, val);
> + }
> +}
> +#endif /* CONFIG_X86_X2APIC */
> +
> static void hv_apic_eoi_write(u32 reg, u32 val)
> {
> struct hv_vp_assist_page *hvp = hv_vp_assist_page[smp_processor_id()];
> @@ -262,9 +300,19 @@ void __init hv_apic_init(void)
> if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
> pr_info("Hyper-V: Using MSR based APIC access\n");
> apic_set_eoi_write(hv_apic_eoi_write);
> - apic->read = hv_apic_read;
> - apic->write = hv_apic_write;
> - apic->icr_write = hv_apic_icr_write;
> +#ifdef CONFIG_X86_X2APIC
> + if (x2apic_enabled()) {
> + apic->read = hv_x2apic_read;
> + apic->write = hv_x2apic_write;
> + apic->icr_write = hv_x2apic_icr_write;
> + } else {
> +#endif
> + apic->read = hv_apic_read;
> + apic->write = hv_apic_write;
> + apic->icr_write = hv_apic_icr_write;
(just wondering): Is it always safe to assume that we cannot switch
between apic_flat/x2apic in runtime? Moreover, the only difference
between hv_apic_read/hv_apic_write and hv_x2apic_read/hv_x2apic_write is
native_apic_mem_{read,write} -> native_apic_msr_{read,write}. Would it
make sense to move if (x2apic_enabled()) and merge these functions?
> +#ifdef CONFIG_X86_X2APIC
> + }
> +#endif
> apic->icr_read = hv_apic_icr_read;
> }
> }
--
Vitaly
^ permalink raw reply
* Re: [PATCH v3 3/4] xen: Mark "xen_nopvspin" parameter obsolete and map it to "nopvspin"
From: Zhenzhong Duan @ 2019-10-03 11:21 UTC (permalink / raw)
To: Sean Christopherson
Cc: linux-kernel, vkuznets, linux-hyperv, kvm, Jonathan Corbet,
Boris Ostrovsky, Juergen Gross, Stefano Stabellini,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin
In-Reply-To: <20191002171805.GD9615@linux.intel.com>
On 2019/10/3 1:18, Sean Christopherson wrote:
> On Mon, Sep 30, 2019 at 08:44:38PM +0800, Zhenzhong Duan wrote:
>> Fix stale description of "xen_nopvspin" as we use qspinlock now.
>>
>> Signed-off-by: Zhenzhong Duan<zhenzhong.duan@oracle.com>
>> Reviewed-by: Juergen Gross<jgross@suse.com>
>> Cc: Jonathan Corbet<corbet@lwn.net>
>> 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: "H. Peter Anvin"<hpa@zytor.com>
>> ---
...snip
>> @@ -93,7 +92,7 @@ void xen_init_lock_cpu(int cpu)
>>
>> void xen_uninit_lock_cpu(int cpu)
>> {
>> - if (!xen_pvspin)
>> + if (!pvspin)
>> return;
>>
>> unbind_from_irqhandler(per_cpu(lock_kicker_irq, cpu), NULL);
>> @@ -117,9 +116,9 @@ void __init xen_init_spinlocks(void)
>>
>> /* Don't need to use pvqspinlock code if there is only 1 vCPU. */
>> if (num_possible_cpus() == 1)
>> - xen_pvspin = false;
>> + pvspin = false;
> As suggested in the other patch, if you incorporate pvspin (or nopvspin)
> into xen_pvspin then the param can be __initdata and the diff for this
> patch will be smaller, e.g. you wouldn't need the xen_domain() shenanigans
> in xen_parse_nopvspin().
Ok, will fix. Thanks
Zhenzhong
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox