=
> @@ -436,6 +433,9 @@ static bool hv_synic_event_pending(void)
> return pending;
> }
>
> +/*
> + * hv_synic_cleanup - Cleanup routine for hv_synic_init().
> + */
> int hv_synic_cleanup(unsigned int cpu)
> {
> struct vmbus_channel *channel, *sc;
>
> base-commit: 831bcbcead6668ebf20b64fdb27518f1362ace3a
> --
> 2.34.1
>
Reviewed-by: Michael Kelley
All looks good and behaves as expected.
On the Gen 1 VM, the PIT is used briefly at boot (takes ~35 interrupts)
before the Hyper-V synthetic timer takes over and the PIT is shutdown.
As expected, no further interrupts are received from the PIT.
On a Gen 2 VM, apic_needs_pit() returns true because
X86_FEATURE_ARAT isn't present. The PIT doesn't exist in a
Gen 2 VM, but the code paths handle this situation with no
problems, just as before the patch series.
For the two-patch series on Hyper-V,
Tested-by: Michael Kelley
From: Thomas Gleixner Sent: Thursday, August 1, 2024 7:21
AM
>
> On Tue, Feb 07 2023 at 09:14, lirongq...@baidu.com wrote:
> > @@ -117,11 +110,6 @@ static int pit_shutdown(struct clock_event_device *evt)
> >
> > outb_p(0x30, PIT_MODE);
> >
> > - if (i8253_clear_counter_on_shutdown) {
> >
From: Saurabh Singh Sengar Sent: Sunday, July 28,
2024 2:18 AM
>
> On Sun, Jul 28, 2024 at 04:32:23AM +, Michael Kelley wrote:
> > From: Saurabh Sengar Sent: Wednesday, July 24,
> 2024 10:26 PM
> > >
> > > Currently on a very large system with 1780 CPUs,
From: Saurabh Sengar Sent: Wednesday, July 24,
2024 10:26 PM
>
> Currently on a very large system with 1780 CPUs, hv_acpi_init takes
> around 3 seconds to complete for all the CPUs. This is because of
> sequential synic initialization for each CPU.
>
> Defer these tasks so that each CPU
python. Also fix the permissions to be 755 so that is executable by
> default, which matches other similar scripts in `tools/hv`.
>
> The script is also tested and verified that is compatible with
> python3.
>
> [1] https://www.python.org/doc/sunset-python-2/
>
> Signed-off-by:
From: Anthony Nandaa Sent: Monday, July 1, 2024 1:36 AM
>
> This patch updates the shebang in the lsvmbus tool to use python3
> instead of python. The change is necessary because Python 2 has
> reached its end of life as of January 1, 2020, and is no longer
> maintained[1]. Many modern systems
From: Haoxiang Li Sent: Sunday, June 30, 2024 7:31 PM
>
> child_device_obj->device cannot perform DMA properly if dma_set_mask()
> returns non-zero. Add check for dma_set_mask() and return the error if it
> fails. child_device_obj->device is not initialized here, so use kfree() to
> free
From: Boqun Feng Sent: Monday, June 24, 2024 10:55 AM
>
> Hi Michael,
>
> On Mon, Jun 03, 2024 at 10:09:39PM -0700, mhkelle...@gmail.com wrote:
> [...]
> > diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> > index bf35bb40c55e..571b2955b38e 100644
> > ---
else if ((where >= PCI_INTERRUPT_LINE && where + size <=
> PCI_INTERRUPT_PIN) ||
> +(where >= PCI_INTERRUPT_PIN && where + size <= PCI_MIN_GNT))
> {
> /*
> * Interrupt Line and Interrupt PIN are hard-wired to zero
>* because this front-end only supports message-signaled
> --
> 2.43.0
>
Reviewed-by: Michael Kelley
a VM. This change should cause no perceivable
> performance difference.
>
> Cc: sta...@vger.kernel.org # 6.6+
> Reviewed-by: Roman Kisel
> Signed-off-by: Dexuan Cui
> ---
>
> Changes in v2:
> Improved the comments in ms_hyperv_init_platform() [Michael Kelley]
>
From: Wei Liu Sent: Thursday, June 20, 2024 6:48 PM
>
> The intent of the code snippet is to always return 0 for both fields.
> The check is wrong though. Fix that.
>
> This is discovered by this call in VFIO:
>
> pci_read_config_byte(vdev->pdev, PCI_INTERRUPT_PIN, );
>
> The old code
From: Dexuan Cui Sent: Tuesday, June 18, 2024 5:25 PM
>
> In a TDX VM without paravisor, currently the default timer is the Hyper-V
> timer, which depends on the slow VM Reference Counter MSR: the Hyper-V TSC
> page is not enabled in such a VM because the VM uses Invariant TSC as a
> better
B on ARM64, define the minimal
> queue size as a macro separately from the PAGE_SIZE, which we always
> assumed it to be 4KB before supporting ARM64.
>
> Also, add MANA specific macros and update code related to size
> alignment, DMA region calculations, etc.
>
> Signed-off-by:
From: LKML haiyangz On Behalf Of Haiyang Zhang Sent:
Friday, June 14, 2024 11:36 AM
>
> As defined by the MANA Hardware spec, the queue size for DMA is 4KB
> minimal, and power of 2. And, the HWC queue size has to be exactly
> 4KB.
>
> To support page sizes other than 4KB on ARM64, define the
From: Haiyang Zhang Sent: Tuesday, June 11, 2024 10:44
AM
>
> > -Original Message-
> > From: Michael Kelley <mailto:mhkli...@outlook.com>
> > Sent: Tuesday, June 11, 2024 12:35 PM
> > To: Haiyang Zhang <mailto:haiya...@microsoft.com>;
From: LKML haiyangz On Behalf Of Haiyang Zhang Sent:
Monday, June 10, 2024 2:23 PM
>
> As defined by the MANA Hardware spec, the queue size for DMA is 4KB
> minimal, and power of 2.
You say the hardware requires 4K "minimal". But the definitions in this
patch hardcode to 4K, as if that's the
From: Thomas Gleixner Sent: Thursday, June 6, 2024 2:34 AM
>
> On Thu, Jun 06 2024 at 03:14, Michael Kelley wrote:
> > From: Thomas Gleixner Sent: Wednesday, June 5, 2024
> > 7:20 AM
> >>
> >> On Wed, Jun 05 2024 at 13:45, Michael Kelley wrote:
> >
From: Thomas Gleixner Sent: Wednesday, June 5, 2024 7:20 AM
>
> On Wed, Jun 05 2024 at 13:45, Michael Kelley wrote:
> > From: Thomas Gleixner Sent: Wednesday, June 5, 2024
> > 6:20 AM
> >
> > In /proc/interrupts, the double-counting isn't a problem, and is
>
From: Thomas Gleixner Sent: Wednesday, June 5, 2024 6:20 AM
>
> On Tue, Jun 04 2024 at 23:03, Michael Kelley wrote:
> > From: Thomas Gleixner Sent: Tuesday, June 4, 2024
> > 11:14 AM
> >>1) Move the inner workings of handle_percpu_irq() out into
> >>
From: Thomas Gleixner Sent: Tuesday, June 4, 2024 11:14 AM
>
> Michael!
>
> On Mon, Jun 03 2024 at 22:09, mhkelle...@gmail.com wrote:
> > Hyper-V VMBus devices generate interrupts that are multiplexed
> > onto a single per-CPU architectural interrupt. The top-level VMBus
> > driver ISR
.pl script"
> drivers/hv/hv.c | 37
> drivers/hv/hv_balloon.c | 98 +++++++--
> 2 files changed, 53 insertions(+), 82 deletions(-)
Reviewed-by: Michael Kelley
From: Aditya Nagesh Sent: Wednesday, May 29,
2024 9:05 AM
>
> Fix issues reported by checkpatch.pl script in hv.c and
> balloon.c
> - Remove unnecessary parentheses
> - Remove extra newlines
> - Remove extra spaces
> - Add spaces between comparison operators
> - Remove comparison with NULL
From: Dexuan Cui Sent: Friday, May 24, 2024 1:46 AM
>
> > From: Dave Hansen
> > Sent: Thursday, May 23, 2024 7:26 AM
> > [...]
> > On 5/22/24 19:24, Dexuan Cui wrote:
> > ...
> > > +static bool noinstr intel_cc_platform_td_l2(enum cc_attr attr)
> > > +{
> > > + switch (attr) {
> > > + case
From: Roman Kisel Sent: Tuesday, May 14, 2024 3:44
PM
>
> The hyperv-pci driver uses ACPI for MSI IRQ domain configuration
> on arm64 thereby it won't be able to do that in the VTL mode where
> only DeviceTree can be used.
That sentence seems a bit weird. How about:
The hyperv-pci driver
From: Roman Kisel Sent: Tuesday, May 14, 2024 3:44
PM
>
> The vmbus driver uses ACPI for interrupt assignment on
> arm64 hence it won't function in the VTL mode where only
> DeviceTree can be used.
>
> Update the vmbus driver to discover interrupt configuration
> via DeviceTree.
>
>
From: Roman Kisel Sent: Tuesday, May 14, 2024 3:44
PM
>
> To run in the VTL mode, Hyper-V drivers have to know what
> VTL the system boots in, and the arm64/hyperv code does not
> update the variable that stores the value.
>
> Update the variable to enable the Hyper-V drivers to boot
> in the
From: Roman Kisel Sent: Tuesday, May 14, 2024 3:44
PM
>
> To run in the VTL mode, Hyper-V drivers have to know what
> VTL the system boots in, and the arm64/hyperv code does not
> have the means to compute that.
>
> Refactor the code to hoist the function that detects VTL,
> make it
From: Roman Kisel Sent: Tuesday, May 14, 2024 3:44
PM
>
> Kconfig dependencies for arm64 guests on Hyper-V require that be ACPI enabled,
> and limit VTL mode to x86/x64. To enable VTL mode on arm64 as well, update the
> dependencies. Since VTL mode requires DeviceTree instead of ACPI, don't
>
From: David Hildenbrand Sent: Thursday, May 2, 2024 12:17 AM
>
> On 01.05.24 17:14, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > The Hyper-V balloon driver supports hot-add of memory in addition
> > to ballooning. Current code hot-adds in fixed siz
uld
be motivated to work on it.
Michael Kelley
From: Michael Kelley Sent: Friday, April 26, 2024 9:36 AM
> > > @@ -505,8 +505,9 @@ enum hv_dm_state {
> > >
> > > static __u8 recv_buffer[HV_HYP_PAGE_SIZE];
> > > static __u8 balloon_up_send_buffer[HV_HYP_PAGE_SIZE];
> > > +static unsi
o algorithms are changed except
> > to initialize the new global variable and to calculate the
> > alignment value to pass to Hyper-V. Testing with memblock
> > sizes of 256 Mbytes and 2 Gbytes shows correct operation.
> >
> > Signed-off-by: Michael Kelley
> &g
previous HA_CHUNK constant. No algorithms are changed except
> to initialize the new global variable and to calculate the
> alignment value to pass to Hyper-V. Testing with memblock
> sizes of 256 Mbytes and 2 Gbytes shows correct operation.
>
> Signed-off-by: Michael Kelley
A
From: Michael Schierl Sent: Friday, April 19, 2024 1:47 PM
> Am 19.04.2024 um 18:36 schrieb Michael Kelley:
>
> >> I still want to understand why 32-bit Linux is taking an oops during
> >> boot while 64-bit Linux does not.
> >
> > The difference is i
From: Michael Kelley Sent: Wednesday, April 17, 2024
3:35 PM
>
> From: Michael Schierl Sent: Wednesday, April 17, 2024 2:08
> PM
> >
> > > Don't let the type 10 distract you. It is entirely possible that the
> > > byte corresponding to type == 10 is already p
f-by: Jean Delvare
> Reported-by: Michael Schierl
> Link:
> https://lore.kernel.org/linux-kernel/Zh2K3-HLXOesT_vZ@liuwe-devbox-debian-v2/T/
> Tested-by: Michael Schierl
> ---
> Changes since v1:
> * Also log the offset of the corrupted entry (suggested by Michael Kelley)
&
e about how to debug that.
FWIW, in comparing the Azure VM with my local VM, it looks like
the corrupted entry is the first type 4 entry describing a CPU.
Michael Kelley
>
> > You should also check the memory map (as displayed early at boot, so
> > near the top of dmesg)
From: Jean Delvare Sent: Wednesday, April 17, 2024 10:34 AM
>
> Hi Michael,
>
> On Wed, 2024-04-17 at 15:43 +0000, Michael Kelley wrote:
> > From: Jean Delvare Sent: Wednesday, April 17, 2024 8:34
> > AM
> > >
> > > If a DMI table entry is shorter tha
From: Jean DELVARE Sent: Wednesday, April 17, 2024 2:44 AM
>
> Hi Michael and Michael,
>
> Thanks to both of you for all the data and early analysis.
>
> On Tue, 2024-04-16 at 23:20 +0000, Michael Kelley wrote:
> > Thanks for the information. I now have a repro of
From: Jean Delvare Sent: Wednesday, April 17, 2024 8:34 AM
>
> If a DMI table entry is shorter than 4 bytes, it is invalid. Due to
> how DMI table parsing works, it is impossible to safely recover from
> such an error, so we have to stop decoding the table.
>
> Signed-off-by: Jean Delvare
>
From: Michael Schierl Sent: Tuesday, April 16, 2024 2:24 PM
>
> Am 16.04.2024 um 01:31 schrieb Michael Kelley:
>
> > Can you give me details of the Hyper-V VM configuration? Maybe
> > a screenshot of the Hyper-V Manager "Settings" for the VM would
> >
Manager "Settings" for the VM would
be a good starting point, though some of the details are on
sub-panels in the UI. I'm guessing your 32-bit Linux VM is
a Generation 1 VM. FWIW, my example was a Generation 2 VM.
When you ran a 64-bit Linux and did not have the problem, was
that with exactly the same Hyper-V VM configuration, or a different
config? Perhaps something about the VM configuration tickles a
bug in Hyper-V and it builds a faulty DMI entry, so I'm focusing on
that aspect. If we can figure out what aspect of the VM config
causes the bad DMI entry to be generated, there might be an
easy work-around for you in tweaking the VM config.
Michael Kelley
ndle 0x0005, DMI type 11, 5 bytes
Handle 0x0006, DMI type 16, 23 bytes
Handle 0x0007, DMI type 17, 92 bytes
Handle 0x0008, DMI type 19, 31 bytes
Handle 0x0009, DMI type 20, 35 bytes
Handle 0x000A, DMI type 17, 92 bytes
Handle 0x000B, DMI type 19, 31 bytes
Handle 0x000C, DMI type 20, 35 bytes
Handle
From: Allen Pais Sent: Wednesday, April 3, 2024
9:56 AM
>
> The only generic interface to execute asynchronously in the BH context is
> tasklet; however, it's marked deprecated and has some design flaws. To
> replace tasklets, BH workqueue support was recently added. A BH workqueue
> behaves
From: Jason A. Donenfeld Sent: Monday, March 18, 2024 2:03 PM
>
> On Mon, Mar 18, 2024 at 08:54:08AM -0700, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > A Hyper-V host provides its guest VMs with entropy in a custom ACPI
> > table named "OEM0&q
From: Kuppuswamy Sathyanarayanan
>
> >>> @@ -886,6 +901,8 @@ int vmbus_teardown_gpadl(struct vmbus_channel
> >>> *channel, struct vmbus_gpadl *gpad
> >>> if (ret)
> >>> pr_warn("Fail to set mem host visibility in GPADL teardown
> >>> %d.\n", ret);
> >>
> >> Will this be called only
From: Jason A. Donenfeld
>
> Hi Michael,
>
> On Thu, Mar 14, 2024 at 12:30:06AM +0000, Michael Kelley wrote:
> > OK, fair enough. But just to double-check: When this is called,
> > the EFI RNG protocol has already invoked add_bootloader_randomness(),
> >
From: Jason A. Donenfeld Sent: Wednesday, March 13, 2024 4:33
PM
>
> Hi Michael,
>
> On Thu, Mar 07, 2024 at 10:48:20AM -0800, mhkelle...@gmail.com wrote:
> > + /*
> > +* Seed the Linux random number generator with entropy provided by
> > +* the Hyper-V host in ACPI table OEM0. It
From: Long Li Sent: Tuesday, March 12, 2024 9:51 PM
>
> > +void __init ms_hyperv_late_init(void)
> > +{
> > + struct acpi_table_header *header;
> > + acpi_status status;
> > + u8 *randomdata;
> > + u32 length, i;
> > +
> > + /*
> > +* Seed the Linux random
rs of vmbus_establish_gpadl() and
> > vmbus_teardown_gpadl() don't return decrypted/shared pages to
> > allocators, add a field in struct vmbus_gpadl to keep track of the
> > decryption status of the buffers. This will allow the callers to
> > know if they should free o
move the printing code to hv_common_init() so it is not duplicated.
>
> Signed-off-by: Nuno Das Neves
> Acked-by: Wei Liu
Reviewed-by: Michael Kelley
> ---
> Changes since v1:
> - Amend commit message
> - Address minor style issues
> - Remove unneeded EXPORT_SYMBOL_GP
From: Edgecombe, Rick P Sent: Thursday, March 7,
2024 11:12 AM
>
> On Thu, 2024-03-07 at 17:11 +, Michael Kelley wrote:
> > Using your patches plus the changes in my comments, I've
> > done most of the testing described above. The normal
> > paths work, and when I h
From: Nuno Das Neves Sent: Thursday, March
7, 2024 11:49 AM
>
> On 3/7/2024 11:22 AM, Michael Kelley wrote:
> > From: Nuno Das Neves Sent: Wednesday,
> > March 6, 2024 4:48 PM
> >>
> >> Introduce x86_64 and arm64 functions for getting the hypervisor
From: Nuno Das Neves Sent: Wednesday, March
6, 2024 4:48 PM
>
> Introduce x86_64 and arm64 functions for getting the hypervisor version
> information and storing it in a structure for simpler parsing.
>
> Use the new function to get and parse the version at boot time. While at
> it, print the
From: Michael Kelley Sent: Friday, March 1, 2024 11:00 AM
> >
> > IMPORTANT NOTE:
> > I don't have a setup to test tdx hyperv changes. These changes are compile
> > tested only. Previously Michael Kelley suggested some folks at MS might be
> > able to help wi
From: wei@kernel.org @ 2024-03-04 6:57 UTC
>
> > +void __init ms_hyperv_late_init(void)
> > +{
> > + struct acpi_table_header *header;
> > + acpi_status status;
> > + u8 *randomdata;
> > + u32 length, i;
> > +
> > + /*
> > +* Seed the Linux random number generator with entropy
From: Edgecombe, Rick P Sent: Friday, March 1,
2024 11:13 AM
> >
> > > On TDX it is possible for the untrusted host to cause
> >
> > I'd argue that this is for CoCo VMs in general, not just TDX. I don't know
> > all the failure modes for SEV-SNP, but the code paths you are changing
> > are run
From: Rick Edgecombe Sent: Wednesday, February 21,
2024 6:10 PM
>
Historically, the preferred Subject prefix for changes to connection.c has
been "Drivers: hv: vmbus:", not just "hv:". Sometimes that preference
isn't followed, but most of the time it is.
> On TDX it is possible for the
From: Rick Edgecombe Sent: Wednesday, February 21,
2024 6:10 PM
>
> On TDX it is possible for the untrusted host to cause
Same comment about TDX vs. CoCo VM.
> set_memory_encrypted() or set_memory_decrypted() to fail such that an
> error is returned and the resulting memory is shared. Callers
From: Rick Edgecombe Sent: Wednesday, February 21,
2024 6:10 PM
>
"Subject:" prefix should be hv_netvsc:
> On TDX it is possible for the untrusted host to cause
Same comment about TDX vs. CoCo VM.
> set_memory_encrypted() or set_memory_decrypted() to fail such that an
> error is returned
From: Rick Edgecombe Sent: Wednesday, February 21,
2024 6:10 PM
>
See comment in Patch 1 about the "Subject" prefix.
> On TDX it is possible for the untrusted host to cause
See comment in Patch 1 about TDX vs. CoCo VM.
> set_memory_encrypted() or set_memory_decrypted() to fail such that an
is to warn in a single place in x86 set_memory()
> code.
>
> This series fixes the cases in the hyperv code.
>
> IMPORTANT NOTE:
> I don't have a setup to test tdx hyperv changes. These changes are compile
> tested only. Previously Michael Kelley suggested some folks
From: Boqun Feng Sent: Tuesday, February 20, 2024 9:29 AM
>
> On Mon, Feb 19, 2024 at 10:30:07PM -0800, Saurabh Singh Sengar wrote:
> > On Mon, Feb 12, 2024 at 10:19:59PM -0800, mhkelle...@gmail.com wrote:
> > > From: Michael Kelley
> > >
> > > The VMBU
From: Saurabh Singh Sengar Sent: Saturday,
February 17, 2024 11:17 PM
> > >
> > > diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
> > > index 0024210..bc3f496 100644
> > > --- a/drivers/hv/Kconfig
> > > +++ b/drivers/hv/Kconfig
> > > @@ -9,6 +9,7 @@ config HYPERV
> > > select PARAVIRT
> >
From: Saurabh Sengar Sent: Friday, February 16,
2024 6:10 AM
> To: k...@microsoft.com; haiya...@microsoft.com; wei@kernel.org;
> de...@microsoft.com; linux-hyperv@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Cc: ssen...@microsoft.com
> Subject: [PATCH] Drivers: hv: Kconfig: select
at's the smallest possible with that page size.
> > It's still 128 Kbytes better than the current code.
> >
> > Cc: # 5.15.x
> > Signed-off-by: Michael Kelley
> > Reviewed-by: Kuppuswamy Sathyanarayanan
>
> > ---
> > Changes in v2:
> > * Use SZ_16K instead
From: Kuppuswamy Sathyanarayanan
>
> On 2/12/24 10:19 PM, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > For a physical PCI device that is passed through to a Hyper-V guest VM,
> > current code specifies the VMBus ring buffer size as 4 pages. Bu
gt; Signed-off-by: Nuno Das Neves
> Reviewed-by: Wei Liu
Overall, this looks good to me. It cleans up the mess I made five
years ago when first separating x86 from ARM64. :-(
See one comment below, but otherwise,
Reviewed-by: Michael Kelley
> ---
> arch/arm64/include/asm/hyperv-t
rove reviewability and to offer the option of
> retaining both hypervisor callbacks.
> * Patch 5 moves set_memory_p() out of an #ifdef CONFIG_X86_64
> so that the code builds correctly for 32-bit, even though it
> is never executed for 32-bit [reported by kernel te
From: Michael Kelley Sent: Friday, January 12, 2024 8:19
AM
>
> From: Markus Elfring Sent: Friday, January 12,
> 2024 12:06 AM
> >
> > …
> > > Eliminate the duplication by making minor tweaks to the logic and
> > > associated comments. Whil
From: Ricardo B. Marliere Sent: Sunday, February 4, 2024
8:38 AM
>
NIT: For consistency, we try to use "Drivers: hv: vmbus:" as the prefix on the
Subject line for patches to vmbus_drv.c.
Otherwise,
Reviewed-by: Michael Kelley
> Now that the driver core can properly handle
v_vtl_wakeup_secondary_cpu(u32 apicid,
> unsigned long start_eip)
> return -EINVAL;
> }
>
> - return hv_vtl_bringup_vcpu(vp_id, start_eip);
> + return hv_vtl_bringup_vcpu(vp_id, cpu, start_eip);
> }
>
> int __init hv_vtl_early_init(void)
> --
> 2.34.1
>
Reviewed-by: Michael Kelley
From: Saurabh Sengar Sent: Thursday, February 1,
2024 10:26 AM
>
> Currently, the secondary vCPUs in Hyper-V VTL context lack support for
> parallel startup. Therefore, relying on the single initial_stack fetched
> from the current task structure suffices for all vCPUs.
>
> However, common
From: Simon Horman @ 2024-01-22 20:49 UTC (permalink / raw)
>
> On Mon, Jan 22, 2024 at 08:20:28AM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > Current code in netvsc_drv_init() incorrectly assumes that PAGE_SIZE
> > is 4 Kbytes, which is
gions = 0;
> x86_platform.legacy.devices.pnpbios = 0;
> +
> + x86_init.hyper.msi_ext_dest_id = hv_vtl_msi_ext_dest_id;
> }
>
> static inline u64 hv_vtl_system_desc_base(struct ldttss_desc *desc)
> --
> 1.8.3.1
>
Reviewed-by: Michael Kelley
From: Souradeep Chakrabarti Sent: Friday,
January 12, 2024 10:31 PM
> On Fri, Jan 12, 2024 at 06:30:44PM +, Haiyang Zhang wrote:
> >
> > > -Original Message-
> > From: Michael Kelley Sent: Friday, January 12, 2024
> > 11:37 AM
> > >
From: Edgecombe, Rick P Sent: Friday, January 12,
2024 9:17 AM
>
> On Fri, 2024-01-12 at 15:07 +, Michael Kelley wrote:
> > The comment is Kirill Shutemov's suggestion based on comments in
> > an earlier version of the patch series. See [1]. The intent is to
> >
From: Souradeep Chakrabarti Sent: Wednesday,
January 10, 2024 10:13 PM
>
> The test topology was used to check the performance between
> cpu_local_spread() and the new approach is :
> Case 1
> IRQ Nodes Cores CPUs
> 0 1 0 0-1
> 1 1 1 2-3
> 2 1 2
From: Markus Elfring Sent: Friday, January 12, 2024
12:06 AM
>
> …
> > Eliminate the duplication by making minor tweaks to the logic and
> > associated comments. While here, simplify the handling of memory
> > allocation errors, and use umin() instead of open coding it.
> …
>
> I got the
From: Edgecombe, Rick P Sent: Thursday, January
11, 2024 5:20 PM
>
> On Fri, 2024-01-05 at 10:30 -0800, mhkelle...@gmail.com wrote:
> > + * It is also used in callbacks for CoCo VM page transitions between
> > private
> > + * and shared because it works when the PRESENT bit is not set in the
From: Edgecombe, Rick P Sent: Thursday, January
11, 2024 4:27 PM
>
> On Fri, 2024-01-05 at 10:30 -0800, mhkelle...@gmail.com wrote:
> > * hv_vtom_set_host_visibility - Set specified memory visible to host.
> > *
> > @@ -521,7 +547,7 @@ static bool hv_vtom_set_host_visibility(unsigned long
From: Dan Carpenter Sent: Wednesday, January 10,
2024 11:05 PM
>
> On Wed, Jan 10, 2024 at 10:17:17PM +, Michael Kelley wrote:
> > From: Dan Carpenter Sent: Wednesday, January
> 10, 2024 10:38 AM
> > >
> > > The second half of the if statement is
From: Dan Carpenter Sent: Wednesday, January 10,
2024 10:38 AM
>
> The second half of the if statement is basically duplicated. It doesn't
> need to be treated as a special case. We could do something like below.
> I deliberately didn't delete the tabs. Also I haven't tested it.
Indeed! I
From: Markus Elfring Sent: Wednesday, January 10, 2024
9:08 AM
>
> > It occurred to me overnight that the existing error handling
> > in create_gpadl_header() is unnecessarily complicated. Here's
> > an approach that I think would fix what you have flagged, and
> > would reduce complexity
From: Markus Elfring Sent: Wednesday, January 10, 2024
2:58 AM
>
> >> The kfree() function was called in two cases by
> >> the create_gpadl_header() function during error handling
> >> even if the passed variable contained a null pointer.
> >> This issue was detected by using the Coccinelle
From: Markus Elfring Sent: Tuesday, December 26, 2023
11:09 AM
>
> The kfree() function was called in two cases by
> the create_gpadl_header() function during error handling
> even if the passed variable contained a null pointer.
> This issue was detected by using the Coccinelle software.
>
>
From: Saurabh Sengar Sent: Friday, January 5,
2024 2:29 AM
>
> The current method for signaling the compatibility of a Hyper-V host
> with MSIs featuring 15-bit APIC IDs relies on a synthetic cpuid leaf.
> However, for higher VTLs, this leaf is not reported, due to the absence
> of an IO-APIC.
> myself.
Agreed. :-) Given the heritage of the patch, I should have clarified
that my question was directed to Souradeep. Regardless, your work
on the cpumask manipulation made everything better and clearer.
>
> On Tue, Jan 09, 2024 at 07:22:38PM +, Michael Kelley wrote:
> >
From: Souradeep Chakrabarti Sent: Tuesday,
January 9, 2024 2:51 AM
>
> From: Yury Norov
>
> Souradeep investigated that the driver performs faster if IRQs are
> spread on CPUs with the following heuristics:
>
> 1. No more than one IRQ per CPU, if possible;
> 2. NUMA locality is the second
From: Kuppuswamy Sathyanarayanan
Sent: Monday, January 8, 2024 10:37 AM
>
> On 1/5/2024 10:30 AM, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > In a CoCo VM, when transitioning memory from encrypted to decrypted, or
> > vice versa, the
From: kirill.shute...@linux.intel.com Sent:
Monday, January 8, 2024 5:08 AM
>
> On Fri, Jan 05, 2024 at 10:30:23AM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > In preparation for temporarily marking pages not present during a
> >
From: Edgecombe, Rick P Sent: Tuesday, November
28, 2023 10:59 AM
>
> On Tue, 2023-11-28 at 18:08 +, Michael Kelley wrote:
> > >
> > > Sort of separately, if those vmalloc objections can't be worked
> > > through, did you consider doing something li
From: Christoph Hellwig Sent: Wednesday, November 22, 2023
11:32 PM
>
> On Thu, Nov 23, 2023 at 12:24:49AM +, Michael Kelley wrote:
> > > I really do not want to expose vmap_pages_range. Please try to come up
> > > with a good way to encapsulate your map at a c
From: Christoph Hellwig Sent: Tuesday, November 21, 2023
10:26 PM
>
> On Tue, Nov 21, 2023 at 01:20:11PM -0800, mhkelle...@gmail.com wrote:
> > From: Michael Kelley
> >
> > The mm subsystem currently provides no mechanism to map memory pages
> > to a specified vir
From: Souradeep Chakrabarti Sent: Tuesday,
November 21, 2023 5:55 AM
>
> Existing MANA design assigns IRQ to every CPUs, including sibling
> hyper-threads
"assigns IRQs to every CPU"
> in a core. This causes multiple IRQs to work on same CPU and may reduce the
> network
"This may cause
bit(i, hvpci_dom_map) == 0)
> - return i;
> - }
> + i = find_and_set_bit(hvpci_dom_map, HVPCI_DOM_MAP_SIZE);
>
> - return HVPCI_DOM_INVALID;
> + return i < HVPCI_DOM_MAP_SIZE ? i : HVPCI_DOM_INVALID;
> }
>
> /**
> --
> 2.39.2
Reviewed-by: Michael Kelley
From: Michael Kelley Sent: Wednesday, November 15, 2023
9:26 PM
> >
> > diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c
> > b/drivers/net/ethernet/microsoft/mana/gdma_main.c
> > index 6367de0c2c2e..839be819d46e 100644
> > --- a/drivers/net/ether
From: Souradeep Chakrabarti Sent: Wednesday,
November 15, 2023 5:49 AM
>
> Existing MANA design assigns IRQ affinity to every sibling CPUs, which causes
Let's make this more specific by saying "... assigns IRQs to every CPU,
Including sibling hyper-threads in a core, which causes "
> IRQ
gt; return NMI_HANDLED;
>
> return NMI_DONE;
> --
> 2.41.0
The change looks correct to me. But is there any motivation other
than saving 3 bytes of generated code? This is not a performance
sensitive path. And the change adds 3 lines of source code. So
I wonder if the change is worth the churn.
In any case,
Reviewed-by: Michael Kelley
1 - 100 of 114 matches
Mail list logo
