* Re: [PATCH] PCI: export and use pci_msi_get_hwirq in pci-hyperv.c
From: Rob Herring @ 2020-05-07 20:58 UTC (permalink / raw)
To: Wei Liu
Cc: linux-pci, linux-hyperv, linux-kernel, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Lorenzo Pieralisi, Andrew Murray, Bjorn Helgaas, Allison Randal,
Greg Kroah-Hartman, Enrico Weigelt
In-Reply-To: <20200422195818.35489-1-wei.liu@kernel.org>
On Wed, Apr 22, 2020 at 07:58:15PM +0000, Wei Liu wrote:
> There is a functionally identical function in pci-hyperv.c. Drop it and
> use pci_msi_get_hwirq instead.
>
> This requires exporting pci_msi_get_hwirq and declaring it in msi.h.
>
> No functional change intended.
>
> Signed-off-by: Wei Liu <wei.liu@kernel.org>
> ---
> arch/x86/include/asm/msi.h | 4 ++++
> arch/x86/kernel/apic/msi.c | 5 +++--
> drivers/pci/controller/pci-hyperv.c | 8 +-------
> 3 files changed, 8 insertions(+), 9 deletions(-)
Would be better if done in a way to remove an x86 dependency.
I guess this would do it:
#define pci_msi_get_hwirq NULL
when GENERIC_MSI_DOMAIN_OPS is enabled.
>
> diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
> index 25ddd0916bb2..353b80122b2e 100644
> --- a/arch/x86/include/asm/msi.h
> +++ b/arch/x86/include/asm/msi.h
> @@ -11,4 +11,8 @@ int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
>
> void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc);
>
> +struct msi_domain_info;
> +irq_hw_number_t pci_msi_get_hwirq(struct msi_domain_info *info,
> + msi_alloc_info_t *arg);
> +
> #endif /* _ASM_X86_MSI_H */
> diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
> index 159bd0cb8548..56dcdd912564 100644
> --- a/arch/x86/kernel/apic/msi.c
> +++ b/arch/x86/kernel/apic/msi.c
> @@ -204,11 +204,12 @@ void native_teardown_msi_irq(unsigned int irq)
> irq_domain_free_irqs(irq, 1);
> }
>
> -static irq_hw_number_t pci_msi_get_hwirq(struct msi_domain_info *info,
> - msi_alloc_info_t *arg)
> +irq_hw_number_t pci_msi_get_hwirq(struct msi_domain_info *info,
> + msi_alloc_info_t *arg)
> {
> return arg->msi_hwirq;
> }
> +EXPORT_SYMBOL_GPL(pci_msi_get_hwirq);
>
> int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
> msi_alloc_info_t *arg)
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index e6020480a28b..2b4a6452095f 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -1520,14 +1520,8 @@ static struct irq_chip hv_msi_irq_chip = {
> .irq_unmask = hv_irq_unmask,
> };
>
> -static irq_hw_number_t hv_msi_domain_ops_get_hwirq(struct msi_domain_info *info,
> - msi_alloc_info_t *arg)
> -{
> - return arg->msi_hwirq;
> -}
> -
> static struct msi_domain_ops hv_msi_ops = {
> - .get_hwirq = hv_msi_domain_ops_get_hwirq,
> + .get_hwirq = pci_msi_get_hwirq,
> .msi_prepare = pci_msi_prepare,
> .set_desc = pci_msi_set_desc,
> .msi_free = hv_msi_free,
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v2 0/1] x86/kvm/hyper-v: Add support to SYNIC exit on EOM
From: Jon Doron @ 2020-05-08 14:29 UTC (permalink / raw)
To: Roman Kagan, Vitaly Kuznetsov, kvm, linux-hyperv
In-Reply-To: <20200507030037.GE2862@jondnuc>
On 07/05/2020, Jon Doron wrote:
>On 06/05/2020, Roman Kagan wrote:
>>On Wed, May 06, 2020 at 07:49:29AM +0300, Jon Doron wrote:
>>>Thanks Roman, I see your point, it's important for me to get the EDK2
>>>working properly not sure why it's not working for me.
>>
>>As I wrote a good deal of that code I hope I should be able to help (and
>>I'd be interested, too). How exactly does the "not working" look like?
>>
>
>Basically when I built the BIOS from the hv-scsi branch you pointed me
>out to, the BIOS did not see the virtio-blk device to boot from, I
>usually take the BIOS from (https://www.kraxel.org/repos/) but I will
>try to build the latest EDK2 and see if it identifies the virtio-blk
>device and boots from it, if that's the case perhaps i just need to
>rebase your branch over the latest master of EDK2.
>
>>Also I'm a bit confused as to why UEFI is critical for the work you're
>>doing? Can't it be made to work with BIOS first?
>>
>
>The reason I want to have the UEFI option is because I need SecureBoot
>to turn on VBS.
>
>>>Do you know by any chance if the EDK2 hyperv patches were submitted and if
>>>they were why they were not merged in?
>>
>>I do, as I'm probably the only one who could have submitted them :)
>>
>>No they were not submitted. Neither were the ones for SeaBIOS nor iPXE.
>>The reason was that I had found no way to use alternative firmware with
>>HyperV, so the only environment where that would be useful and testable
>>was QEMU with VMBus. Therefore I thought it made no sense to submit
>>them until VMBus landed in QEMU.
>>
>>Thanks,
>>Roman.
>
>Heh I see, well I'm really happy that you are here helping so we can
>try and finally add VMBus to QEMU, I realize it's a big effort but I'm
>willing to spend the time and do the required changes...
>
>I'm working this only during my free time so things takes me longer
>than usual (sorry for that..)
>
>I will keep update on results once I get to test with latest EDK2 :)
>
>Thanks,
>-- Jon.
Hi, just wanted to update you I did some stupid mistake when I did the
UEFI setup test (that's why I could not boot my Win10).
I suggest we will abandon this patch, and try to keep going on the QEMU
VMBus patchset.
And perhaps submit a very basic patch to SeaBIOS and EDK2 which just
enable SCONTROL.
Does that sound like a good plan to you?
Thanks,
-- Jon.
^ permalink raw reply
* Re: [PATCH v2 0/1] x86/kvm/hyper-v: Add support to SYNIC exit on EOM
From: Roman Kagan @ 2020-05-08 16:56 UTC (permalink / raw)
To: Jon Doron; +Cc: Vitaly Kuznetsov, kvm, linux-hyperv
In-Reply-To: <20200508142954.GH2862@jondnuc>
On Fri, May 08, 2020 at 05:29:54PM +0300, Jon Doron wrote:
> Hi, just wanted to update you I did some stupid mistake when I did the UEFI
> setup test (that's why I could not boot my Win10).
>
> I suggest we will abandon this patch, and try to keep going on the QEMU
> VMBus patchset.
>
> And perhaps submit a very basic patch to SeaBIOS and EDK2 which just enable
> SCONTROL.
>
> Does that sound like a good plan to you?
Absolutely.
Thanks,
Roman.
^ permalink raw reply
* Re: [PATCH] vmbus: Replace zero-length array with flexible-array
From: Wei Liu @ 2020-05-10 12:28 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger, Wei Liu,
linux-hyperv, linux-kernel
In-Reply-To: <20200507185323.GA14416@embeddedor>
On Thu, May 07, 2020 at 01:53:23PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on.
>
> Also, notice that, dynamic memory allocations won't be affected by
> this change:
>
> "Flexible array members have incomplete type, and so the sizeof operator
> may not be applied. As a quirk of the original implementation of
> zero-length arrays, sizeof evaluates to zero."[1]
>
> sizeof(flexible-array-member) triggers a warning because flexible array
> members have incomplete type[1]. There are some instances of code in
> which the sizeof operator is being incorrectly/erroneously applied to
> zero-length arrays and the result is zero. Such instances may be hiding
> some bugs. So, this work (flexible-array member conversions) will also
> help to get completely rid of those sorts of issues.
>
> This issue was found with the help of Coccinelle.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Applied to hyperv-next.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 2/2] PCI: hv: Retry PCI bus D0 entry when the first attempt failed with invalid device state
From: Lorenzo Pieralisi @ 2020-05-11 11:21 UTC (permalink / raw)
To: Wei Hu
Cc: kys, haiyangz, sthemmin, wei.liu, robh, bhelgaas, linux-hyperv,
linux-pci, linux-kernel, decui, mikelley
In-Reply-To: <20200507050300.10974-1-weh@microsoft.com>
On Thu, May 07, 2020 at 01:03:00PM +0800, Wei Hu wrote:
> In the case of kdump, the PCI device was not cleanly shut down
> before the kdump kernel starts. This causes the initial
> attempt of entering D0 state in the kdump kernel to fail with
> invalid device state returned from Hyper-V host.
> When this happens, explicitly call PCI bus exit and retry to
> enter the D0 state.
>
> Signed-off-by: Wei Hu <weh@microsoft.com>
> ---
> v2: Incorporate review comments from Michael Kelley, Dexuan Cui and
> Bjorn Helgaas
>
> drivers/pci/controller/pci-hyperv.c | 40 +++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
Subject: exceeded 80 chars and commit log needed rewording and
paragraphs rewrapping. I did it this time but please pay attention
to commit log content (and format).
Thanks,
Lorenzo
> diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
> index e6fac0187722..92092a47d3af 100644
> --- a/drivers/pci/controller/pci-hyperv.c
> +++ b/drivers/pci/controller/pci-hyperv.c
> @@ -2739,6 +2739,8 @@ static void hv_free_config_window(struct hv_pcibus_device *hbus)
> vmbus_free_mmio(hbus->mem_config->start, PCI_CONFIG_MMIO_LENGTH);
> }
>
> +static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs);
> +
> /**
> * hv_pci_enter_d0() - Bring the "bus" into the D0 power state
> * @hdev: VMBus's tracking struct for this root PCI bus
> @@ -2751,8 +2753,10 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
> struct pci_bus_d0_entry *d0_entry;
> struct hv_pci_compl comp_pkt;
> struct pci_packet *pkt;
> + bool retry = true;
> int ret;
>
> +enter_d0_retry:
> /*
> * Tell the host that the bus is ready to use, and moved into the
> * powered-on state. This includes telling the host which region
> @@ -2779,6 +2783,38 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
> if (ret)
> goto exit;
>
> + /*
> + * In certain case (Kdump) the pci device of interest was
> + * not cleanly shut down and resource is still held on host
> + * side, the host could return invalid device status.
> + * We need to explicitly request host to release the resource
> + * and try to enter D0 again.
> + */
> + if (comp_pkt.completion_status < 0 && retry) {
> + retry = false;
> +
> + dev_err(&hdev->device, "Retrying D0 Entry\n");
> +
> + /*
> + * Hv_pci_bus_exit() calls hv_send_resource_released()
> + * to free up resources of its child devices.
> + * In the kdump kernel we need to set the
> + * wslot_res_allocated to 255 so it scans all child
> + * devices to release resources allocated in the
> + * normal kernel before panic happened.
> + */
> + hbus->wslot_res_allocated = 255;
> +
> + ret = hv_pci_bus_exit(hdev, true);
> +
> + if (ret == 0) {
> + kfree(pkt);
> + goto enter_d0_retry;
> + }
> + dev_err(&hdev->device,
> + "Retrying D0 failed with ret %d\n", ret);
> + }
> +
> if (comp_pkt.completion_status < 0) {
> dev_err(&hdev->device,
> "PCI Pass-through VSP failed D0 Entry with status %x\n",
> @@ -3185,7 +3221,7 @@ static int hv_pci_probe(struct hv_device *hdev,
> return ret;
> }
>
> -static int hv_pci_bus_exit(struct hv_device *hdev, bool hibernating)
> +static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs)
> {
> struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
> struct {
> @@ -3203,7 +3239,7 @@ static int hv_pci_bus_exit(struct hv_device *hdev, bool hibernating)
> if (hdev->channel->rescind)
> return 0;
>
> - if (!hibernating) {
> + if (!keep_devs) {
> /* Delete any children which might still exist. */
> dr = kzalloc(sizeof(*dr), GFP_KERNEL);
> if (dr && hv_pci_start_relations_work(hbus, dr))
> --
> 2.20.1
>
^ permalink raw reply
* Re: [PATCH v3 0/2] Fix PCI HyperV device error handling
From: Lorenzo Pieralisi @ 2020-05-11 11:21 UTC (permalink / raw)
To: Wei Hu
Cc: kys, haiyangz, sthemmin, wei.liu, robh, bhelgaas, linux-hyperv,
linux-pci, linux-kernel, decui, mikelley
In-Reply-To: <20200507050126.10871-1-weh@microsoft.com>
On Thu, May 07, 2020 at 01:01:26PM +0800, Wei Hu wrote:
> This series better handles some PCI HyperV error cases in general
> and for kdump case. Some of review comments from previous individual
> patch reviews, including splitting into separate patches, have already
> been incorporated. Thanks Lorenzo Pieralisi for the review and
> suggestions, as well as Michael Kelley's contribution to the commit
> log.
>
> Thanks,
> Wei
>
>
> Wei Hu (2):
> PCI: hv: Fix the PCI HyperV probe failure path to release resource
> properly
> PCI: hv: Retry PCI bus D0 entry when the first attempt failed with
> invalid device state
>
> drivers/pci/controller/pci-hyperv.c | 60 ++++++++++++++++++++++++++---
> 1 file changed, 54 insertions(+), 6 deletions(-)
Applied to pci/hv, thanks.
Lorenzo
^ permalink raw reply
* RE: [PATCH v3 2/2] PCI: hv: Retry PCI bus D0 entry when the first attempt failed with invalid device state
From: Wei Hu @ 2020-05-11 14:11 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: KY Srinivasan, Haiyang Zhang, Stephen Hemminger,
wei.liu@kernel.org, robh@kernel.org, bhelgaas@google.com,
linux-hyperv@vger.kernel.org, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, Dexuan Cui, Michael Kelley
In-Reply-To: <20200511112112.GC24954@e121166-lin.cambridge.arm.com>
> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Sent: Monday, May 11, 2020 7:21 PM
> To: Wei Hu <weh@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger <sthemmin@microsoft.com>;
> wei.liu@kernel.org; robh@kernel.org; bhelgaas@google.com; linux-
> hyperv@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org; Dexuan Cui <decui@microsoft.com>; Michael Kelley
> <mikelley@microsoft.com>
> Subject: Re: [PATCH v3 2/2] PCI: hv: Retry PCI bus D0 entry when the first
> attempt failed with invalid device state
>
> On Thu, May 07, 2020 at 01:03:00PM +0800, Wei Hu wrote:
> > In the case of kdump, the PCI device was not cleanly shut down before
> > the kdump kernel starts. This causes the initial attempt of entering
> > D0 state in the kdump kernel to fail with invalid device state
> > returned from Hyper-V host.
> > When this happens, explicitly call PCI bus exit and retry to enter the
> > D0 state.
> >
> > Signed-off-by: Wei Hu <weh@microsoft.com>
> > ---
> > v2: Incorporate review comments from Michael Kelley, Dexuan Cui and
> > Bjorn Helgaas
> >
> > drivers/pci/controller/pci-hyperv.c | 40
> > +++++++++++++++++++++++++++--
> > 1 file changed, 38 insertions(+), 2 deletions(-)
>
> Subject: exceeded 80 chars and commit log needed rewording and paragraphs
> rewrapping. I did it this time but please pay attention to commit log content
> (and format).
Got it. Thanks much for correcting it for me this time!
Wei
>
> Thanks,
> Lorenzo
>
^ permalink raw reply
* Re: [PATCH] PCI: export and use pci_msi_get_hwirq in pci-hyperv.c
From: Wei Liu @ 2020-05-11 15:32 UTC (permalink / raw)
To: Rob Herring
Cc: Wei Liu, linux-pci, linux-hyperv, linux-kernel, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, x86,
K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger,
Lorenzo Pieralisi, Andrew Murray, Bjorn Helgaas, Allison Randal,
Greg Kroah-Hartman, Enrico Weigelt
In-Reply-To: <20200507205831.GA30988@bogus>
On Thu, May 07, 2020 at 03:58:31PM -0500, Rob Herring wrote:
> On Wed, Apr 22, 2020 at 07:58:15PM +0000, Wei Liu wrote:
> > There is a functionally identical function in pci-hyperv.c. Drop it and
> > use pci_msi_get_hwirq instead.
> >
> > This requires exporting pci_msi_get_hwirq and declaring it in msi.h.
> >
> > No functional change intended.
> >
> > Signed-off-by: Wei Liu <wei.liu@kernel.org>
> > ---
> > arch/x86/include/asm/msi.h | 4 ++++
> > arch/x86/kernel/apic/msi.c | 5 +++--
> > drivers/pci/controller/pci-hyperv.c | 8 +-------
> > 3 files changed, 8 insertions(+), 9 deletions(-)
>
> Would be better if done in a way to remove an x86 dependency.
This is a good point, Rob. I will see what I can do.
Wei.
>
> I guess this would do it:
>
> #define pci_msi_get_hwirq NULL
>
> when GENERIC_MSI_DOMAIN_OPS is enabled.
^ permalink raw reply
* Re: [PATCH v11 6/7] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls
From: Roman Kagan @ 2020-05-12 15:33 UTC (permalink / raw)
To: Jon Doron; +Cc: kvm, linux-hyperv, vkuznets
In-Reply-To: <20200424113746.3473563-7-arilou@gmail.com>
On Fri, Apr 24, 2020 at 02:37:45PM +0300, Jon Doron wrote:
> There is another mode for the synthetic debugger which uses hypercalls
> to send/recv network data instead of the MSR interface.
>
> This interface is much slower and less recommended since you might get
> a lot of VMExits while KDVM polling for new packets to recv, rather
> than simply checking the pending page to see if there is data avialble
> and then request.
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Jon Doron <arilou@gmail.com>
> ---
> arch/x86/kvm/hyperv.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 524b5466a515..744bcef88c70 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -1832,6 +1832,34 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> }
> ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
> break;
> + case HVCALL_POST_DEBUG_DATA:
> + case HVCALL_RETRIEVE_DEBUG_DATA:
> + if (unlikely(fast)) {
> + ret = HV_STATUS_INVALID_PARAMETER;
> + break;
> + }
> + fallthrough;
> + case HVCALL_RESET_DEBUG_SESSION: {
> + struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu);
> +
> + if (!syndbg->active) {
> + ret = HV_STATUS_INVALID_HYPERCALL_CODE;
> + break;
> + }
> +
> + if (!(syndbg->options & HV_X64_SYNDBG_OPTION_USE_HCALLS)) {
> + ret = HV_STATUS_OPERATION_DENIED;
> + break;
> + }
> + vcpu->run->exit_reason = KVM_EXIT_HYPERV;
> + vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
> + vcpu->run->hyperv.u.hcall.input = param;
> + vcpu->run->hyperv.u.hcall.params[0] = ingpa;
> + vcpu->run->hyperv.u.hcall.params[1] = outgpa;
> + vcpu->arch.complete_userspace_io =
> + kvm_hv_hypercall_complete_userspace;
> + return 0;
> + }
I'd personally just push every hyperv hypercall not recognized by the
kernel to userspace. Smth like this:
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index bcefa9d4e57e..f0404df0f488 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -1644,6 +1644,48 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
}
kvm_vcpu_on_spin(vcpu, true);
break;
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
+ if (unlikely(fast || !rep_cnt || rep_idx)) {
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ break;
+ }
+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
+ break;
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
+ if (unlikely(fast || rep)) {
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ break;
+ }
+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
+ break;
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
+ if (unlikely(fast || !rep_cnt || rep_idx)) {
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ break;
+ }
+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
+ break;
+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
+ if (unlikely(fast || rep)) {
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ break;
+ }
+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
+ break;
+ case HVCALL_SEND_IPI:
+ if (unlikely(rep)) {
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ break;
+ }
+ ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, false, fast);
+ break;
+ case HVCALL_SEND_IPI_EX:
+ if (unlikely(fast || rep)) {
+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
+ break;
+ }
+ ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
+ break;
case HVCALL_SIGNAL_EVENT:
if (unlikely(rep)) {
ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
@@ -1653,12 +1695,8 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
if (ret != HV_STATUS_INVALID_PORT_ID)
break;
/* fall through - maybe userspace knows this conn_id. */
- case HVCALL_POST_MESSAGE:
- /* don't bother userspace if it has no way to handle it */
- if (unlikely(rep || !vcpu_to_synic(vcpu)->active)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
+ default:
+ /* forward unrecognized hypercalls to userspace */
vcpu->run->exit_reason = KVM_EXIT_HYPERV;
vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
vcpu->run->hyperv.u.hcall.input = param;
@@ -1667,51 +1705,6 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
vcpu->arch.complete_userspace_io =
kvm_hv_hypercall_complete_userspace;
return 0;
- case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
- if (unlikely(fast || !rep_cnt || rep_idx)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
- break;
- case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
- if (unlikely(fast || rep)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
- break;
- case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
- if (unlikely(fast || !rep_cnt || rep_idx)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
- break;
- case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
- if (unlikely(fast || rep)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
- break;
- case HVCALL_SEND_IPI:
- if (unlikely(rep)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
- ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, false, fast);
- break;
- case HVCALL_SEND_IPI_EX:
- if (unlikely(fast || rep)) {
- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
- break;
- }
- ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
- break;
- default:
- ret = HV_STATUS_INVALID_HYPERCALL_CODE;
- break;
}
return kvm_hv_hypercall_complete(vcpu, ret);
(would also need a kvm cap for that)
Roman.
^ permalink raw reply related
* [PATCH] x86/hyperv: Properly suspend/resume reenlightenment notifications
From: Vitaly Kuznetsov @ 2020-05-12 16:01 UTC (permalink / raw)
To: linux-hyperv
Cc: Wei Liu, x86, linux-kernel, kvm, Michael Kelley, Dexuan Cui,
Tianyu Lan
Errors during hibernation with reenlightenment notifications enabled were
reported:
[ 51.730435] PM: hibernation entry
[ 51.737435] PM: Syncing filesystems ...
...
[ 54.102216] Disabling non-boot CPUs ...
[ 54.106633] smpboot: CPU 1 is now offline
[ 54.110006] unchecked MSR access error: WRMSR to 0x40000106 (tried to
write 0x47c72780000100ee) at rIP: 0xffffffff90062f24
native_write_msr+0x4/0x20)
[ 54.110006] Call Trace:
[ 54.110006] hv_cpu_die+0xd9/0xf0
...
Normally, hv_cpu_die() just reassigns reenlightenment notifications to some
other CPU when the CPU receiving them goes offline. Upon hibernation, there
is no other CPU which is still online so cpumask_any_but(cpu_online_mask)
returns >= nr_cpu_ids and using it as hv_vp_index index is incorrect.
Disable the feature when cpumask_any_but() fails.
Also, as we now disable reenlightenment notifications upon hibernation we
need to restore them on resume. Check if hv_reenlightenment_cb was
previously set and restore from hv_resume().
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
arch/x86/hyperv/hv_init.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index fd51bac11b46..acf76b466db6 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -226,10 +226,18 @@ static int hv_cpu_die(unsigned int cpu)
rdmsrl(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
if (re_ctrl.target_vp == hv_vp_index[cpu]) {
- /* Reassign to some other online CPU */
+ /*
+ * Reassign reenlightenment notifications to some other online
+ * CPU or just disable the feature if there are no online CPUs
+ * left (happens on hibernation).
+ */
new_cpu = cpumask_any_but(cpu_online_mask, cpu);
- re_ctrl.target_vp = hv_vp_index[new_cpu];
+ if (new_cpu < nr_cpu_ids)
+ re_ctrl.target_vp = hv_vp_index[new_cpu];
+ else
+ re_ctrl.enabled = 0;
+
wrmsrl(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
}
@@ -293,6 +301,13 @@ static void hv_resume(void)
hv_hypercall_pg = hv_hypercall_pg_saved;
hv_hypercall_pg_saved = NULL;
+
+ /*
+ * Reenlightenment notifications are disabled by hv_cpu_die(0),
+ * reenable them here if hv_reenlightenment_cb was previously set.
+ */
+ if (hv_reenlightenment_cb)
+ set_hv_tscchange_cb(hv_reenlightenment_cb);
}
/* Note: when the ops are called, only CPU0 is online and IRQs are disabled. */
--
2.25.4
^ permalink raw reply related
* RE: [PATCH] x86/hyperv: Properly suspend/resume reenlightenment notifications
From: Dexuan Cui @ 2020-05-12 21:03 UTC (permalink / raw)
To: vkuznets, linux-hyperv@vger.kernel.org
Cc: Wei Liu, x86@kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Michael Kelley, Tianyu Lan
In-Reply-To: <20200512160153.134467-1-vkuznets@redhat.com>
> From: Vitaly Kuznetsov <vkuznets@redhat.com>
> Sent: Tuesday, May 12, 2020 9:02 AM
> To: linux-hyperv@vger.kernel.org
> Cc: Wei Liu <wei.liu@kernel.org>; x86@kernel.org;
> linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Michael Kelley
> <mikelley@microsoft.com>; Dexuan Cui <decui@microsoft.com>; Tianyu Lan
> <Tianyu.Lan@microsoft.com>
> Subject: [PATCH] x86/hyperv: Properly suspend/resume reenlightenment
> notifications
>
> Errors during hibernation with reenlightenment notifications enabled were
> reported:
>
> [ 51.730435] PM: hibernation entry
> [ 51.737435] PM: Syncing filesystems ...
> ...
> [ 54.102216] Disabling non-boot CPUs ...
> [ 54.106633] smpboot: CPU 1 is now offline
> [ 54.110006] unchecked MSR access error: WRMSR to 0x40000106 (tried
> to
> write 0x47c72780000100ee) at rIP: 0xffffffff90062f24
> native_write_msr+0x4/0x20)
> [ 54.110006] Call Trace:
> [ 54.110006] hv_cpu_die+0xd9/0xf0
> ...
>
> Normally, hv_cpu_die() just reassigns reenlightenment notifications to some
> other CPU when the CPU receiving them goes offline. Upon hibernation, there
> is no other CPU which is still online so cpumask_any_but(cpu_online_mask)
> returns >= nr_cpu_ids and using it as hv_vp_index index is incorrect.
> Disable the feature when cpumask_any_but() fails.
>
> Also, as we now disable reenlightenment notifications upon hibernation we
> need to restore them on resume. Check if hv_reenlightenment_cb was
> previously set and restore from hv_resume().
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
Looks good to me. Thanks!
Reviewed-by: Dexuan Cui <decui@microsoft.com>
^ permalink raw reply
* Re: [PATCH v11 1/7] x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit
From: Roman Kagan @ 2020-05-13 8:42 UTC (permalink / raw)
To: Jon Doron; +Cc: kvm, linux-hyperv, vkuznets
In-Reply-To: <20200424113746.3473563-2-arilou@gmail.com>
On Fri, Apr 24, 2020 at 02:37:40PM +0300, Jon Doron wrote:
> The problem the patch is trying to address is the fact that 'struct
> kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit
> modes.
>
> In 64-bit mode the default alignment boundary is 64 bits thus
> forcing extra gaps after 'type' and 'msr' but in 32-bit mode the
> boundary is at 32 bits thus no extra gaps.
>
> This is an issue as even when the kernel is 64 bit, the userspace using
> the interface can be both 32 and 64 bit but the same 32 bit userspace has
> to work with 32 bit kernel.
>
> The issue is fixed by forcing the 64 bit layout, this leads to ABI
> change for 32 bit builds and while we are obviously breaking '32 bit
> userspace with 32 bit kernel' case, we're fixing the '32 bit userspace
> with 64 bit kernel' one.
>
> As the interface has no (known) users and 32 bit KVM is rather baroque
> nowadays, this seems like a reasonable decision.
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Jon Doron <arilou@gmail.com>
> ---
> Documentation/virt/kvm/api.rst | 2 ++
> include/uapi/linux/kvm.h | 2 ++
> 2 files changed, 4 insertions(+)
Reviewed-by: Roman Kagan <rvkagan@yandex-team.ru>
^ permalink raw reply
* Re: [PATCH v11 2/7] x86/kvm/hyper-v: Simplify addition for custom cpuid leafs
From: Roman Kagan @ 2020-05-13 9:24 UTC (permalink / raw)
To: Jon Doron; +Cc: kvm, linux-hyperv, vkuznets
In-Reply-To: <20200424113746.3473563-3-arilou@gmail.com>
On Fri, Apr 24, 2020 at 02:37:41PM +0300, Jon Doron wrote:
> Simlify the code to define a new cpuid leaf group by enabled feature.
>
> This also fixes a bug in which the max cpuid leaf was always set to
> HYPERV_CPUID_NESTED_FEATURES regardless if nesting is supported or not.
I'm not sure the bug is there. My understanding is that
HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS is supposed to provide the range
of leaves that return meaningful information.
HYPERV_CPUID_NESTED_FEATURES *can* return meaningful information
regardless of whether nested virt is active.
So I'd rather skip reducing the returned set if !evmcs_ver. The
returned set is sparse in .function anyway; anything that isn't there
will just return zeros to the guest.
Changing the cpuid is also guest-visible so care must be taken with
this.
> Any new CPUID group needs to consider the max leaf and be added in the
> correct order, in this method there are two rules:
> 1. Each cpuid leaf group must be order in an ascending order
> 2. The appending for the cpuid leafs by features also needs to happen by
> ascending order.
It looks like unnecessary complication. I think all you need to do to
simplify adding new leaves is to add a macro to hyperv-tlfs.h, say,
HYPERV_CPUID_MAX_PRESENT_LEAF, define it to
HYPERV_CPUID_NESTED_FEATURES, and redefine once another leaf is added
(compat may need to be taken care of).
Thanks,
Roman.
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Jon Doron <arilou@gmail.com>
> ---
> arch/x86/kvm/hyperv.c | 46 ++++++++++++++++++++++++++++++-------------
> 1 file changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index bcefa9d4e57e..ab3e9dbcabbe 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -1785,27 +1785,45 @@ int kvm_vm_ioctl_hv_eventfd(struct kvm *kvm, struct kvm_hyperv_eventfd *args)
> return kvm_hv_eventfd_assign(kvm, args->conn_id, args->fd);
> }
>
> +/* Must be sorted in ascending order by function */
> +static struct kvm_cpuid_entry2 core_cpuid_entries[] = {
> + { .function = HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS },
> + { .function = HYPERV_CPUID_INTERFACE },
> + { .function = HYPERV_CPUID_VERSION },
> + { .function = HYPERV_CPUID_FEATURES },
> + { .function = HYPERV_CPUID_ENLIGHTMENT_INFO },
> + { .function = HYPERV_CPUID_IMPLEMENT_LIMITS },
> +};
> +
> +static struct kvm_cpuid_entry2 evmcs_cpuid_entries[] = {
> + { .function = HYPERV_CPUID_NESTED_FEATURES },
> +};
> +
> +#define HV_MAX_CPUID_ENTRIES \
> + (ARRAY_SIZE(core_cpuid_entries) +\
> + ARRAY_SIZE(evmcs_cpuid_entries))
> +
> int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
> struct kvm_cpuid_entry2 __user *entries)
> {
> uint16_t evmcs_ver = 0;
> - struct kvm_cpuid_entry2 cpuid_entries[] = {
> - { .function = HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS },
> - { .function = HYPERV_CPUID_INTERFACE },
> - { .function = HYPERV_CPUID_VERSION },
> - { .function = HYPERV_CPUID_FEATURES },
> - { .function = HYPERV_CPUID_ENLIGHTMENT_INFO },
> - { .function = HYPERV_CPUID_IMPLEMENT_LIMITS },
> - { .function = HYPERV_CPUID_NESTED_FEATURES },
> - };
> - int i, nent = ARRAY_SIZE(cpuid_entries);
> + struct kvm_cpuid_entry2 cpuid_entries[HV_MAX_CPUID_ENTRIES];
> + int i, nent = 0;
> +
> + /* Set the core cpuid entries required for Hyper-V */
> + memcpy(&cpuid_entries[nent], &core_cpuid_entries,
> + sizeof(core_cpuid_entries));
> + nent = ARRAY_SIZE(core_cpuid_entries);
>
> if (kvm_x86_ops.nested_get_evmcs_version)
> evmcs_ver = kvm_x86_ops.nested_get_evmcs_version(vcpu);
>
> - /* Skip NESTED_FEATURES if eVMCS is not supported */
> - if (!evmcs_ver)
> - --nent;
> + if (evmcs_ver) {
> + /* EVMCS is enabled, add the required EVMCS CPUID leafs */
> + memcpy(&cpuid_entries[nent], &evmcs_cpuid_entries,
> + sizeof(evmcs_cpuid_entries));
> + nent += ARRAY_SIZE(evmcs_cpuid_entries);
> + }
>
> if (cpuid->nent < nent)
> return -E2BIG;
> @@ -1821,7 +1839,7 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
> case HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS:
> memcpy(signature, "Linux KVM Hv", 12);
>
> - ent->eax = HYPERV_CPUID_NESTED_FEATURES;
> + ent->eax = cpuid_entries[nent - 1].function;
> ent->ebx = signature[0];
> ent->ecx = signature[1];
> ent->edx = signature[2];
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH v11 5/7] x86/kvm/hyper-v: enable hypercalls without hypercall page with syndbg
From: Roman Kagan @ 2020-05-13 9:57 UTC (permalink / raw)
To: Jon Doron; +Cc: kvm, linux-hyperv, vkuznets
In-Reply-To: <20200424113746.3473563-6-arilou@gmail.com>
On Fri, Apr 24, 2020 at 02:37:44PM +0300, Jon Doron wrote:
> Microsoft's kdvm.dll dbgtransport module does not respect the hypercall
> page and simply identifies the CPU being used (AMD/Intel) and according
> to it simply makes hypercalls with the relevant instruction
> (vmmcall/vmcall respectively).
>
> The relevant function in kdvm is KdHvConnectHypervisor which first checks
> if the hypercall page has been enabled via HV_X64_MSR_HYPERCALL_ENABLE,
> and in case it was not it simply sets the HV_X64_MSR_GUEST_OS_ID to
> 0x1000101010001 which means:
> build_number = 0x0001
> service_version = 0x01
> minor_version = 0x01
> major_version = 0x01
> os_id = 0x00 (Undefined)
> vendor_id = 1 (Microsoft)
> os_type = 0 (A value of 0 indicates a proprietary, closed source OS)
>
> and starts issuing the hypercall without setting the hypercall page.
I guess this is to avoid interfering with the OS being debugged
requesting its own hypercall page at a different address.
> To resolve this issue simply enable hypercalls also if the guest_os_id
> is not 0 and the syndbg feature is enabled.
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Signed-off-by: Jon Doron <arilou@gmail.com>
> ---
> arch/x86/kvm/hyperv.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index 435516595090..524b5466a515 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -1650,7 +1650,10 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *current_vcpu, u64 ingpa, u64 outgpa,
>
> bool kvm_hv_hypercall_enabled(struct kvm *kvm)
> {
> - return READ_ONCE(kvm->arch.hyperv.hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE;
> + struct kvm_hv *hv = &kvm->arch.hyperv;
> +
> + return READ_ONCE(hv->hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE ||
> + (hv->hv_syndbg.active && READ_ONCE(hv->hv_guest_os_id) != 0);
This function is meant to tell if the hypercall should be interpreted as
following KVM or HyperV conventions. Quoting from the spec
3.5 Legal Hypercall Environments
...
All hypercalls should be invoked through the architecturally-defined
hypercall interface. (See the following sections for instructions on
discovering and establishing this interface.) An attempt to invoke a
hypercall by any other means (for example, copying the code from the
hypercall code page to an alternate location and executing it from
there) might result in an undefined operation (#UD) exception. The
hypervisor is not guaranteed to deliver this exception.
so I think we can simply test for hv_guest_os_id != 0 and ignore
HV_X64_MSR_HYPERCALL_ENABLE (it's about hypercall page being enabled,
not the hypercalls per se).
Thanks,
Roman.
> }
>
> static void kvm_hv_hypercall_set_result(struct kvm_vcpu *vcpu, u64 result)
> --
> 2.24.1
>
^ permalink raw reply
* Re: [PATCH v11 5/7] x86/kvm/hyper-v: enable hypercalls without hypercall page with syndbg
From: Jon Doron @ 2020-05-13 12:37 UTC (permalink / raw)
To: Roman Kagan, kvm, linux-hyperv, vkuznets
In-Reply-To: <20200513095738.GC29650@rvkaganb.lan>
On 13/05/2020, Roman Kagan wrote:
>On Fri, Apr 24, 2020 at 02:37:44PM +0300, Jon Doron wrote:
>> Microsoft's kdvm.dll dbgtransport module does not respect the hypercall
>> page and simply identifies the CPU being used (AMD/Intel) and according
>> to it simply makes hypercalls with the relevant instruction
>> (vmmcall/vmcall respectively).
>>
>> The relevant function in kdvm is KdHvConnectHypervisor which first checks
>> if the hypercall page has been enabled via HV_X64_MSR_HYPERCALL_ENABLE,
>> and in case it was not it simply sets the HV_X64_MSR_GUEST_OS_ID to
>> 0x1000101010001 which means:
>> build_number = 0x0001
>> service_version = 0x01
>> minor_version = 0x01
>> major_version = 0x01
>> os_id = 0x00 (Undefined)
>> vendor_id = 1 (Microsoft)
>> os_type = 0 (A value of 0 indicates a proprietary, closed source OS)
>>
>> and starts issuing the hypercall without setting the hypercall page.
>
>I guess this is to avoid interfering with the OS being debugged
>requesting its own hypercall page at a different address.
>
>> To resolve this issue simply enable hypercalls also if the guest_os_id
>> is not 0 and the syndbg feature is enabled.
>>
>> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Signed-off-by: Jon Doron <arilou@gmail.com>
>> ---
>> arch/x86/kvm/hyperv.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index 435516595090..524b5466a515 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1650,7 +1650,10 @@ static u64 kvm_hv_send_ipi(struct kvm_vcpu *current_vcpu, u64 ingpa, u64 outgpa,
>>
>> bool kvm_hv_hypercall_enabled(struct kvm *kvm)
>> {
>> - return READ_ONCE(kvm->arch.hyperv.hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE;
>> + struct kvm_hv *hv = &kvm->arch.hyperv;
>> +
>> + return READ_ONCE(hv->hv_hypercall) & HV_X64_MSR_HYPERCALL_ENABLE ||
>> + (hv->hv_syndbg.active && READ_ONCE(hv->hv_guest_os_id) != 0);
>
>This function is meant to tell if the hypercall should be interpreted as
>following KVM or HyperV conventions. Quoting from the spec
>
> 3.5 Legal Hypercall Environments
>
> ...
> All hypercalls should be invoked through the architecturally-defined
> hypercall interface. (See the following sections for instructions on
> discovering and establishing this interface.) An attempt to invoke a
> hypercall by any other means (for example, copying the code from the
> hypercall code page to an alternate location and executing it from
> there) might result in an undefined operation (#UD) exception. The
> hypervisor is not guaranteed to deliver this exception.
>
>so I think we can simply test for hv_guest_os_id != 0 and ignore
>HV_X64_MSR_HYPERCALL_ENABLE (it's about hypercall page being enabled,
>not the hypercalls per se).
>
>Thanks,
>Roman.
>
>> }
>>
>> static void kvm_hv_hypercall_set_result(struct kvm_vcpu *vcpu, u64 result)
>> --
>> 2.24.1
>>
Hi Roman,
I agree this was the original implementation of this patchset (see v1) I
will send a v12 with the suggested change, but I would prefer that you
will review the mailing list previous comments which caused to this
specific behaviour.
Thanks,
-- Jon.
^ permalink raw reply
* Re: [PATCH v11 6/7] x86/kvm/hyper-v: Add support for synthetic debugger via hypercalls
From: Jon Doron @ 2020-05-13 12:39 UTC (permalink / raw)
To: Roman Kagan, kvm, linux-hyperv, vkuznets
In-Reply-To: <20200512153353.GB9944@rvkaganb.lan>
On 12/05/2020, Roman Kagan wrote:
>On Fri, Apr 24, 2020 at 02:37:45PM +0300, Jon Doron wrote:
>> There is another mode for the synthetic debugger which uses hypercalls
>> to send/recv network data instead of the MSR interface.
>>
>> This interface is much slower and less recommended since you might get
>> a lot of VMExits while KDVM polling for new packets to recv, rather
>> than simply checking the pending page to see if there is data avialble
>> and then request.
>>
>> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Signed-off-by: Jon Doron <arilou@gmail.com>
>> ---
>> arch/x86/kvm/hyperv.c | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index 524b5466a515..744bcef88c70 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1832,6 +1832,34 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>> }
>> ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
>> break;
>> + case HVCALL_POST_DEBUG_DATA:
>> + case HVCALL_RETRIEVE_DEBUG_DATA:
>> + if (unlikely(fast)) {
>> + ret = HV_STATUS_INVALID_PARAMETER;
>> + break;
>> + }
>> + fallthrough;
>> + case HVCALL_RESET_DEBUG_SESSION: {
>> + struct kvm_hv_syndbg *syndbg = vcpu_to_hv_syndbg(vcpu);
>> +
>> + if (!syndbg->active) {
>> + ret = HV_STATUS_INVALID_HYPERCALL_CODE;
>> + break;
>> + }
>> +
>> + if (!(syndbg->options & HV_X64_SYNDBG_OPTION_USE_HCALLS)) {
>> + ret = HV_STATUS_OPERATION_DENIED;
>> + break;
>> + }
>> + vcpu->run->exit_reason = KVM_EXIT_HYPERV;
>> + vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
>> + vcpu->run->hyperv.u.hcall.input = param;
>> + vcpu->run->hyperv.u.hcall.params[0] = ingpa;
>> + vcpu->run->hyperv.u.hcall.params[1] = outgpa;
>> + vcpu->arch.complete_userspace_io =
>> + kvm_hv_hypercall_complete_userspace;
>> + return 0;
>> + }
>
>I'd personally just push every hyperv hypercall not recognized by the
>kernel to userspace. Smth like this:
>
>diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>index bcefa9d4e57e..f0404df0f488 100644
>--- a/arch/x86/kvm/hyperv.c
>+++ b/arch/x86/kvm/hyperv.c
>@@ -1644,6 +1644,48 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> }
> kvm_vcpu_on_spin(vcpu, true);
> break;
>+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
>+ if (unlikely(fast || !rep_cnt || rep_idx)) {
>+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+ break;
>+ }
>+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>+ break;
>+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
>+ if (unlikely(fast || rep)) {
>+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+ break;
>+ }
>+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>+ break;
>+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
>+ if (unlikely(fast || !rep_cnt || rep_idx)) {
>+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+ break;
>+ }
>+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>+ break;
>+ case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
>+ if (unlikely(fast || rep)) {
>+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+ break;
>+ }
>+ ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>+ break;
>+ case HVCALL_SEND_IPI:
>+ if (unlikely(rep)) {
>+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+ break;
>+ }
>+ ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, false, fast);
>+ break;
>+ case HVCALL_SEND_IPI_EX:
>+ if (unlikely(fast || rep)) {
>+ ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>+ break;
>+ }
>+ ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
>+ break;
> case HVCALL_SIGNAL_EVENT:
> if (unlikely(rep)) {
> ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>@@ -1653,12 +1695,8 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> if (ret != HV_STATUS_INVALID_PORT_ID)
> break;
> /* fall through - maybe userspace knows this conn_id. */
>- case HVCALL_POST_MESSAGE:
>- /* don't bother userspace if it has no way to handle it */
>- if (unlikely(rep || !vcpu_to_synic(vcpu)->active)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>+ default:
>+ /* forward unrecognized hypercalls to userspace */
> vcpu->run->exit_reason = KVM_EXIT_HYPERV;
> vcpu->run->hyperv.type = KVM_EXIT_HYPERV_HCALL;
> vcpu->run->hyperv.u.hcall.input = param;
>@@ -1667,51 +1705,6 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
> vcpu->arch.complete_userspace_io =
> kvm_hv_hypercall_complete_userspace;
> return 0;
>- case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST:
>- if (unlikely(fast || !rep_cnt || rep_idx)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>- break;
>- case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE:
>- if (unlikely(fast || rep)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, false);
>- break;
>- case HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX:
>- if (unlikely(fast || !rep_cnt || rep_idx)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>- break;
>- case HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE_EX:
>- if (unlikely(fast || rep)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>- ret = kvm_hv_flush_tlb(vcpu, ingpa, rep_cnt, true);
>- break;
>- case HVCALL_SEND_IPI:
>- if (unlikely(rep)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>- ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, false, fast);
>- break;
>- case HVCALL_SEND_IPI_EX:
>- if (unlikely(fast || rep)) {
>- ret = HV_STATUS_INVALID_HYPERCALL_INPUT;
>- break;
>- }
>- ret = kvm_hv_send_ipi(vcpu, ingpa, outgpa, true, false);
>- break;
>- default:
>- ret = HV_STATUS_INVALID_HYPERCALL_CODE;
>- break;
> }
>
> return kvm_hv_hypercall_complete(vcpu, ret);
>
>(would also need a kvm cap for that)
>
>Roman.
This looks like a good idea, but I think it should be part of another
patchset, I could revise one once this is in and expose a new CAP, and
we need to make sure QEMU can handle this and wont just crash getting
these additional exits.
-- Jon.
^ permalink raw reply
* Re: [PATCH v11 2/7] x86/kvm/hyper-v: Simplify addition for custom cpuid leafs
From: Jon Doron @ 2020-05-13 12:49 UTC (permalink / raw)
To: Roman Kagan, kvm, linux-hyperv, vkuznets
In-Reply-To: <20200513092404.GB29650@rvkaganb.lan>
On 13/05/2020, Roman Kagan wrote:
>On Fri, Apr 24, 2020 at 02:37:41PM +0300, Jon Doron wrote:
>> Simlify the code to define a new cpuid leaf group by enabled feature.
>>
>> This also fixes a bug in which the max cpuid leaf was always set to
>> HYPERV_CPUID_NESTED_FEATURES regardless if nesting is supported or not.
>
>I'm not sure the bug is there. My understanding is that
>HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS is supposed to provide the range
>of leaves that return meaningful information.
>HYPERV_CPUID_NESTED_FEATURES *can* return meaningful information
>regardless of whether nested virt is active.
>
>So I'd rather skip reducing the returned set if !evmcs_ver. The
>returned set is sparse in .function anyway; anything that isn't there
>will just return zeros to the guest.
>
>Changing the cpuid is also guest-visible so care must be taken with
>this.
>
To be honest from my understanding of the TLFS it states:
"The maximum input value for hypervisor CPUID information."
So we should not expose stuff we wont "answer" to, I agree you can
always issue CPUID to any leaf and you will get zeroes but if we try to
follow TLFS it sounds like this needs to be capped here.
>> Any new CPUID group needs to consider the max leaf and be added in the
>> correct order, in this method there are two rules:
>> 1. Each cpuid leaf group must be order in an ascending order
>> 2. The appending for the cpuid leafs by features also needs to happen by
>> ascending order.
>
>It looks like unnecessary complication. I think all you need to do to
>simplify adding new leaves is to add a macro to hyperv-tlfs.h, say,
>HYPERV_CPUID_MAX_PRESENT_LEAF, define it to
>HYPERV_CPUID_NESTED_FEATURES, and redefine once another leaf is added
>(compat may need to be taken care of).
>
>Thanks,
>Roman.
>
I suggest you will see the discussion around v8 of this patchset where I
simply set HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS to be the maximum
value, but then we noticed this issue and hence why this patch was
revised to current form. (I agree it could be done under the TLFS header
file but as I understand from other emails from Michal it's going to get
re-worked a bit and splitted, still have not got into the details of
that work).
Thanks,
-- Jon.
>> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>> Signed-off-by: Jon Doron <arilou@gmail.com>
>> ---
>> arch/x86/kvm/hyperv.c | 46 ++++++++++++++++++++++++++++++-------------
>> 1 file changed, 32 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index bcefa9d4e57e..ab3e9dbcabbe 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1785,27 +1785,45 @@ int kvm_vm_ioctl_hv_eventfd(struct kvm *kvm, struct kvm_hyperv_eventfd *args)
>> return kvm_hv_eventfd_assign(kvm, args->conn_id, args->fd);
>> }
>>
>> +/* Must be sorted in ascending order by function */
>> +static struct kvm_cpuid_entry2 core_cpuid_entries[] = {
>> + { .function = HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS },
>> + { .function = HYPERV_CPUID_INTERFACE },
>> + { .function = HYPERV_CPUID_VERSION },
>> + { .function = HYPERV_CPUID_FEATURES },
>> + { .function = HYPERV_CPUID_ENLIGHTMENT_INFO },
>> + { .function = HYPERV_CPUID_IMPLEMENT_LIMITS },
>> +};
>> +
>> +static struct kvm_cpuid_entry2 evmcs_cpuid_entries[] = {
>> + { .function = HYPERV_CPUID_NESTED_FEATURES },
>> +};
>> +
>> +#define HV_MAX_CPUID_ENTRIES \
>> + (ARRAY_SIZE(core_cpuid_entries) +\
>> + ARRAY_SIZE(evmcs_cpuid_entries))
>> +
>> int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
>> struct kvm_cpuid_entry2 __user *entries)
>> {
>> uint16_t evmcs_ver = 0;
>> - struct kvm_cpuid_entry2 cpuid_entries[] = {
>> - { .function = HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS },
>> - { .function = HYPERV_CPUID_INTERFACE },
>> - { .function = HYPERV_CPUID_VERSION },
>> - { .function = HYPERV_CPUID_FEATURES },
>> - { .function = HYPERV_CPUID_ENLIGHTMENT_INFO },
>> - { .function = HYPERV_CPUID_IMPLEMENT_LIMITS },
>> - { .function = HYPERV_CPUID_NESTED_FEATURES },
>> - };
>> - int i, nent = ARRAY_SIZE(cpuid_entries);
>> + struct kvm_cpuid_entry2 cpuid_entries[HV_MAX_CPUID_ENTRIES];
>> + int i, nent = 0;
>> +
>> + /* Set the core cpuid entries required for Hyper-V */
>> + memcpy(&cpuid_entries[nent], &core_cpuid_entries,
>> + sizeof(core_cpuid_entries));
>> + nent = ARRAY_SIZE(core_cpuid_entries);
>>
>> if (kvm_x86_ops.nested_get_evmcs_version)
>> evmcs_ver = kvm_x86_ops.nested_get_evmcs_version(vcpu);
>>
>> - /* Skip NESTED_FEATURES if eVMCS is not supported */
>> - if (!evmcs_ver)
>> - --nent;
>> + if (evmcs_ver) {
>> + /* EVMCS is enabled, add the required EVMCS CPUID leafs */
>> + memcpy(&cpuid_entries[nent], &evmcs_cpuid_entries,
>> + sizeof(evmcs_cpuid_entries));
>> + nent += ARRAY_SIZE(evmcs_cpuid_entries);
>> + }
>>
>> if (cpuid->nent < nent)
>> return -E2BIG;
>> @@ -1821,7 +1839,7 @@ int kvm_vcpu_ioctl_get_hv_cpuid(struct kvm_vcpu *vcpu, struct kvm_cpuid2 *cpuid,
>> case HYPERV_CPUID_VENDOR_AND_MAX_FUNCTIONS:
>> memcpy(signature, "Linux KVM Hv", 12);
>>
>> - ent->eax = HYPERV_CPUID_NESTED_FEATURES;
>> + ent->eax = cpuid_entries[nent - 1].function;
>> ent->ebx = signature[0];
>> ent->ecx = signature[1];
>> ent->edx = signature[2];
>> --
>> 2.24.1
>>
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Properly suspend/resume reenlightenment notifications
From: Tianyu Lan @ 2020-05-13 13:35 UTC (permalink / raw)
To: Vitaly Kuznetsov, linux-hyperv
Cc: Wei Liu, x86, linux-kernel, kvm, Michael Kelley, Dexuan Cui,
Tianyu Lan
In-Reply-To: <20200512160153.134467-1-vkuznets@redhat.com>
On 5/13/2020 12:01 AM, Vitaly Kuznetsov wrote:
> Errors during hibernation with reenlightenment notifications enabled were
> reported:
>
> [ 51.730435] PM: hibernation entry
> [ 51.737435] PM: Syncing filesystems ...
> ...
> [ 54.102216] Disabling non-boot CPUs ...
> [ 54.106633] smpboot: CPU 1 is now offline
> [ 54.110006] unchecked MSR access error: WRMSR to 0x40000106 (tried to
> write 0x47c72780000100ee) at rIP: 0xffffffff90062f24
> native_write_msr+0x4/0x20)
> [ 54.110006] Call Trace:
> [ 54.110006] hv_cpu_die+0xd9/0xf0
> ...
>
> Normally, hv_cpu_die() just reassigns reenlightenment notifications to some
> other CPU when the CPU receiving them goes offline. Upon hibernation, there
> is no other CPU which is still online so cpumask_any_but(cpu_online_mask)
> returns >= nr_cpu_ids and using it as hv_vp_index index is incorrect.
> Disable the feature when cpumask_any_but() fails.
>
> Also, as we now disable reenlightenment notifications upon hibernation we
> need to restore them on resume. Check if hv_reenlightenment_cb was
> previously set and restore from hv_resume().
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
> arch/x86/hyperv/hv_init.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
> index fd51bac11b46..acf76b466db6 100644
> --- a/arch/x86/hyperv/hv_init.c
> +++ b/arch/x86/hyperv/hv_init.c
> @@ -226,10 +226,18 @@ static int hv_cpu_die(unsigned int cpu)
>
> rdmsrl(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
> if (re_ctrl.target_vp == hv_vp_index[cpu]) {
> - /* Reassign to some other online CPU */
> + /*
> + * Reassign reenlightenment notifications to some other online
> + * CPU or just disable the feature if there are no online CPUs
> + * left (happens on hibernation).
> + */
> new_cpu = cpumask_any_but(cpu_online_mask, cpu);
>
> - re_ctrl.target_vp = hv_vp_index[new_cpu];
> + if (new_cpu < nr_cpu_ids)
> + re_ctrl.target_vp = hv_vp_index[new_cpu];
> + else
> + re_ctrl.enabled = 0;
> +
> wrmsrl(HV_X64_MSR_REENLIGHTENMENT_CONTROL, *((u64 *)&re_ctrl));
> }
>
> @@ -293,6 +301,13 @@ static void hv_resume(void)
>
> hv_hypercall_pg = hv_hypercall_pg_saved;
> hv_hypercall_pg_saved = NULL;
> +
> + /*
> + * Reenlightenment notifications are disabled by hv_cpu_die(0),
> + * reenable them here if hv_reenlightenment_cb was previously set.
> + */
> + if (hv_reenlightenment_cb)
> + set_hv_tscchange_cb(hv_reenlightenment_cb);
> }
>
> /* Note: when the ops are called, only CPU0 is online and IRQs are disabled. */
>
Reviewed-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
^ permalink raw reply
* Re: RE: [PATCH v6 09/10] arm64: efi: Export screen_info
From: Nikhil Mahale @ 2020-05-13 14:26 UTC (permalink / raw)
To: Michael Kelley, Arnd Bergmann
Cc: Will Deacon, Ard Biesheuvel, Catalin Marinas, Mark Rutland,
Marc Zyngier, Linux ARM, gregkh, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-efi, linux-arch,
olaf@aepfle.de, Andy Whitcroft, vkuznets, Jason Wang,
marcelo.cerri@canonical.com, KY Srinivasan, Sunil Muthuswamy,
Boqun Feng
In-Reply-To: <MW2PR2101MB1052E413218D295EF24E5E05D7F40@MW2PR2101MB1052.namprd21.prod.outlook.com>
On 3/20/20 3:16 AM, Michael Kelley wrote:
> From: Arnd Bergmann <arnd@arndb.de> Sent: Wednesday, March 18, 2020 2:27 AM
>>
>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@microsoft.com> wrote:
>>> From: Arnd Bergmann <arnd@arndb.de>
>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@microsoft.com> wrote:
>>>>>
>>>>> The Hyper-V frame buffer driver may be built as a module, and
>>>>> it needs access to screen_info. So export screen_info.
>>>>>
>>>>> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
>>>>
>>>> Is there any chance of using a more modern KMS based driver for the screen
>>>> than the old fbdev subsystem? I had hoped to one day completely remove
>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern
>>>> architectures.
>>>>
>>>
>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V
>>> frame buffer device. That driver builds and runs on both ARM64 and x86.
>>>
>>> I'm not knowledgeable about video/graphics drivers, but when you
>>> say "a more modern KMS based driver", are you meaning one based on
>>> DRM & KMS? Does DRM make sense for a "dumb" frame buffer device?
>>> Are there any drivers that would be a good pattern to look at?
>>
>> It used to be a lot harder to write a DRM driver compared to an fbdev
>> driver, but this has changed to the opposite over the years.
>>
>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c
>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the
>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c,
>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c,
>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c.
>>
>
> Thanks for the pointers, especially for the other hypervisors.
>
Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times.
I had configured by email client incorrectly to reply.
screen_info is still useful with a modern KMS-based driver. It exposes
the mode parameters that the GOP driver chose. This information is
needed to implement seamless or glitchless boot, by both ensuring that
the scanout parameters don't change and being able to read back the
scanout image to populate the initial contents of the new surface.
This works today on arches which implement (U)EFI and export
screen_info, including x86 and powerpc, but doesn't work on arm or
arm64. As arm64 systems that implement UEFI with real GOP drivers
become more prevalent, it would be nice to be have these features there
as well.
Thanks,
Nikhil Mahale
> Michael
>
^ permalink raw reply
* Re: [PATCH] x86/hyperv: Properly suspend/resume reenlightenment notifications
From: Wei Liu @ 2020-05-13 15:01 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: linux-hyperv, Wei Liu, x86, linux-kernel, kvm, Michael Kelley,
Dexuan Cui, Tianyu Lan
In-Reply-To: <20200512160153.134467-1-vkuznets@redhat.com>
On Tue, May 12, 2020 at 06:01:53PM +0200, Vitaly Kuznetsov wrote:
> Errors during hibernation with reenlightenment notifications enabled were
> reported:
>
> [ 51.730435] PM: hibernation entry
> [ 51.737435] PM: Syncing filesystems ...
> ...
> [ 54.102216] Disabling non-boot CPUs ...
> [ 54.106633] smpboot: CPU 1 is now offline
> [ 54.110006] unchecked MSR access error: WRMSR to 0x40000106 (tried to
> write 0x47c72780000100ee) at rIP: 0xffffffff90062f24
> native_write_msr+0x4/0x20)
> [ 54.110006] Call Trace:
> [ 54.110006] hv_cpu_die+0xd9/0xf0
> ...
>
> Normally, hv_cpu_die() just reassigns reenlightenment notifications to some
> other CPU when the CPU receiving them goes offline. Upon hibernation, there
> is no other CPU which is still online so cpumask_any_but(cpu_online_mask)
> returns >= nr_cpu_ids and using it as hv_vp_index index is incorrect.
> Disable the feature when cpumask_any_but() fails.
>
> Also, as we now disable reenlightenment notifications upon hibernation we
> need to restore them on resume. Check if hv_reenlightenment_cb was
> previously set and restore from hv_resume().
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Applied to hyperv-fixes.
Thank you all.
Wei.
^ permalink raw reply
* [PATCH AUTOSEL 5.6 29/62] hv_netvsc: Fix netvsc_start_xmit's return type
From: Sasha Levin @ 2020-05-14 18:51 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Nathan Chancellor, Haiyang Zhang, David S . Miller, Sasha Levin,
linux-hyperv, netdev, clang-built-linux
In-Reply-To: <20200514185147.19716-1-sashal@kernel.org>
From: Nathan Chancellor <natechancellor@gmail.com>
[ Upstream commit 7fdc66debebc6a7170a37c8c9b0d9585a9788fb4 ]
netvsc_start_xmit is used as a callback function for the ndo_start_xmit
function pointer. ndo_start_xmit's return type is netdev_tx_t but
netvsc_start_xmit's return type is int.
This causes a failure with Control Flow Integrity (CFI), which requires
function pointer prototypes and callback function definitions to match
exactly. When CFI is in enforcing, the kernel panics. When booting a
CFI kernel with WSL 2, the VM is immediately terminated because of this.
The splat when CONFIG_CFI_PERMISSIVE is used:
[ 5.916765] CFI failure (target: netvsc_start_xmit+0x0/0x10):
[ 5.916771] WARNING: CPU: 8 PID: 0 at kernel/cfi.c:29 __cfi_check_fail+0x2e/0x40
[ 5.916772] Modules linked in:
[ 5.916774] CPU: 8 PID: 0 Comm: swapper/8 Not tainted 5.7.0-rc3-next-20200424-microsoft-cbl-00001-ged4eb37d2c69-dirty #1
[ 5.916776] RIP: 0010:__cfi_check_fail+0x2e/0x40
[ 5.916777] Code: 48 c7 c7 70 98 63 a9 48 c7 c6 11 db 47 a9 e8 69 55 59 00 85 c0 75 02 5b c3 48 c7 c7 73 c6 43 a9 48 89 de 31 c0 e8 12 2d f0 ff <0f> 0b 5b c3 00 00 cc cc 00 00 cc cc 00 00 cc cc 00 00 85 f6 74 25
[ 5.916778] RSP: 0018:ffffa803c0260b78 EFLAGS: 00010246
[ 5.916779] RAX: 712a1af25779e900 RBX: ffffffffa8cf7950 RCX: ffffffffa962cf08
[ 5.916779] RDX: ffffffffa9c36b60 RSI: 0000000000000082 RDI: ffffffffa9c36b5c
[ 5.916780] RBP: ffff8ffc4779c2c0 R08: 0000000000000001 R09: ffffffffa9c3c300
[ 5.916781] R10: 0000000000000151 R11: ffffffffa9c36b60 R12: ffff8ffe39084000
[ 5.916782] R13: ffffffffa8cf7950 R14: ffffffffa8d12cb0 R15: ffff8ffe39320140
[ 5.916784] FS: 0000000000000000(0000) GS:ffff8ffe3bc00000(0000) knlGS:0000000000000000
[ 5.916785] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.916786] CR2: 00007ffef5749408 CR3: 00000002f4f5e000 CR4: 0000000000340ea0
[ 5.916787] Call Trace:
[ 5.916788] <IRQ>
[ 5.916790] __cfi_check+0x3ab58/0x450e0
[ 5.916793] ? dev_hard_start_xmit+0x11f/0x160
[ 5.916795] ? sch_direct_xmit+0xf2/0x230
[ 5.916796] ? __dev_queue_xmit.llvm.11471227737707190958+0x69d/0x8e0
[ 5.916797] ? neigh_resolve_output+0xdf/0x220
[ 5.916799] ? neigh_connected_output.cfi_jt+0x8/0x8
[ 5.916801] ? ip6_finish_output2+0x398/0x4c0
[ 5.916803] ? nf_nat_ipv6_out+0x10/0xa0
[ 5.916804] ? nf_hook_slow+0x84/0x100
[ 5.916807] ? ip6_input_finish+0x8/0x8
[ 5.916807] ? ip6_output+0x6f/0x110
[ 5.916808] ? __ip6_local_out.cfi_jt+0x8/0x8
[ 5.916810] ? mld_sendpack+0x28e/0x330
[ 5.916811] ? ip_rt_bug+0x8/0x8
[ 5.916813] ? mld_ifc_timer_expire+0x2db/0x400
[ 5.916814] ? neigh_proxy_process+0x8/0x8
[ 5.916816] ? call_timer_fn+0x3d/0xd0
[ 5.916817] ? __run_timers+0x2a9/0x300
[ 5.916819] ? rcu_core_si+0x8/0x8
[ 5.916820] ? run_timer_softirq+0x14/0x30
[ 5.916821] ? __do_softirq+0x154/0x262
[ 5.916822] ? native_x2apic_icr_write+0x8/0x8
[ 5.916824] ? irq_exit+0xba/0xc0
[ 5.916825] ? hv_stimer0_vector_handler+0x99/0xe0
[ 5.916826] ? hv_stimer0_callback_vector+0xf/0x20
[ 5.916826] </IRQ>
[ 5.916828] ? hv_stimer_global_cleanup.cfi_jt+0x8/0x8
[ 5.916829] ? raw_setsockopt+0x8/0x8
[ 5.916830] ? default_idle+0xe/0x10
[ 5.916832] ? do_idle.llvm.10446269078108580492+0xb7/0x130
[ 5.916833] ? raw_setsockopt+0x8/0x8
[ 5.916833] ? cpu_startup_entry+0x15/0x20
[ 5.916835] ? cpu_hotplug_enable.cfi_jt+0x8/0x8
[ 5.916836] ? start_secondary+0x188/0x190
[ 5.916837] ? secondary_startup_64+0xa5/0xb0
[ 5.916838] ---[ end trace f2683fa869597ba5 ]---
Avoid this by using the right return type for netvsc_start_xmit.
Fixes: fceaf24a943d8 ("Staging: hv: add the Hyper-V virtual network driver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1009
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/hyperv/netvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 2c0a24c606fc7..28a5d46ad5266 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -710,7 +710,8 @@ static int netvsc_xmit(struct sk_buff *skb, struct net_device *net, bool xdp_tx)
goto drop;
}
-static int netvsc_start_xmit(struct sk_buff *skb, struct net_device *ndev)
+static netdev_tx_t netvsc_start_xmit(struct sk_buff *skb,
+ struct net_device *ndev)
{
return netvsc_xmit(skb, ndev, false);
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v6 09/10] arm64: efi: Export screen_info
From: Nikhil Mahale @ 2020-05-18 4:25 UTC (permalink / raw)
To: Michael Kelley, Arnd Bergmann
Cc: Will Deacon, Ard Biesheuvel, Catalin Marinas, Mark Rutland,
Marc Zyngier, Linux ARM, gregkh, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, linux-efi, linux-arch,
olaf@aepfle.de, Andy Whitcroft, vkuznets, Jason Wang,
marcelo.cerri@canonical.com, KY Srinivasan, Sunil Muthuswamy,
Boqun Feng
In-Reply-To: <f2b63853-24ae-d6b7-cd43-5792c0d4d31b@nvidia.com>
On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> On 3/20/20 3:16 AM, Michael Kelley wrote:
>> From: Arnd Bergmann <arnd@arndb.de> Sent: Wednesday, March 18, 2020 2:27 AM
>>>
>>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@microsoft.com> wrote:
>>>> From: Arnd Bergmann <arnd@arndb.de>
>>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@microsoft.com> wrote:
>>>>>>
>>>>>> The Hyper-V frame buffer driver may be built as a module, and
>>>>>> it needs access to screen_info. So export screen_info.
>>>>>>
>>>>>> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
>>>>>
>>>>> Is there any chance of using a more modern KMS based driver for the screen
>>>>> than the old fbdev subsystem? I had hoped to one day completely remove
>>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern
>>>>> architectures.
>>>>>
>>>>
>>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V
>>>> frame buffer device. That driver builds and runs on both ARM64 and x86.
>>>>
>>>> I'm not knowledgeable about video/graphics drivers, but when you
>>>> say "a more modern KMS based driver", are you meaning one based on
>>>> DRM & KMS? Does DRM make sense for a "dumb" frame buffer device?
>>>> Are there any drivers that would be a good pattern to look at?
>>>
>>> It used to be a lot harder to write a DRM driver compared to an fbdev
>>> driver, but this has changed to the opposite over the years.
>>>
>>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c
>>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the
>>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c,
>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c,
>>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c.
>>>
>>
>> Thanks for the pointers, especially for the other hypervisors.
>>
> Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times.
> I had configured by email client incorrectly to reply.
>
> screen_info is still useful with a modern KMS-based driver. It exposes
> the mode parameters that the GOP driver chose. This information is
> needed to implement seamless or glitchless boot, by both ensuring that
> the scanout parameters don't change and being able to read back the
> scanout image to populate the initial contents of the new surface.
>
> This works today on arches which implement (U)EFI and export
> screen_info, including x86 and powerpc, but doesn't work on arm or
> arm64. As arm64 systems that implement UEFI with real GOP drivers
> become more prevalent, it would be nice to be have these features there
> as well.
In addition to this, even if a driver doesn't implement a framebuffer
console, or if it does but has an option to disable it, the driver still
needs to know whether the EFI console is using resources on the GPU so
it can avoid clobbering them. For example screen_info provides information
like offset and size of EFI console, using this information driver can
reserve memory used by console and prevent corruption on it.
I think arm64 should export screen_info.
> Thanks,
> Nikhil Mahale
>
>> Michael
>>
^ permalink raw reply
* Re: [PATCH v6 09/10] arm64: efi: Export screen_info
From: Ard Biesheuvel @ 2020-05-18 12:51 UTC (permalink / raw)
To: Nikhil Mahale
Cc: Michael Kelley, Arnd Bergmann, Will Deacon, Catalin Marinas,
Mark Rutland, Marc Zyngier, Linux ARM, gregkh,
linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-efi, linux-arch, olaf@aepfle.de, Andy Whitcroft, vkuznets,
Jason Wang, marcelo.cerri@canonical.com, KY Srinivasan,
Sunil Muthuswamy, Boqun Feng
In-Reply-To: <4202ea20-6e51-31d3-44b1-3861798a8158@nvidia.com>
On Mon, 18 May 2020 at 06:25, Nikhil Mahale <nmahale@nvidia.com> wrote:
>
> On 5/13/20 7:56 PM, Nikhil Mahale wrote:
> > On 3/20/20 3:16 AM, Michael Kelley wrote:
> >> From: Arnd Bergmann <arnd@arndb.de> Sent: Wednesday, March 18, 2020 2:27 AM
> >>>
> >>> On Wed, Mar 18, 2020 at 1:18 AM Michael Kelley <mikelley@microsoft.com> wrote:
> >>>> From: Arnd Bergmann <arnd@arndb.de>
> >>>>> On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@microsoft.com> wrote:
> >>>>>>
> >>>>>> The Hyper-V frame buffer driver may be built as a module, and
> >>>>>> it needs access to screen_info. So export screen_info.
> >>>>>>
> >>>>>> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
> >>>>>
> >>>>> Is there any chance of using a more modern KMS based driver for the screen
> >>>>> than the old fbdev subsystem? I had hoped to one day completely remove
> >>>>> support for the old CONFIG_VIDEO_FBDEV and screen_info from modern
> >>>>> architectures.
> >>>>>
> >>>>
> >>>> The current hyperv_fb.c driver is all we have today for the synthetic Hyper-V
> >>>> frame buffer device. That driver builds and runs on both ARM64 and x86.
> >>>>
> >>>> I'm not knowledgeable about video/graphics drivers, but when you
> >>>> say "a more modern KMS based driver", are you meaning one based on
> >>>> DRM & KMS? Does DRM make sense for a "dumb" frame buffer device?
> >>>> Are there any drivers that would be a good pattern to look at?
> >>>
> >>> It used to be a lot harder to write a DRM driver compared to an fbdev
> >>> driver, but this has changed to the opposite over the years.
> >>>
> >>> A fairly minimal example would be drivers/gpu/drm/pl111/pl111_drv.c
> >>> or anything in drivers/gpu/drm/tiny/, but you may want to look at the
> >>> other hypervisor platforms first, i.e drivers/gpu/drm/virtio/virtgpu_drv.c,
> >>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c, drivers/gpu/drm/xen/xen_drm_front.c,
> >>> drivers/gpu/drm/qxl/qxl_drv.c, and drivers/gpu/drm/bochs/bochs_drv.c.
> >>>
> >>
> >> Thanks for the pointers, especially for the other hypervisors.
> >>
> > Sorry if anybody in 'to' or 'cc' is receiving this reply multiple times.
> > I had configured by email client incorrectly to reply.
> >
> > screen_info is still useful with a modern KMS-based driver. It exposes
> > the mode parameters that the GOP driver chose. This information is
> > needed to implement seamless or glitchless boot, by both ensuring that
> > the scanout parameters don't change and being able to read back the
> > scanout image to populate the initial contents of the new surface.
> >
> > This works today on arches which implement (U)EFI and export
> > screen_info, including x86 and powerpc, but doesn't work on arm or
> > arm64. As arm64 systems that implement UEFI with real GOP drivers
> > become more prevalent, it would be nice to be have these features there
> > as well.
>
> In addition to this, even if a driver doesn't implement a framebuffer
> console, or if it does but has an option to disable it, the driver still
> needs to know whether the EFI console is using resources on the GPU so
> it can avoid clobbering them. For example screen_info provides information
> like offset and size of EFI console, using this information driver can
> reserve memory used by console and prevent corruption on it.
>
> I think arm64 should export screen_info.
>
If there are reasons why KMS or fbdev drivers may need to access the
information in screen_info, it should be exported. I don't think that
is under debate here.
^ permalink raw reply
* [GIT PULL] Hyper-V fixes for v5.7-rc7
From: Wei Liu @ 2020-05-19 9:57 UTC (permalink / raw)
To: Linus Torvalds
Cc: Wei Liu, kys, sthemmin, haiyangz, Michael Kelley,
Linux on Hyper-V List, Linux Kernel List
Hi Linus
Please pull the following changes since commit f081bbb3fd03f949bcdc5aed95a827d7c65e0f30:
hyper-v: Remove internal types from UAPI header (2020-04-22 21:10:05 +0100)
are available in the Git repository at:
ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git tags/hyperv-fixes-signed
for you to fetch changes up to 38dce4195f0daefb566279fd9fd51e1fbd62ae1b:
x86/hyperv: Properly suspend/resume reenlightenment notifications (2020-05-13 15:02:03 +0000)
----------------------------------------------------------------
hyperv-fixes for 5.7-rc6
- One patch from Vitaly to fix reenlightenment notifications
----------------------------------------------------------------
Vitaly Kuznetsov (1):
x86/hyperv: Properly suspend/resume reenlightenment notifications
arch/x86/hyperv/hv_init.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
^ permalink raw reply
* [RFC PATCH 0/4] DirectX on Linux
From: Sasha Levin @ 2020-05-19 16:32 UTC (permalink / raw)
To: alexander.deucher, chris, ville.syrjala, Hawking.Zhang,
tvrtko.ursulin
Cc: linux-kernel, linux-hyperv, kys, haiyangz, sthemmin, wei.liu,
spronovo, iourit, dri-devel, linux-fbdev, gregkh, Sasha Levin
There is a blog post that goes into more detail about the bigger
picture, and walks through all the required pieces to make this work. It
is available here:
https://devblogs.microsoft.com/directx/directx-heart-linux . The rest of
this cover letter will focus on the Linux Kernel bits.
Overview
========
This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The
driver exposes a paravirtualized GPU to user mode applications running
in a virtual machine on a Windows host. This enables hardware
acceleration in environment such as WSL (Windows Subsystem for Linux)
where the Linux virtual machine is able to share the GPU with the
Windows host.
The projection is accomplished by exposing the WDDM (Windows Display
Driver Model) interface as a set of IOCTL. This allows APIs and user
mode driver written against the WDDM GPU abstraction on Windows to be
ported to run within a Linux environment. This enables the port of the
D3D12 and DirectML APIs as well as their associated user mode driver to
Linux. This also enables third party APIs, such as the popular NVIDIA
Cuda compute API, to be hardware accelerated within a WSL environment.
Only the rendering/compute aspect of the GPU are projected to the
virtual machine, no display functionality is exposed. Further, at this
time there are no presentation integration. So although the D3D12 API
can be use to render graphics offscreen, there is no path (yet) for
pixel to flow from the Linux environment back onto the Windows host
desktop. This GPU stack is effectively side-by-side with the native
Linux graphics stack.
The driver creates the /dev/dxg device, which can be opened by user mode
application and handles their ioctls. The IOCTL interface to the driver
is defined in dxgkmthk.h (Dxgkrnl Graphics Port Driver ioctl
definitions). The interface matches the D3DKMT interface on Windows.
Ioctls are implemented in ioctl.c.
When a VM starts, hyper-v on the host adds virtual GPU devices to the VM
via the hyper-v driver. The host offers several VM bus channels to the
VM: the global channel and one channel per virtual GPU, assigned to the
VM.
The driver registers with the hyper-v driver (hv_driver) for the arrival
of VM bus channels. dxg_probe_device recognizes the vGPU channels and
creates the corresponding objects (dxgadapter for vGPUs and dxgglobal
for the global channel).
The driver uses the hyper-V VM bus interface to communicate with the
host. dxgvmbus.c implements the communication interface.
The global channel has 8GB of IO space assigned by the host. This space
is managed by the host and used to give the guest direct CPU access to
some allocations. Video memory is allocated on the host except in the
case of existing_sysmem allocations. The Windows host allocates memory
for the GPU on behalf of the guest. The Linux guest can access that
memory by mapping GPU virtual address to allocations and then
referencing those GPU virtual address from within GPU command buffers
submitted to the GPU. For allocations which require CPU access, the
allocation is mapped by the host into a location in the 8GB of IO space
reserved in the guest for that purpose. The Windows host uses the nested
CPU page table to ensure that this guest IO space always map to the
correct location for the allocation as it may migrate between dedicated
GPU memory (e.g. VRAM, firmware reserved DDR) and shared system memory
(regular DDR) over its lifetime. The Linux guest maps a user mode CPU
virtual address to an allocation IO space range for direct access by
user mode APIs and drivers.
Implementation of LX_DXLOCK2 ioctl
==================================
We would appreciate your feedback on the implementation of the
LX_DXLOCK2 ioctl.
This ioctl is used to get a CPU address to an allocation, which is
resident in video/system memory on the host. The way it works:
1. The driver sends the Lock message to the host
2. The host allocates space in the VM IO space and maps it to the
allocation memory
3. The host returns the address in IO space for the mapped allocation
4. The driver (in dxg_map_iospace) allocates a user mode virtual address
range using vm_mmap and maps it to the IO space using
io_remap_ofn_range)
5. The VA is returned to the application
Internal objects
================
The following objects are created by the driver (defined in dxgkrnl.h):
- dxgadapter - represents a virtual GPU
- dxgprocess - tracks per process state (handle table of created
objects, list of objects, etc.)
- dxgdevice - a container for other objects (contexts, paging queues,
allocations, GPU synchronization objects)
- dxgcontext - represents thread of GPU execution for packet
scheduling.
- dxghwqueue - represents thread of GPU execution of hardware scheduling
- dxgallocation - represents a GPU accessible allocation
- dxgsyncobject - represents a GPU synchronization object
- dxgresource - collection of dxgalloction objects
- dxgsharedresource, dxgsharedsyncobj - helper objects to share objects
between different dxgdevice objects, which can belong to different
processes
Object handles
==============
All GPU objects, created by the driver, are accessible by a handle
(d3dkmt_handle). Each process has its own handle table, which is
implemented in hmgr.c. For each API visible object, created by the
driver, there is an object, created on the host. For example, the is a
dxgprocess object on the host for each dxgprocess object in the VM, etc.
The object handles have the same value in the host and the VM, which is
done to avoid translation from the guest handles to the host handles.
Signaling CPU events by the host
================================
The WDDM interface provides a way to signal CPU event objects when
execution of a context reached certain point. The way it is implemented:
- application sends an event_fd via ioctl to the driver
- eventfd_ctx_get is used to get a pointer to the file object
(eventfd_ctx)
- the pointer to sent the host via a VM bus message
- when GPU execution reaches a certain point, the host sends a message
to the VM with the event pointer
- signal_guest_event() handles the messages and eventually
eventfd_signal() is called.
Sasha Levin (4):
gpu: dxgkrnl: core code
gpu: dxgkrnl: hook up dxgkrnl
Drivers: hv: vmbus: hook up dxgkrnl
gpu: dxgkrnl: create a MAINTAINERS entry
MAINTAINERS | 7 +
drivers/gpu/Makefile | 2 +-
drivers/gpu/dxgkrnl/Kconfig | 10 +
drivers/gpu/dxgkrnl/Makefile | 12 +
drivers/gpu/dxgkrnl/d3dkmthk.h | 1635 +++++++++
drivers/gpu/dxgkrnl/dxgadapter.c | 1399 ++++++++
drivers/gpu/dxgkrnl/dxgkrnl.h | 913 ++++++
drivers/gpu/dxgkrnl/dxgmodule.c | 692 ++++
drivers/gpu/dxgkrnl/dxgprocess.c | 355 ++
drivers/gpu/dxgkrnl/dxgvmbus.c | 2955 +++++++++++++++++
drivers/gpu/dxgkrnl/dxgvmbus.h | 859 +++++
drivers/gpu/dxgkrnl/hmgr.c | 593 ++++
drivers/gpu/dxgkrnl/hmgr.h | 107 +
drivers/gpu/dxgkrnl/ioctl.c | 5269 ++++++++++++++++++++++++++++++
drivers/gpu/dxgkrnl/misc.c | 280 ++
drivers/gpu/dxgkrnl/misc.h | 288 ++
drivers/video/Kconfig | 2 +
include/linux/hyperv.h | 16 +
18 files changed, 15393 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/dxgkrnl/Kconfig
create mode 100644 drivers/gpu/dxgkrnl/Makefile
create mode 100644 drivers/gpu/dxgkrnl/d3dkmthk.h
create mode 100644 drivers/gpu/dxgkrnl/dxgadapter.c
create mode 100644 drivers/gpu/dxgkrnl/dxgkrnl.h
create mode 100644 drivers/gpu/dxgkrnl/dxgmodule.c
create mode 100644 drivers/gpu/dxgkrnl/dxgprocess.c
create mode 100644 drivers/gpu/dxgkrnl/dxgvmbus.c
create mode 100644 drivers/gpu/dxgkrnl/dxgvmbus.h
create mode 100644 drivers/gpu/dxgkrnl/hmgr.c
create mode 100644 drivers/gpu/dxgkrnl/hmgr.h
create mode 100644 drivers/gpu/dxgkrnl/ioctl.c
create mode 100644 drivers/gpu/dxgkrnl/misc.c
create mode 100644 drivers/gpu/dxgkrnl/misc.h
--
2.25.1
^ 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