Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

> On 16. May 2019, at 15:50, Graf, Alexander wrote: > > On 14.05.19 08:16, Filippo Sironi wrote: >> Start populating /sys/hypervisor with KVM entries when we're running on >> KVM. This is to replicate functionality that's available when we're >> running on Xen. >> >> Start with

Re: [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID

> On 16. May 2019, at 18:40, Boris Ostrovsky wrote: > > On 5/16/19 11:33 AM, Alexander Graf wrote: >> On 16.05.19 08:25, Sironi, Filippo wrote: >>>> On 16. May 2019, at 15:56, Graf, Alexander wrote: >>>> >>>> On 14.05.19 08:16, Filippo Si

Re: [PATCH v2 2/2] KVM: x86: Implement the arch-specific hook to report the VM UUID

> On 16. May 2019, at 15:56, Graf, Alexander wrote: > > On 14.05.19 08:16, Filippo Sironi wrote: >> On x86, we report the UUID in DMI System Information (i.e., DMI Type 1) >> as VM UUID. >> >> Signed-off-by: Filippo Sironi >> --- >> arch/x86/kernel/kvm.c | 7 +++ >> 1 file changed, 7

Re: [Xen-devel] [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

> On 16. May 2019, at 17:02, Boris Ostrovsky wrote: > > On 5/16/19 10:08 AM, Alexander Graf wrote: >> >> My point is mostly that we should be as common >> as possible when it comes to /sys/hypervisor, so that tools don't have >> to care about the HV they're working against. > > It might make

Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

> On 14. May 2019, at 18:09, Sironi, Filippo wrote: > >> On 14. May 2019, at 17:26, Christian Borntraeger >> wrote: >> >>> On 14.05.19 17:16, Filippo Sironi wrote: >>> Start populating /sys/hypervisor with KVM entries when we're running on >>

Re: [PATCH v2 1/2] KVM: Start populating /sys/hypervisor with KVM entries

> On 14. May 2019, at 17:26, Christian Borntraeger > wrote: > > > > On 14.05.19 17:16, Filippo Sironi wrote: >> Start populating /sys/hypervisor with KVM entries when we're running on >> KVM. This is to replicate functionality that's available when we're >> running on Xen. >> >> Start

Re: [PATCH] x86/microcode: Don't duplicate code to update ucode cpu info and cpu info

> On 31. Jul 2018, at 17:41, Greg KH wrote: > > On Tue, Jul 31, 2018 at 05:29:30PM +0200, Filippo Sironi wrote: >> ... on late microcode loading when handling a CPU that's already been >> updated and a CPU that's yet to be updated. >> >> Signed-off-by: Filippo Sironi >> --- >>

Re: [PATCH] x86/microcode: Don't duplicate code to update ucode cpu info and cpu info

> On 31. Jul 2018, at 17:41, Greg KH wrote: > > On Tue, Jul 31, 2018 at 05:29:30PM +0200, Filippo Sironi wrote: >> ... on late microcode loading when handling a CPU that's already been >> updated and a CPU that's yet to be updated. >> >> Signed-off-by: Filippo Sironi >> --- >>

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

> On 31. Jul 2018, at 15:00, Borislav Petkov wrote: > > On Tue, Jul 31, 2018 at 11:46:09AM +0000, Sironi, Filippo wrote: >> There may be a chance of skipping this code, I think. >> >> If the microcode is loaded on the hyperthread sibling of the boot cpu >> be

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

> On 31. Jul 2018, at 15:00, Borislav Petkov wrote: > > On Tue, Jul 31, 2018 at 11:46:09AM +0000, Sironi, Filippo wrote: >> There may be a chance of skipping this code, I think. >> >> If the microcode is loaded on the hyperthread sibling of the boot cpu >> be

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

> On 31. Jul 2018, at 13:27, Prarit Bhargava wrote: > > I tested this on AMD Ryzen & Intel Broadwell system and dumped the > boot_cpu_data before and after a microcode update. On the Intel > system I also did a fatal MCE using mce-inject to confirm the output > from the mce handling code. >

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

> On 31. Jul 2018, at 13:27, Prarit Bhargava wrote: > > I tested this on AMD Ryzen & Intel Broadwell system and dumped the > boot_cpu_data before and after a microcode update. On the Intel > system I also did a fatal MCE using mce-inject to confirm the output > from the mce handling code. >

Re: [PATCH] x86/MCE: Fix CPU microcode version output

> On 30. Jul 2018, at 18:16, Borislav Petkov wrote: > > On Mon, Jul 30, 2018 at 11:23:18AM -0400, Prarit Bhargava wrote: >> Filippo & Borislav, did the patch get committed to a -next tree? > > No, I'm still waiting for it - looks like Filippo is busy. > > Care to send one instead as

Re: [PATCH] x86/MCE: Fix CPU microcode version output

> On 30. Jul 2018, at 18:16, Borislav Petkov wrote: > > On Mon, Jul 30, 2018 at 11:23:18AM -0400, Prarit Bhargava wrote: >> Filippo & Borislav, did the patch get committed to a -next tree? > > No, I'm still waiting for it - looks like Filippo is busy. > > Care to send one instead as

Re: [PATCH] x86/MCE: Get microcode revision from cpu_info instead of boot_cpu_data

> On 1. Jun 2018, at 14:19, Borislav Petkov wrote: > > On Fri, Jun 01, 2018 at 01:30:26PM +0200, Filippo Sironi wrote: >> Commit fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check >> records") extended MCE entries to report the microcode revision taken >> from boot_cpu_data.

Re: [PATCH] x86/MCE: Get microcode revision from cpu_info instead of boot_cpu_data

> On 1. Jun 2018, at 14:19, Borislav Petkov wrote: > > On Fri, Jun 01, 2018 at 01:30:26PM +0200, Filippo Sironi wrote: >> Commit fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check >> records") extended MCE entries to report the microcode revision taken >> from boot_cpu_data.

Re: [Fwd: [RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()]

> On 8. Feb 2018, at 13:17, David Woodhouse wrote: > > > From: David Woodhouse > Subject: [RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in > slot_handle_level_range() > Date: 7. February 2018 at 01:03:12 GMT+1 > To: t...@linutronix.de,

Re: [Fwd: [RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()]

> On 8. Feb 2018, at 13:17, David Woodhouse wrote: > > > From: David Woodhouse > Subject: [RFC PATCH 2/4] KVM: x86: Reduce retpoline performance impact in > slot_handle_level_range() > Date: 7. February 2018 at 01:03:12 GMT+1 > To: t...@linutronix.de, torva...@linux-foundation.org,

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

> On 2. Feb 2018, at 15:59, David Woodhouse wrote: > > With retpoline, tight loops of "call this function for every XXX" are > very much pessimised by taking a prediction miss *every* time. > > This one showed up very high in our early testing, and it only has five > things

Re: [PATCH] KVM: x86: Reduce retpoline performance impact in slot_handle_level_range()

> On 2. Feb 2018, at 15:59, David Woodhouse wrote: > > With retpoline, tight loops of "call this function for every XXX" are > very much pessimised by taking a prediction miss *every* time. > > This one showed up very high in our early testing, and it only has five > things it'll ever call so

Re: [PATCH] sched/fair: Prevent a division by 0 in scale_rt_capacity()

> On 19. Dec 2017, at 20:33, Peter Zijlstra wrote: > > On Sat, Dec 09, 2017 at 09:03:49AM +0100, Filippo Sironi wrote: >> ... since total = sched_avg_period() + delta can yield 0x1, >> which results in a division by 0, given that div_u64() takes a u32 >> divisor.

Re: [PATCH] sched/fair: Prevent a division by 0 in scale_rt_capacity()

> On 19. Dec 2017, at 20:33, Peter Zijlstra wrote: > > On Sat, Dec 09, 2017 at 09:03:49AM +0100, Filippo Sironi wrote: >> ... since total = sched_avg_period() + delta can yield 0x1, >> which results in a division by 0, given that div_u64() takes a u32 >> divisor. Use div64_u64()

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 27. Nov 2017, at 14:09, Steve Rutherford wrote: > > On Mon, Nov 27, 2017 at 3:58 AM, Paolo Bonzini wrote: >> On 26/11/2017 17:41, Filippo Sironi wrote: >>> ... that the guest should see. >>> Guest operating systems may check the microcode

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 27. Nov 2017, at 14:09, Steve Rutherford wrote: > > On Mon, Nov 27, 2017 at 3:58 AM, Paolo Bonzini wrote: >> On 26/11/2017 17:41, Filippo Sironi wrote: >>> ... that the guest should see. >>> Guest operating systems may check the microcode version to decide whether >>> to disable certain

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 27. Nov 2017, at 03:58, Paolo Bonzini wrote: > > On 26/11/2017 17:41, Filippo Sironi wrote: >> ... that the guest should see. >> Guest operating systems may check the microcode version to decide whether >> to disable certain features that are known to be buggy up to

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 27. Nov 2017, at 03:58, Paolo Bonzini wrote: > > On 26/11/2017 17:41, Filippo Sironi wrote: >> ... that the guest should see. >> Guest operating systems may check the microcode version to decide whether >> to disable certain features that are known to be buggy up to certain >> microcode

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 27. Nov 2017, at 02:40, Paolo Bonzini wrote: > > On 26/11/2017 17:41, Filippo Sironi wrote: >> ... that the guest should see. >> Guest operating systems may check the microcode version to decide whether >> to disable certain features that are known to be buggy up to

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 27. Nov 2017, at 02:40, Paolo Bonzini wrote: > > On 26/11/2017 17:41, Filippo Sironi wrote: >> ... that the guest should see. >> Guest operating systems may check the microcode version to decide whether >> to disable certain features that are known to be buggy up to certain >> microcode

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 26. Nov 2017, at 17:02, Wanpeng Li wrote: > > 2017-11-27 0:41 GMT+08:00 Filippo Sironi : >> ... that the guest should see. >> Guest operating systems may check the microcode version to decide whether >> to disable certain features that are known to be

Re: [PATCH 2/2] KVM: x86: Allow userspace to define what's the microcode version

> On 26. Nov 2017, at 17:02, Wanpeng Li wrote: > > 2017-11-27 0:41 GMT+08:00 Filippo Sironi : >> ... that the guest should see. >> Guest operating systems may check the microcode version to decide whether >> to disable certain features that are known to be buggy up to certain >> microcode

Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via sysfs

> On 3. Oct 2017, at 21:48, Bjorn Helgaas <helg...@kernel.org> wrote: > > On Tue, Oct 03, 2017 at 02:31:14PM -0500, Bjorn Helgaas wrote: >> On Fri, Sep 29, 2017 at 07:53:31AM +, Sironi, Filippo wrote: >>> >>> Hi Bjorn, >>> >>>>

Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via sysfs

> On 3. Oct 2017, at 21:48, Bjorn Helgaas wrote: > > On Tue, Oct 03, 2017 at 02:31:14PM -0500, Bjorn Helgaas wrote: >> On Fri, Sep 29, 2017 at 07:53:31AM +, Sironi, Filippo wrote: >>> >>> Hi Bjorn, >>> >>>> On 25. Sep 2017,

Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via sysfs

Hi Bjorn, > On 25. Sep 2017, at 20:55, Bjorn Helgaas wrote: > > Hi Filippo, > > On Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote: >> +static ssize_t sriov_vf_did_show(struct device *dev, >> + struct device_attribute *attr, >> +

Re: [PATCH 2/2] pci: Expose offset, stride, and VF device ID via sysfs

Hi Bjorn, > On 25. Sep 2017, at 20:55, Bjorn Helgaas wrote: > > Hi Filippo, > > On Mon, Aug 28, 2017 at 03:38:50PM +0200, Filippo Sironi wrote: >> +static ssize_t sriov_vf_did_show(struct device *dev, >> + struct device_attribute *attr, >> +

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

Hi Jacob, > On 30. Aug 2017, at 17:50, Jacob Pan wrote: > > On Mon, 28 Aug 2017 16:16:29 +0200 > Filippo Sironi via iommu wrote: > >> Previously, we were invalidating context cache and IOTLB globally when >> clearing one context

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

Hi Jacob, > On 30. Aug 2017, at 17:50, Jacob Pan wrote: > > On Mon, 28 Aug 2017 16:16:29 +0200 > Filippo Sironi via iommu wrote: > >> Previously, we were invalidating context cache and IOTLB globally when >> clearing one context entry. This is a tad too aggressive. >> Invalidate the context

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

Hi Joerg, > On 30. Aug 2017, at 15:31, Joerg Roedel wrote: > > Hi Filippo, > > please change the subject to: > > iommu/vt-d: Don't be too aggressive when clearing one context entry > > to follow the convention used in the iommu-tree. Another comment below. Will do. >

Re: [PATCH] intel-iommu: Don't be too aggressive when clearing one context entry

Hi Joerg, > On 30. Aug 2017, at 15:31, Joerg Roedel wrote: > > Hi Filippo, > > please change the subject to: > > iommu/vt-d: Don't be too aggressive when clearing one context entry > > to follow the convention used in the iommu-tree. Another comment below. Will do. > On Mon, Aug 28,

Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

Thanks for taking the time and sorry for the delay. > On 6. Apr 2017, at 16:22, Radim Krčmář wrote: > > 2017-04-05 15:07+0200, Filippo Sironi: >> cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of >> pages and the respective struct pages for mapping in the

Re: [PATCH] x86, kvm: Handle PFNs outside of kernel reach when touching GPTEs

Thanks for taking the time and sorry for the delay. > On 6. Apr 2017, at 16:22, Radim Krčmář wrote: > > 2017-04-05 15:07+0200, Filippo Sironi: >> cmpxchg_gpte() calls get_user_pages_fast() to retrieve the number of >> pages and the respective struct pages for mapping in the kernel virtual >>