Re: [PATCH] x86/hyperv: Fix the detection of E820_TYPE_PRAM in a Gen2 VM

On Mon, Sep 18, 2023 at 10:36:47PM -0700, Saurabh Singh Sengar wrote: > On Thu, Aug 10, 2023 at 10:31:37PM -0700, Dexuan Cui wrote: > > A Gen2 VM doesn't support legacy PCI/PCIe, so both raw_pci_ops and > > raw_pci_ext_ops are NULL, and pci_subsys_init() -> pcibios_init() > > doesn't call

Re: [PATCH] hv/hv_kvp_daemon: Some small fixes for handling NM keyfiles

On Fri, Nov 10, 2023 at 02:59:14PM +, Haiyang Zhang wrote: > @Wei Liu Could you please add this to the hv > tree? > Applied to hyperv-fixes. Sorry for the delay. Thanks, Wei.

Re: [PATCH net-next v4] hv_netvsc: Mark VF as slave before exposing it to user-mode

On Fri, 10 Nov 2023 00:43:55 + Long Li wrote: > The code above needs to work with and without netvsc (the possible > master device) present. I don't think that's a reasonable requirement for the kernel code. The auto-bonding already puts the kernel into business of guessing policy, which

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On Fri, Nov 10, 2023 at 02:42:31PM +0100, Jeremi Piotrowski wrote: > On 10/11/2023 13:46, kirill.shute...@linux.intel.com wrote: > > On Fri, Nov 10, 2023 at 01:27:08PM +0100, Jeremi Piotrowski wrote: > >>> Maybe just remove incorrect info and that's it? > >>> > >> > >> I disagree, other users and

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On Fri, Nov 10, 2023 at 04:51:43PM +0100, Jeremi Piotrowski wrote: > What's semi-correct about checking for CC_VENDOR_INTEL and then > printing Intel? I can post a v2 that checks CC_ATTR_GUEST_MEM_ENCRYPT > before printing "TDX". How is it that you're not seeing the conflict: Your TD

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On 10/11/2023 14:17, Borislav Petkov wrote: > On Thu, Nov 09, 2023 at 07:41:33PM +0100, Jeremi Piotrowski wrote: >> tdx_early_init() changes kernel behavior with the assumption that it >> can talk directly to the TD module or change page visibility in >> a certain way, instead of talking to a

[PATCH net,v4, 3/3] hv_netvsc: Mark VF as slave before exposing it to user-mode

From: Long Li When a VF is being exposed form the kernel, it should be marked as "slave" before exposing to the user-mode. The VF is not usable without netvsc running as master. The user-mode should never see a VF without the "slave" flag. This commit moves the code of setting the slave flag to

[PATCH net,v4, 2/3] hv_netvsc: Fix race of register_netdevice_notifier and VF register

If VF NIC is registered earlier, NETDEV_REGISTER event is replayed, but NETDEV_POST_INIT is not. Move register_netdevice_notifier() earlier, so the call back function is set before probing. Cc: sta...@vger.kernel.org Fixes: e04e7a7bbd4b ("hv_netvsc: Fix a deadlock by getting rtnl lock earlier in

[PATCH net,v4, 1/3] hv_netvsc: fix race of netvsc and VF register_netdevice

The rtnl lock also needs to be held before rndis_filter_device_add() which advertises nvsp_2_vsc_capability / sriov bit, and triggers VF NIC offering and registering. If VF NIC finished register_netdev() earlier it may cause name based config failure. To fix this issue, move the call to

[PATCH net,v4, 0/3] hv_netvsc: fix race of netvsc, VF register, and slave bit

There are some races between netvsc probe, set notifier, VF register, and slave bit setting. This patch set fixes them. Haiyang Zhang (2): hv_netvsc: fix race of netvsc and VF register_netdevice hv_netvsc: Fix race of register_netdevice_notifier and VF register Long Li (1): hv_netvsc:

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On 10/11/2023 13:46, kirill.shute...@linux.intel.com wrote: > On Fri, Nov 10, 2023 at 01:27:08PM +0100, Jeremi Piotrowski wrote: >>> Maybe just remove incorrect info and that's it? >>> >> >> I disagree, other users and I find the print very useful to see which coco >> platform the kernel is

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On Thu, Nov 09, 2023 at 07:41:33PM +0100, Jeremi Piotrowski wrote: > tdx_early_init() changes kernel behavior with the assumption that it > can talk directly to the TD module or change page visibility in > a certain way, instead of talking to a paravisor. So that CPUID is > hidden to prevent this.

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On Fri, Nov 10, 2023 at 01:27:08PM +0100, Jeremi Piotrowski wrote: > > Maybe just remove incorrect info and that's it? > > > > I disagree, other users and I find the print very useful to see which coco > platform the kernel is running on and which confidential computing features > the kernel

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On 10/11/2023 13:06, kirill.shute...@linux.intel.com wrote: > On Thu, Nov 09, 2023 at 07:41:33PM +0100, Jeremi Piotrowski wrote: >> It's not disregard, the way the kernel behaves in this case is correct except >> for the error in reporting CPU vendor. Users care about seeing the correct >>

Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

On Thu, Nov 09, 2023 at 07:41:33PM +0100, Jeremi Piotrowski wrote: > It's not disregard, the way the kernel behaves in this case is correct except > for the error in reporting CPU vendor. Users care about seeing the correct > information in dmesg. I think it is wrong place to advertise CoCo