> 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 suggested
> 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.
>
>
> 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
> 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
>> ---
>> arch/x86/kernel
> 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. Unfortu
> 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 with
> 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
>
> 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
> 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 inser
> 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
> 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 /sys/hypervisor
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
>> add
> 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, x...@kerne
> 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 m
> 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() instead
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, 2
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 c
> 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,
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,
>> +
> 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 versio
> 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 ver
> 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 ver
> 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 fe
23 matches
Mail list logo