n fine.
Cc: sta...@vger.kernel.org
Fixes: 9fe41efaca084 ("tracing: Add synth event generation test module")
Reported-by: Alexander Graf
Signed-off-by: Steven Rostedt (Google)
Thanks a bunch for the super quick turnaround time for the fix! I can
confirm that I'm no longer seeing the warning :)
g")
Cc: sta...@vger.kernel.org
Cc: Alexander Graf
Reported-by: Yuan Yao
Signed-off-by: Sean Christopherson
Thanks a lot Sean for cleaning up after me! I was trying to be a bit too
smart with the inband count as token unfortunately :)
Reviewed-by: Alexander Graf
Alex
Amazon Developmen
On 08.03.21 15:36, Greg KH wrote:
On Mon, Mar 08, 2021 at 04:18:03PM +0200, Adrian Catangiu wrote:
+static struct miscdevice sysgenid_misc = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "sysgenid",
+ .fops = ,
+};
Much cleaner, but:
+static int __init sysgenid_init(void)
+{
+
On 24.02.21 23:41, Michael S. Tsirkin wrote:
On Wed, Feb 24, 2021 at 02:45:03PM +0100, Alexander Graf wrote:
Above should try harder to explan what are the things that need to be
scrubbed and why. For example, I personally don't really know what is
the OpenSSL session token example and what
On 24.02.21 10:19, Michael S. Tsirkin wrote:
On Wed, Feb 24, 2021 at 10:47:31AM +0200, Adrian Catangiu wrote:
- Background and problem
The System Generation ID feature is required in virtualized or
containerized environments by applications that work with local copies
or caches of
On 10.02.21 11:39, Hikaru Nishida wrote:
From: Hikaru Nishida
Hi folks,
We'd like to add a sysfs interface that enable us to advance
CLOCK_BOOTTIME from userspace. The use case of this change is that
adjusting guest's CLOCK_BOOTTIME as host suspends to ensure that the
guest can notice
Hey Michael!
On 27.01.21 13:47, Michael S. Tsirkin wrote:
On Thu, Jan 21, 2021 at 10:28:16AM +, Catangiu, Adrian Costin wrote:
On 12/01/2021, 14:49, "Michael S. Tsirkin" wrote:
On Tue, Jan 12, 2021 at 02:15:58PM +0200, Adrian Catangiu wrote:
> The first patch in the set
On 20.01.21 19:06, Mohamed Mediouni wrote:
On 20 Jan 2021, at 17:47, Alexander Graf wrote:
On 20.01.21 14:27, Mohamed Mediouni wrote:
Use nGnRnE instead of nGnRE on Apple SoCs to workaround a serious hardware
quirk.
On Apple processors, writes using the nGnRE device memory type get
On 20.01.21 14:27, Mohamed Mediouni wrote:
From: Stan Skowronek
Apple SoCs use the Apple AIC interrupt controller.
The Arm architectural timers is wired over FIQ on that hardware.
Signed-off-by: Stan Skowronek
Signed-off-by: Mohamed Mediouni
---
.../interrupt-controller/apple,aic.yaml
On 20.01.21 14:27, Mohamed Mediouni wrote:
From: Stan Skowronek
WFI drops register state on Apple Silicon for SMP systems.
It probably drops the register because it loses power on WFI, right?
Have you tried to set the ARM64_REG_CYC_OVRD_ok2pwrdn_force_up bit in
ARM64_REG_CYC_OVRD yet? XNU
On 20.01.21 14:27, Mohamed Mediouni wrote:
Use nGnRnE instead of nGnRE on Apple SoCs to workaround a serious hardware
quirk.
On Apple processors, writes using the nGnRE device memory type get dropped in
flight,
getting to nowhere.
Signed-off-by: Stan Skowronek
Signed-off-by: Mohamed
On 27.11.20 21:20, Jann Horn wrote:
On Fri, Nov 27, 2020 at 8:04 PM Catangiu, Adrian Costin
wrote:
On 27/11/2020 20:22, Jann Horn wrote:
On Fri, Nov 20, 2020 at 11:29 PM Jann Horn wrote:
On Mon, Nov 16, 2020 at 4:35 PM Catangiu, Adrian Costin
wrote:
This patch is a driver that exposes
On 27.11.20 18:17, Catangiu, Adrian Costin wrote:
On 18/11/2020 12:30, Alexander Graf wrote:
On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
- Future improvements
Ideally we would want the driver to register itself based on devices'
_CID and not _HID, but unfortunately I couldn't find
On 27.11.20 19:26, Catangiu, Adrian Costin wrote:
- Background
The VM Generation ID is a feature defined by Microsoft (paper:
http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
multiple hypervisor vendors.
The feature is required in virtualized environments by apps that work
On 19.11.20 18:38, Mike Rapoport wrote:
On Thu, Nov 19, 2020 at 01:51:18PM +0100, Alexander Graf wrote:
On 19.11.20 13:02, Christian Borntraeger wrote:
On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
- Background
The VM Generation ID is a feature defined by Microsoft (paper:
http
On 19.11.20 15:03, Stefan Hajnoczi wrote:
On Thu, Nov 12, 2020 at 02:38:37PM +0100, Stefano Garzarella wrote:
Before commit c0cfa2d8a788 ("vsock: add multi-transports support"),
if a G2H transport was loaded (e.g. virtio transport), every packets
was forwarded to the host, regardless of the
On 19.11.20 13:02, Christian Borntraeger wrote:
On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
- Background
The VM Generation ID is a feature defined by Microsoft (paper:
http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
multiple hypervisor vendors.
The feature is required
On 16.11.20 16:34, Catangiu, Adrian Costin wrote:
- Background
The VM Generation ID is a feature defined by Microsoft (paper:
http://go.microsoft.com/fwlink/?LinkId=260709) and supported by
multiple hypervisor vendors.
The feature is required in virtualized environments by apps that work
On 13.11.20 16:55, Joel Fernandes wrote:
+static enum coresched_cmds coresched_cmd __ro_after_init = CORE_SCHED_SECURE;
+
+static int __init coresched_parse_cmdline(char *arg)
+{
+ if (!strcmp(arg, "off"))
+ coresched_cmd = CORE_SCHED_OFF;
+ else if (!strcmp(arg,
On 12.11.20 15:40, Joel Fernandes wrote:
On Thu, Nov 12, 2020 at 08:40:05AM -0500, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 11:29:37PM +0100, Alexander Graf wrote:
On 11.11.20 23:15, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 5:13 PM Joel Fernandes wrote:
On Wed, Nov 11
On 12.11.20 16:28, Joel Fernandes wrote:
On Thu, Nov 12, 2020 at 03:52:32PM +0100, Alexander Graf wrote:
On 12.11.20 14:40, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 11:29:37PM +0100, Alexander Graf wrote:
On 11.11.20 23:15, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 5:13 PM
On 12.11.20 14:40, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 11:29:37PM +0100, Alexander Graf wrote:
On 11.11.20 23:15, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 5:13 PM Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 5:00 PM Alexander Graf wrote:
On 11.11.20 22:14, Joel
On 11.11.20 23:15, Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 5:13 PM Joel Fernandes wrote:
On Wed, Nov 11, 2020 at 5:00 PM Alexander Graf wrote:
On 11.11.20 22:14, Joel Fernandes wrote:
Some hardware such as certain AMD variants don't have cross-HT MDS/L1TF
issues. Detect
On 11.11.20 22:14, Joel Fernandes wrote:
Sorry, forgot to CC +Tom Lendacky . Please take a look Tom, thanks.
On Wed, Nov 11, 2020 at 4:10 PM Joel Fernandes (Google)
wrote:
Some hardware such as certain AMD variants don't have cross-HT MDS/L1TF
issues. Detect this and don't enable core
rom the poll function.
Signed-off-by: Andra Paraschiv
Reported-by: kernel test robot
Reviewed-by: Alexander Graf
Alex
---
drivers/virt/nitro_enclaves/ne_misc_dev.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/virt/nitro_enclaves/ne_misc_dev.c
b/driv
On 14.10.20 11:05, Andra Paraschiv wrote:
Update the assigned value of the poll result to be EPOLLHUP instead of
POLLHUP to match the __poll_t type.
Signed-off-by: Andra Paraschiv
Reported-by: kernel test robot
---
drivers/virt/nitro_enclaves/ne_misc_dev.c | 2 +-
1 file changed, 1
On 20.10.20 12:34, Paolo Bonzini wrote:
On 20/10/20 11:48, Alexander Graf wrote:
count: 1,
default_allow: false,
ranges: [
{
flags: KVM_MSR_FILTER_READ,
nmsrs: 1,
base: MSR_EFER,
bitmap: { 1
On 19.10.20 19:15, Mathieu Desnoyers wrote:
- On Oct 17, 2020, at 2:10 PM, Andy Lutomirski l...@kernel.org wrote:
On Fri, Oct 16, 2020 at 6:40 PM Jann Horn wrote:
[adding some more people who are interested in RNG stuff: Andy, Jason,
Theodore, Willy Tarreau, Eric Biggers. also
On 20.10.20 11:35, Christian Borntraeger wrote:
On 17.10.20 20:09, Alexander Graf wrote:
Hi Jason,
On 17.10.20 15:24, Jason A. Donenfeld wrote:
After discussing this offline with Jann a bit, I have a few general
comments on the design of this.
First, the UUID communicated by the hypervisor
On 20.10.20 11:27, Paolo Bonzini wrote:
On 19/10/20 19:45, Graf (AWS), Alexander wrote:
+* In principle it would be possible to trap x2apic ranges
+* if !lapic_in_kernel. This however would be complicated
+* because KVM_X86_SET_MSR_FILTER can be called before
+
Hi Jason,
On 17.10.20 15:24, Jason A. Donenfeld wrote:
After discussing this offline with Jann a bit, I have a few general
comments on the design of this.
First, the UUID communicated by the hypervisor should be consumed by
the kernel -- added as another input to the rng -- and then userspace
userspace
interception could work for those registers, though it is still silly.
Cc: Alexander Graf
Cc: Aaron Lewis
Cc: Peter Xu
Signed-off-by: Sean Christopherson
I'm not opposed in general to leaving APICV handled registers out of the
filtering logic. However, this really needs a note
the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.
Signed-off-by: Alexander Graf
Reviewed-by: Jim Mattson
---
v1 -&g
that came in between]
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm/svm.c| 60
arch/x86/kvm/vmx/nested.c | 2 +-
arch/x86/kvm/vmx/vmx.c| 83 +++
arch/x86/kvm/vmx/vmx.h| 2 +-
4 files changed, 77 insertions(+), 70
Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- s/KVM_CAP_ADD_MSR_ALLOWL
In the following commits we will add pieces of MSR filtering.
To ensure that code compiles even with the feature half-merged, let's add
a few stubs and struct definitions before the real patches start.
Signed-off-by: Alexander Graf
---
v7 -> v8:
s/KVM_MSR_ALLOW/KVM_MSR_FILTER/g
---
a
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
v7 -> v8:
- s/KVM_MSR_ALLOW/KVM_MSR_FILTER/g
---
arch/x86/kvm/svm/svm.c | 77 +-
arch/x86/kvm/svm/svm.h | 7
2 files changed, 76 insertions(+), 8 deletions(-)
d
When we find an MSR that we can not handle, bubble up that error code as
MSR error return code. Follow up patches will use that to expose the fact
that an MSR is not handled by KVM to user space.
Suggested-by: Aaron Lewis
Signed-off-by: Alexander Graf
---
arch/x86/kvm/x86.c | 2 +-
1 file
_MAX_RANGES
- adapt KVM_MSR_EXIT_REASON_FILTER value
- selftest: add KVM_MSR_EXIT_REASON_UNKNOWN handling
Aaron Lewis (1):
KVM: x86: Prepare MSR bitmaps for userspace tracked MSRs
Alexander Graf (7):
KVM: x86: Return -ENOENT on unimplemented MSRs
KVM: x86: Deflect unknown MSR accesses to user space
KVM: x8
is populated, MSR handling stays identical to before.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- document flags for KVM_X86_ADD_MSR_ALLOWLIST
- generalize exit path, always unlock when returning
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIST/g
- Add KVM_X86_CLEAR_MSR_ALLOWL
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
v6 -> v7:
- s/MAX_POSSIBLE_PASSGHROUGH_MSRS/MAX_POSSIBLE_PASSTHROUGH_MSRS/g
---
arch/x86/kvm/vmx/vmx.c | 226 +++--
arch/x86/kvm/vmx/vmx.h | 7 ++
2 files changed,
On 16.09.20 22:13, Aaron Lewis wrote:
+
/*
* These 2 parameters are used to config the controls for Pause-Loop Exiting:
* ple_gap:upper bound on the amount of time between two successive
@@ -622,6 +642,41 @@ static inline bool report_flexpriority(void)
return
the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.
Signed-off-by: Alexander Graf
Reviewed-by: Jim Mattson
---
v1 -&g
ftest: fix asserts
- selftest: add test for invalid msr handling
Aaron Lewis (1):
KVM: x86: Prepare MSR bitmaps for userspace tracked MSRs
Alexander Graf (6):
KVM: x86: Deflect unknown MSR accesses to user space
KVM: x86: Add infrastructure for MSR filtering
KVM: x86: SVM: Prevent MSR pa
In the following commits we will add pieces of MSR filtering.
To ensure that code compiles even with the feature half-merged, let's add
a few stubs and struct definitions before the real patches start.
Signed-off-by: Alexander Graf
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/include
that came in between]
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm/svm.c| 60
arch/x86/kvm/vmx/nested.c | 2 +-
arch/x86/kvm/vmx/vmx.c| 83 +++
arch/x86/kvm/vmx/vmx.h| 2 +-
4 files changed, 77 insertions(+), 70
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm/svm.c | 77 +-
arch/x86/kvm/svm/svm.h | 7
2 files changed, 76 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
is populated, MSR handling stays identical to before.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- document flags for KVM_X86_ADD_MSR_ALLOWLIST
- generalize exit path, always unlock when returning
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIST/g
- Add KVM_X86_CLEAR_MSR_ALLOWL
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
v6 -> v7:
- s/MAX_POSSIBLE_PASSGHROUGH_MSRS/MAX_POSSIBLE_PASSTHROUGH_MSRS/g
---
arch/x86/kvm/vmx/vmx.c | 226 +++--
arch/x86/kvm/vmx/vmx.h | 7 ++
2 files changed,
Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- s/KVM_CAP_ADD_MSR_ALLOWL
On 04.09.20 04:18, Aaron Lewis wrote:
+/*
+ * List of MSRs that can be directly passed to the guest.
+ * In addition to these x2apic and PT MSRs are handled specially.
+ */
+static u32 vmx_possible_passthrough_msrs[MAX_POSSIBLE_PASSGHROUGH_MSRS] = {
MAX_POSSIBLE_PASSGHROUGH_MSRS should be
On 16.09.20 19:08, Sean Christopherson wrote:
On Wed, Sep 16, 2020 at 11:31:30AM +0200, Alexander Graf wrote:
On 03.09.20 21:27, Aaron Lewis wrote:
@@ -412,6 +414,15 @@ struct kvm_run {
__u64 esr_iss;
__u64 fault_ipa
Hi Aaron,
Thanks a lot for the amazing review! I've been caught in some other
things recently, so sorry for the delayed response.
On 03.09.20 21:27, Aaron Lewis wrote:
+::
+
+ /* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */
+ struct {
+ __u8
is populated, MSR handling stays identical to before.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- document flags for KVM_X86_ADD_MSR_ALLOWLIST
- generalize exit path, always unlock when returning
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIST/g
- Add KVM_X86_CLEAR_MSR_ALLOWL
Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- s/KVM_CAP_ADD_MSR_ALLOWL
the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.
Signed-off-by: Alexander Graf
Reviewed-by: Jim Mattson
---
v1 -&g
On 02.09.20 00:32, Aaron Lewis wrote:
On Tue, Sep 1, 2020 at 1:15 PM Alexander Graf wrote:
While tying to add support for the MSR_CORE_THREAD_COUNT MSR in KVM,
I realized that we were still in a world where user space has no control
over what happens with MSR emulation in KVM.
That is bad
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
arch/x86/kvm/vmx/vmx.c | 226 +++--
arch/x86/kvm/vmx/vmx.h | 7 ++
2 files changed, 181 insertions(+), 52 deletions(-)
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx
From: Aaron Lewis
Prepare vmx and svm for a subsequent change that ensures the MSR permission
bitmap is set to allow an MSR that userspace is tracking to force a vmx_vmexit
in the guest.
Signed-off-by: Aaron Lewis
Reviewed-by: Oliver Upton
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm/svm.c | 78 +-
arch/x86/kvm/svm/svm.h | 7
2 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
In the following commits we will add pieces of MSR filtering.
To ensure that code compiles even with the feature half-merged, let's add
a few stubs and struct definitions before the real patches start.
Signed-off-by: Alexander Graf
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/include
new patch: KVM: x86: VMX: Prevent MSR passthrough when MSR access is denied
Aaron Lewis (1):
KVM: x86: Prepare MSR bitmaps for userspace tracked MSRs
Alexander Graf (6):
KVM: x86: Deflect unknown MSR accesses to user space
KVM: x86: Add infrastructure for MSR filtering
KVM: x86: S
From: Aaron Lewis
Prepare vmx and svm for a subsequent change that ensures the MSR permission
bitmap is set to allow an MSR that userspace is tracking to force a vmx_vmexit
in the guest.
Signed-off-by: Aaron Lewis
Reviewed-by: Oliver Upton
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm
In the following commits we will add pieces of MSR filtering.
To ensure that code compiles even with the feature half-merged, let's add
a few stubs and struct definitions before the real patches start.
Signed-off-by: Alexander Graf
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/include
trapped are not marked as direct access for guests.
Signed-off-by: Alexander Graf
---
arch/x86/kvm/svm/svm.c | 78 +-
arch/x86/kvm/svm/svm.h | 7
2 files changed, 77 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.
Signed-off-by: Alexander Graf
Reviewed-by: Jim Mattson
---
v1 -&g
new patch: KVM: x86: VMX: Prevent MSR passthrough when MSR access is denied
Aaron Lewis (1):
KVM: x86: Prepare MSR bitmaps for userspace tracked MSRs
Alexander Graf (6):
KVM: x86: Deflect unknown MSR accesses to user space
KVM: x86: Add infrastructure for MSR filtering
KVM: x86: S
On 20.08.20 00:49, Jim Mattson wrote:
On Mon, Aug 3, 2020 at 2:14 PM Alexander Graf wrote:
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -901,6 +901,13 @@ struct kvm_hv {
struct kvm_hv_syndbg hv_syndbg;
};
+struct msr_bitmap_range {
+ u32
properly when we
know which task we want to run, let's add an explicit callback to
the scheduler class which can then be triggered from the core's
pick_next_task().
With this patch, core scheduling with HRTICK enabled does see
improved responsiveness on scheduling decisions.
Signed-off-by: Alexander Graf
for as long as it executed before, to bring the overall queue's
vruntime into balance again.
With this patch, even a too early hrtick timer event will just reconfigure
the hrtick to when we expected it to fire, removing overall jitter from
the system.
Signed-off-by: Alexander Graf
---
kernel
if sched_min_granularity
is smaller than the HZ tick would allow us to account with. That way systems
with HZ=1000 will usually resort to the HZ tick while systems at lower HZ values
will keep using hrticks.
Signed-off-by: Alexander Graf
---
kernel/sched/fair.c | 3 ++-
1 file changed, 2 insertions
s not work with the Core
Scheduling patch set. This patch set adds support for it.
Feel free to squash bits in where it makes sense.
Alex
Alexander Graf (3):
sched: Allow hrticks to work with core scheduling
sched: Trigger new hrtick if timer expires too fast
sched: Use hrticks even with >sch
Hi Vineeth,
On 30.06.20 23:32, Vineeth Remanan Pillai wrote:
Sixth iteration of the Core-Scheduling feature.
Core scheduling is a feature that allows only trusted tasks to run
concurrently on cpus sharing compute resources (eg: hyperthreads on a
core). The goal is to mitigate the core-level
On 26.08.20 23:47, David Laight wrote:
From: David Laight
Sent: 26 August 2020 22:37
From: Thomas Gleixner
Sent: 26 August 2020 21:22
...
Moving interrupts on x86 happens in several steps. A new vector on a
different CPU is allocated and the relevant interrupt source is
reprogrammed to
a
real patch? :)
Tested-by: Alexander Graf
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
On 26.08.20 16:27, Thomas Gleixner wrote:
On Wed, Aug 26 2020 at 13:53, Alexander Graf wrote:
Commit 633260fa143 ("x86/irq: Convey vector as argument and not in ptregs")
changed the handover logic of the vector identifier from ~vector in orig_ax
to purely register based. Unf
On 26.08.20 15:22, Josh Poimboeuf wrote:
On Wed, Aug 26, 2020 at 01:53:57PM +0200, Alexander Graf wrote:
-.macro idtentry_body cfunc has_error_code:req
+.macro idtentry_body cfunc has_error_code:req preserve_error_code:req
callerror_entry
UNWIND_HINT_REGS
@@ -328,7 +328,9
e restored to previous levels.
Reported-by: Alex bykov
Reported-by: Avi Kivity
Fixes: 633260fa143 ("x86/irq: Convey vector as argument and not in ptregs")
Cc: sta...@vger.kernel.org
Signed-off-by: Alexander Graf
---
arch/x86/entry/entry_32.S | 2 +-
arch/x86/entry
Hi Andy,
On 26.08.20 01:41, Andy Lutomirski wrote:
On Tue, Aug 25, 2020 at 4:18 PM Alexander Graf wrote:
Hi Thomas,
On 25.08.20 12:28, Thomas Gleixner wrote:
void irq_complete_move(struct irq_cfg *cfg)
{
__irq_complete_move(cfg, ~get_irq_regs()->orig_ax);
}
Alex,
On Mon,
Hi Thomas,
On 25.08.20 12:28, Thomas Gleixner wrote:
Alex,
On Mon, Aug 24 2020 at 19:29, Alexander Graf wrote:
I'm currently trying to understand a performance regression with
ScyllaDB on i3en.3xlarge (KVM based VM on Skylake) which we reliably
bisected down to this commit:
https
Hi Thomas,
On 21.05.20 22:05, Thomas Gleixner wrote:
From: Thomas Gleixner
Device interrupts which go through do_IRQ() or the spurious interrupt
handler have their separate entry code on 64 bit for no good reason.
Both 32 and 64 bit transport the vector number through ORIG_[RE]AX in
pt_regs.
in the primary VM via a poll notification mechanism. Then the user space
enclave process can exit.
Thank you.
This version reads very well, thanks a lot Andra!
Greg, would you mind to have another look over it?
Reviewed-by: Alexander Graf
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
channel addressing -
vsock CID - and the flags associated with the enclave.
Signed-off-by: Alexandru Vasile
Signed-off-by: Andra Paraschiv
Reviewed-by: Alexander Graf
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan
memory where to
place the enclave image. Then the user space tooling copies the enclave
image in the memory using the given memory offset.
Signed-off-by: Andra Paraschiv
Reviewed-by: Alexander Graf
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung
.
Signed-off-by: Alexandru Vasile
Signed-off-by: Andra Paraschiv
Reviewed-by: Alexander Graf
Alex
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz
On 05.08.20 11:10, Andra Paraschiv wrote:
An enclave, before being started, has its resources set. One of its
resources is CPU.
A NE CPU pool is set and enclave CPUs are chosen from it. Offline the
CPUs from the NE CPU pool during the pool setup and online them back
during the NE CPU pool
.
Signed-off-by: Alexandru Vasile
Signed-off-by: Andra Paraschiv
Reviewed-by: Alexander Graf
---
Changelog
v5 -> v6
* Update the code base to init the ioctl function in this patch.
* Update documentation to kernel-doc format.
v4 -> v5
* Release the reference to the NE PCI device on cre
On 05.08.20 11:10, Andra Paraschiv wrote:
The Nitro Enclaves driver provides an ioctl interface to the user space
for enclave lifetime management e.g. enclave creation / termination and
setting enclave resources such as memory and CPU.
This ioctl interface is mapped to a Nitro Enclaves misc
Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- s/KVM_CAP_ADD_MSR_ALLOWL
is populated, MSR handling stays identical to before.
Signed-off-by: KarimAllah Ahmed
Signed-off-by: Alexander Graf
---
v2 -> v3:
- document flags for KVM_X86_ADD_MSR_ALLOWLIST
- generalize exit path, always unlock when returning
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIS
the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.
Signed-off-by: Alexander Graf
Reviewed-by: Jim Mattson
---
v1 -&g
redundant pending_user_msr field
- lock allow check and clearing
- free bitmaps on clear
v4 -> v5:
- use srcu
Alexander Graf (3):
KVM: x86: Deflect unknown MSR accesses to user space
KVM: x86: Introduce allow list for MSR emulation
KVM: selftests: Add test for user space MSR handling
D
the existing "ignore_msrs" logic with
something that applies per-VM rather than on the full system. That way you
can run productive VMs in parallel to experimental ones where you don't care
about proper MSR handling.
Signed-off-by: Alexander Graf
Reviewed-by: Jim Mattson
---
v1 -&g
redundant pending_user_msr field
- lock allow check and clearing
- free bitmaps on clear
Alexander Graf (3):
KVM: x86: Deflect unknown MSR accesses to user space
KVM: x86: Introduce allow list for MSR emulation
KVM: selftests: Add test for user space MSR handling
Documentation/virt/kv
Now that we have the ability to handle MSRs from user space and also to
select which ones we do want to prevent in-kernel KVM code from handling,
let's add a selftest to show case and verify the API.
Signed-off-by: Alexander Graf
---
v2 -> v3:
- s/KVM_CAP_ADD_MSR_ALLOWL
is populated, MSR handling stays identical to before.
Signed-off-by: KarimAllah Ahmed
Signed-off-by: Alexander Graf
---
v2 -> v3:
- document flags for KVM_X86_ADD_MSR_ALLOWLIST
- generalize exit path, always unlock when returning
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIS
On 03.08.20 13:37, Vitaly Kuznetsov wrote:
Alexander Graf writes:
It's not desireable to have all MSRs always handled by KVM kernel space. Some
MSRs would be useful to handle in user space to either emulate behavior (like
uCode updates) or differentiate whether they are valid based
On 03.08.20 13:27, Vitaly Kuznetsov wrote:
Alexander Graf writes:
MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads, and not performance critical.
Others again
On 01.08.20 01:36, Jim Mattson wrote:
On Fri, Jul 31, 2020 at 2:50 PM Alexander Graf wrote:
MSRs are weird. Some of them are normal control registers, such as EFER.
Some however are registers that really are model specific, not very
interesting to virtualization workloads
is populated, MSR handling stays identical to before.
Signed-off-by: KarimAllah Ahmed
Signed-off-by: Alexander Graf
---
v2 -> v3:
- document flags for KVM_X86_ADD_MSR_ALLOWLIST
- generalize exit path, always unlock when returning
- s/KVM_CAP_ADD_MSR_ALLOWLIST/KVM_CAP_X86_MSR_ALLOWLIS
1 - 100 of 843 matches
Mail list logo
