On March 31, 2021 8:51:38 AM GMT+02:00, Kai Huang wrote:
>How about adding explanation to Documentation/x86/sgx.rst?
Sure, and then we should point users at it. The thing is also indexed by search
engines so hopefully people will find it.
Thx.
--
Sent from a small device: formatting sux and b
On March 31, 2021 3:10:32 AM GMT+02:00, Kai Huang wrote:
> The admin will be aware of
>such EPC
>allocation disjoint situation, and deploy host enclaves/KVM SGX guests
>accordingly.
The admin will be aware because...
1) he's following our discussion?
2) he'll read the commit messages and hope
On March 2, 2021 5:02:13 PM GMT+01:00, Sean Christopherson
wrote:
>The KVM use case is to query /proc/cpuinfo to see if sgx2 can be
>enabled in a
>guest.
You mean before the guest ia created? I sure hope there's a better way to query
HV-supported features than grepping /proc/cpuinfo...
>The co
On January 6, 2021 3:36:25 PM GMT+01:00, Peter Zijlstra
wrote:
>Instead of using noinstr, kill instrumentation for all of mce/. This
>switches MCE over to a best-effort but non-validated mode. Doing
>better will require a significant investment of time and effort.
Another thing that we could do
On August 13, 2020 5:17:10 PM GMT+03:00, Aristeu Rozanski
wrote:
>> So Tested-by: you ?
>
>Not by me, "we" meant as in company.
"you" can also mean you as a company. ;-P
>Tested-by: Vishal Agrawal
Thx.
--
Sent from a small device: formatting sux and brevity is inevitable.
On August 13, 2020 4:44:06 PM GMT+03:00, Aristeu Rozanski
wrote:
>We tested this inside in machines having this issue and it works.
>Patch looks good to me.
>
>Acked-by: Aristeu Rozanski
So Tested-by: you ?
--
Sent from a small device: formatting sux and brevity is inevitable.
On June 19, 2020 10:24:23 PM GMT+02:00, Dave Hansen
wrote:
>On 6/19/20 1:20 PM, Andy Lutomirski wrote:
>> Boris, etc: would it be reasonable to add a list of CPU features that
>> are present but turned off by firmware? SME is far from the only
>> thing that's frequently in this category. x2apic
On June 22, 2020 10:52:23 AM GMT+02:00, Alexandre Chartre
wrote:
> So the appropriate change to make Coverity happy
Or we can stop "fixing" the kernel in order to shut up tools and not do
anything.
--
Sent from a small device: formatting sux and brevity is inevitable.
On September 5, 2019 12:06:54 AM GMT+02:00, Boris Ostrovsky
wrote:
>Why do we need to taint kernel here? We are not making any changes.
Because this is not a normal operation we want users to do. This is only for
testing microcode quicker.
>This won't allow people to load from new microcode bl
On May 30, 2019 3:15:29 AM PDT, Hanna Hawa wrote:
>Add support for error detection and correction for Amazon's Annapurna
>Labs SoCs for L1/L2 caches.
So this should be a driver for the whole annapurna platform and not only about
the RAS functionality in an IP like the caches. See other ARM EDAC
On May 22, 2019 4:13:59 AM CDT, James Morse wrote:
>Hi Boris,
>
>On 21/05/2019 19:21, Borislav Petkov wrote:
>> On Tue, May 21, 2019 at 11:00:59AM +0530, Yash Shah wrote:
>>> The prerequisite patch (sifive_l2_cache driver) has been merged into
>>> mainline v5.2-rc1
>>> It should be OK to merge thi
On February 13, 2019 2:54:29 AM GMT+01:00, Chao Fan
wrote:
>Yes, your PATCH really works well. I tried both efi32 OVMF and efi64
>OVMF, all boot.
What about the real hardware you are normally testing on? Boots there too?
Thx.
--
Sent from a small device: formatting sux and brevity is inevitab
On December 31, 2018 3:20:00 PM GMT+02:00, Stefan Schaeckeler
wrote:
>Let me start with reviewing my own driver. Perhaps someone could review
>it as well, please?
Someone will review it when the merge window and vacations are over.
--
Sent from a small device: formatting sux and brevity is ine
On December 12, 2018 3:04:35 PM GMT+01:00, "Lendacky, Thomas"
wrote:
>Not sure I completely follow. Are you saying to do what I did in my
>first patch or something different from that yet?
I'm saying that STIBP_ALWAYS_ON should be implemented the same way like
IBRS_ENHANCED is and there's no ne
On November 21, 2018 1:41:37 PM GMT+01:00, Victoria Anosova
wrote:
>For v4.9 your first fix (
>https://lists.openwall.net/linux-kernel/2016/02/26/299) helped.
Can you please not top-post? Thx.
That old version is not quite right - see the commit message of the current fix.
HTH.
--
Sent from
On August 30, 2018 5:20:32 PM GMT+03:00, wufan wrote:
>> > +static int ghes_edac_dimm_index(u16 handle)
>>
>> get_dimm_smbios_handle()
>
>This function returns an index. So how about get_dimm_smbios_index()?
Sure.
--
Sent from a small device: formatting sux and brevity is inevitable.
On August 25, 2018 6:50:39 AM GMT+03:00, Jacek Tomaka wrote:
>/sys/devices/system/cpu/cpuX/microcode
>
>Before:
>-r processor_flags
>-r version
>
>After:
>-r--r--r-- processor_flags
>-r--r--r-- version
>
>Microcode version has been already readable for non root users via
>/proc/cpu
On August 1, 2018 7:01:50 PM GMT+03:00, Oleksandr Natalenko
wrote:
>I don't mind doing the right thing at all. It is just to inform you
>that
>it was found to be useful.
I don't think it would've worked if you did a second microcode upgrade on the
system.
--
Sent from a small device: format
On May 18, 2018 6:29:59 PM GMT+02:00, Nadav Amit wrote:
>Funny. I found in my mailbox that you once wrote me: "It is a dumb
>idea, it
>doesn't bring us anything besides some superficial readability which
>you
>don't really need.”
How about a proper quotation with the Message-id you're referring t
On March 23, 2018 9:40:50 AM CDT, "Maciej S. Szmigiero"
wrote:
>It is possible to keep verify_patch_size() unmodified (with unsigned
>int
>and u32) but microcode container files >4GB in size then may be
>rejected,
If we ever have to support that - which I'm pretty sure we won't - more changes
t
On January 11, 2018 9:42:38 AM GMT+01:00, Peter Zijlstra
wrote:
>Or we teach the alternative thing to patch in a jmp to end instead of
>NOP padding the entire thing as soon as the jmp (3 bytes) fits ?
Or, even better: use alternative_call() to call functions instead of patching
gazillion bytes.
On October 27, 2017 6:02:00 PM GMT+02:00, Dou Liyang
wrote:
>Commit:
>
> 9043442b43b1 ("locking/paravirt: Use new static key for controlling
> call of virt_spin_lock()")
>
>set the static virt_spin_lock_key to a value before jump_label_init()
>has been called, which will result in a WARN().
>
>
On October 22, 2017 3:04:29 PM GMT+02:00, Peter Zijlstra
wrote:
>I realize this is an erratum work around, but would it be too much to
>ask for a small comment explaining the magic values?
Revision guide doesn't state what those bits are. By the looks of it, they
could be some sort of chicken b
On July 24, 2017 8:44:03 PM GMT+03:00, "Kani, Toshimitsu"
wrote:
>I assumed our platforms w/o build-in RAS do not implement GHES,
If we make it a normal module, it will be decoupled from GHES and it will rely
only on the whitelist to load.
--
Sent from a small device: formatting sux and brevi
On March 9, 2017 11:08:17 AM GMT+01:00, Borislav Petkov wrote:
>From: Borislav Petkov
...
>diff --git a/arch/x86/ras/Kconfig b/arch/x86/ras/Kconfig
>index 0bc60a308730..2a2d89d39af6 100644
>--- a/arch/x86/ras/Kconfig
>+++ b/arch/x86/ras/Kconfig
>@@ -7,3 +7,17 @@ config MCE_AMD_INJ
> asp
On February 17, 2017 6:00:34 PM GMT+01:00, Jiri Olsa wrote:
>---
>Boris asked for default -a option in case we monitor
>only uncore events. While implementing that I thought
>it might be actually useful to make it overall default.
>
>Running 'perf stat' will now collect system wide data.
>
>Reques
On January 11, 2017 4:03:50 AM GMT+01:00, Suravee Suthikulpanit
wrote:
>
>Right Thanks for catching this. Do you want me to send out V8 with
>this fix?
Send only the corrected version of this patch please, as a reply to this
message.
Thanks.
--
Sent from a small device: formatting sux an
On January 4, 2017 10:37:31 AM GMT+02:00, Baoquan He wrote:
>In early boot code level2_kernel_pgt is used to map kernel text. And
>its
>size varies with KERNEL_IMAGE_SIZE and fixed at compiling time. In fact
>we can make it always take 512 entries of one whole page table, because
>later function c
On December 29, 2016 5:28:49 PM GMT+02:00, Augusto Mecking Caringi
wrote:
>The mce_irq_ipi() function is only called inside a #ifdef
>CONFIG_X86_LOCAL_APIC block, if this option is disabled gcc gives the
>following build warning:
>
>arch/x86/kernel/cpu/mcheck/mce-inject.c:97:13: warning: ‘mce_irq
On December 13, 2016 11:44:06 PM GMT+01:00, "H. Peter Anvin"
wrote:
>When compiling with -fPIC gcc treats ebx as a "fixed register". A
>fixed
>register can't be spilled, and so a clobber of a fixed register is a
>fatal error.
>
>Like it or not, it's how it works.
>
> -hpa
In the meantime
Haozhong Zhang wrote:
>On Intel platforms, this patch adds LMCE to KVM MCE supported
>capabilities and handles guest access to LMCE related MSRs.
>
>Signed-off-by: Ashok Raj
>Signed-off-by: Haozhong Zhang
SOB chain needs correction wrt who the author is and who the submitter.
--
Sent from
Andy Lutomirski wrote:
>Easier said than done. struct thread_info doesn't have addr_limit on
>sensible architectures (e.g. sparc), and I'd rather not stick a bunch
>of ifdefs in generic code.
It's not like it doesn't have an actual address limit though - I'm guessing it
is something like the ma
Aravind Gopalakrishnan wrote:
>Should I change that as well and move it to mce.h?
Yes please.
--
Sent from a small device: formatting sux and brevity is inevitable.
Aravind Gopalakrishnan wrote:
>
>
>That's precisely it-
>I thought I wasn't descriptive enough. But yeah, I guess I can include
>a
>reference to BKDG as well if anyone wants a detailed description.
No need for that. There are these things called search engines, you know...
;)
--
Sent from a
"H. Peter Anvin" wrote:
>Is there a reason why all this parsing has to be done in kernel space?
Not at all. What do you have in mind?
--
Sent from a small device: formatting sux and brevity is inevitable.
"Michael S. Tsirkin" wrote:
>Sorry - in which tree are these applied?
They'll appear in tip at some point.
--
Sent from a small device: formatting sux and brevity is inevitable.
Joerg Roedel wrote:
>Hmm, the arch/x86/events directory does not exist yet, is it the plan
>to move non-cpu event over there? It looks to be a better place for the
>iommu events, are there more no-cpu events to move there?
Yeah, basically move all arch/x86/ *perf_event* stuff there.
--
Sent
Andy Lutomirski wrote:
>You certainly can, but it doesn't scale well to multiple users of
>similar mechanisms. It also prevents you from using the same
>mechanism in anything that could be inlined, which is IMO kind of
>unfortunate.
Well, but the bit 31 game doesn't make it any better than the b
On 2/14/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> On Thursday 14 February 2008, Borislav Petkov wrote:
> > On Thu, Feb 14, 2008 at 12:37:50AM +0100, Hans-Peter Jansen wrote:
> >
> > [Added Bart to CC]
> >
> > > Am Dienstag, 12. Februar 2008 schrieb Borislav Petkov:
> > > > On Tue,
39 matches
Mail list logo
