On 05/08/2025 01:09, Sean Christopherson wrote:
> On Mon, Aug 04, 2025, Vitaly Kuznetsov wrote:
>> Sean Christopherson writes:
>>> It'll take more work than the below, e.g. to have VMX's construct_eptp()
>>> pull the
>>> level and A/D bits from kvm_mmu_page (vendor code can get at the
>>> kvm_mm
On 27/06/2025 10:31, Vitaly Kuznetsov wrote:
> Jeremi Piotrowski writes:
>
>> Use Hyper-V's HvCallFlushGuestPhysicalAddressSpace for local TLB flushes.
>> This makes any KVM_REQ_TLB_FLUSH_CURRENT (such as on root alloc) visible to
>> all CPUs which me
s the
KVM_REQ_TLB_FLUSH on CPU migration no longer necessary on Hyper-V.
Coincidentally - we now match the behavior of SVM on Hyper-V.
Signed-off-by: Jeremi Piotrowski
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/vmx/vmx.c | 20 +---
arch/x86/kvm/vmx/vmx_onhyperv.h
because that would
break the assumption that it is stronger than KVM_REQ_TLB_FLUSH_CURRENT).
With 2. the performance is comparable to EPT=N on Intel, roughly 20s for the
test scenario.
Let me know what you think about this and if you have any suggestions.
Best wishes,
Jeremi
[^1]: https://lore.kernel.org/kvm/yqljn
On 07/12/2023 18:36, Reshetova, Elena wrote:
The TDVMCALLs are related to the I/O path (networking/block io) into the L2
>> guest, and
so they intentionally go straight to L0 and are never injected to L1. L1
is not
involved in that path at all.
Using something differe
On 07/12/2023 18:21, Jeremi Piotrowski wrote:
> On 07/12/2023 13:58, Huang, Kai wrote:
>>>
>>> That's how it currently works - all the enlightenments are in
>>> hypervisor/paravisor
>>> specific code in arch/x86/hyperv and drivers/hv and the vm is no
On 07/12/2023 13:58, Huang, Kai wrote:
>>
>> That's how it currently works - all the enlightenments are in
>> hypervisor/paravisor
>> specific code in arch/x86/hyperv and drivers/hv and the vm is not marked with
>> X86_FEATURE_TDX_GUEST.
>
> And I believe there's a reason that the VM is not marke
On 06/12/2023 23:54, Kirill A. Shutemov wrote:
> On Wed, Dec 06, 2023 at 06:49:11PM +0100, Jeremi Piotrowski wrote:
>> On 05/12/2023 11:54, Kirill A. Shutemov wrote:
>>> On Mon, Dec 04, 2023 at 08:07:38PM +0100, Jeremi Piotrowski wrote:
>>>> On 04/12/2023
On 05/12/2023 14:26, Huang, Kai wrote:
>>
>
> Hm. Okay.
>
> Can we take a step back? What is bigger picture here? What enlightenment
> do you expect from the guest when everything is in-place?
>
All the functional enlightenment are already in place in the kernel an
On 05/12/2023 11:54, Kirill A. Shutemov wrote:
> On Mon, Dec 04, 2023 at 08:07:38PM +0100, Jeremi Piotrowski wrote:
>> On 04/12/2023 10:17, Reshetova, Elena wrote:
>>>> Check for additional CPUID bits to identify TDX guests running with Trust
>>>> Domain (TD) part
On 29/11/2023 17:40, Borislav Petkov wrote:
> On Wed, Nov 22, 2023 at 06:19:20PM +0100, Jeremi Piotrowski wrote:
>> Which approach do you prefer?
>
> I'm trying to figure out from the whole thread, what this guest is.
Wanted to clarify some things directly here. This type g
On 04/12/2023 10:17, Reshetova, Elena wrote:
>> Check for additional CPUID bits to identify TDX guests running with Trust
>> Domain (TD) partitioning enabled. TD partitioning is like nested
>> virtualization
>> inside the Trust Domain so there is a L1 TD VM(M) and there can be L2 TD
>> VM(s).
>>
On 30/11/2023 10:21, Borislav Petkov wrote:
> On Thu, Nov 30, 2023 at 08:31:03AM +, Reshetova, Elena wrote:
>> No threats whatsoever,
>
> I don't mean you - others. :-)
>
>> I just truly don’t know details of SEV architecture on this and how it
>> envisioned to operate under this nesting scen
ll strategy on this?
> We can try to push as much as possible complexity into L1 VMM in this
> scenario to keep the guest kernel almost free from these sprinkling
> differences.
> Afterall the L1 VMM can emulate whatever it wants for the guest.
> We can also see if there is a true n
On 29/11/2023 05:36, Huang, Kai wrote:
> On Fri, 2023-11-24 at 17:19 +0100, Jeremi Piotrowski wrote:
>> On 24/11/2023 14:33, Kirill A. Shutemov wrote:
>>> On Fri, Nov 24, 2023 at 12:04:56PM +0100, Jeremi Piotrowski wrote:
>>>> On 24/11/2023 11:43, Kirill A. Shutem
On 29/11/2023 11:37, Huang, Kai wrote:
> On Fri, 2023-11-24 at 11:38 +0100, Jeremi Piotrowski wrote:
>> On 23/11/2023 15:13, Kirill A. Shutemov wrote:
>>> On Wed, Nov 22, 2023 at 06:01:05PM +0100, Jeremi Piotrowski wrote:
>>>> Introduce CC_ATTR_TDX_MODULE_CALLS to a
On 24/11/2023 14:33, Kirill A. Shutemov wrote:
> On Fri, Nov 24, 2023 at 12:04:56PM +0100, Jeremi Piotrowski wrote:
>> On 24/11/2023 11:43, Kirill A. Shutemov wrote:
>>> On Fri, Nov 24, 2023 at 11:31:44AM +0100, Jeremi Piotrowski wrote:
>>>> On 23/11/2023 14:58, Kiri
On 24/11/2023 11:43, Kirill A. Shutemov wrote:
> On Fri, Nov 24, 2023 at 11:31:44AM +0100, Jeremi Piotrowski wrote:
>> On 23/11/2023 14:58, Kirill A. Shutemov wrote:
>>> On Wed, Nov 22, 2023 at 06:01:04PM +0100, Jeremi Piotrowski wrote:
>>>> Check for additional CPU
On 23/11/2023 15:13, Kirill A. Shutemov wrote:
> On Wed, Nov 22, 2023 at 06:01:05PM +0100, Jeremi Piotrowski wrote:
>> Introduce CC_ATTR_TDX_MODULE_CALLS to allow code to check whether TDX module
>> calls are available. When TD partitioning is enabled, a L1 TD VMM handles
On 23/11/2023 14:58, Kirill A. Shutemov wrote:
> On Wed, Nov 22, 2023 at 06:01:04PM +0100, Jeremi Piotrowski wrote:
>> Check for additional CPUID bits to identify TDX guests running with Trust
>> Domain (TD) partitioning enabled. TD partitioning is like nested
>> virtual
On 23/11/2023 15:11, Kirill A. Shutemov wrote:
> On Wed, Nov 22, 2023 at 06:01:06PM +0100, Jeremi Piotrowski wrote:
>> When CONFIG_INTEL_TDX_GUEST is not defined but CONFIG_UNACCEPTED_MEMORY=y is,
>> the kernel fails to link with an undefined reference to tdx_accept_
On 22/11/2023 18:01, Jeremi Piotrowski wrote:
> Check for additional CPUID bits to identify TDX guests running with Trust
> Domain (TD) partitioning enabled. TD partitioning is like nested
> virtualization
> inside the Trust Domain so there is a L1 TD VM(M) and there can be L
On 10/11/2023 19:57, kirill.shute...@linux.intel.com wrote:
> On Fri, Nov 10, 2023 at 02:42:31PM +0100, Jeremi Piotrowski wrote:
>> On 10/11/2023 13:46, kirill.shute...@linux.intel.com wrote:
>>> On Fri, Nov 10, 2023 at 01:27:08PM +0100, Jeremi Piotrowski wrote:
>>>>
On 10/11/2023 17:45, Borislav Petkov wrote:
> On Fri, Nov 10, 2023 at 04:51:43PM +0100, Jeremi Piotrowski wrote:
>> What's semi-correct about checking for CC_VENDOR_INTEL and then
>> printing Intel? I can post a v2 that checks CC_ATTR_GUEST_MEM_ENCRYPT
>> before prin
) which is forwarded
to the VMM for processing, which is the L1 TD VM in this case.
Cc: # v6.5+
Signed-off-by: Jeremi Piotrowski
---
arch/x86/coco/core.c | 3 +++
arch/x86/include/asm/unaccepted_memory.h | 2 +-
drivers/virt/coco/tdx-guest/tdx-guest.c | 3 +++
include/linux
: # v6.5+
Fixes: 75d090fd167a ("x86/tdx: Add unaccepted memory support")
Signed-off-by: Jeremi Piotrowski
---
arch/x86/include/asm/shared/tdx.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/include/asm/shared/tdx.h
b/arch/x86/include/asm/shared/tdx.h
index 75
have X86_FEATURE_TDX_GUEST set for all TDX guests so we
need to check these additional CPUID bits, but we skip further initialization
in the function as we aren't guaranteed access to TDX module calls.
Cc: # v6.5+
Signed-off-by: Jeremi Piotrowski
---
arch/x86/coco/tdx/tdx
On 10/11/2023 14:17, Borislav Petkov wrote:
> On Thu, Nov 09, 2023 at 07:41:33PM +0100, Jeremi Piotrowski wrote:
>> tdx_early_init() changes kernel behavior with the assumption that it
>> can talk directly to the TD module or change page visibility in
>> a certain way, in
On 10/11/2023 13:46, kirill.shute...@linux.intel.com wrote:
> On Fri, Nov 10, 2023 at 01:27:08PM +0100, Jeremi Piotrowski wrote:
>>> Maybe just remove incorrect info and that's it?
>>>
>>
>> I disagree, other users and I find the print very useful to se
On 10/11/2023 13:06, kirill.shute...@linux.intel.com wrote:
> On Thu, Nov 09, 2023 at 07:41:33PM +0100, Jeremi Piotrowski wrote:
>> It's not disregard, the way the kernel behaves in this case is correct except
>> for the error in reporting CPU vendor. Users care abou
On 09/11/2023 17:50, Dave Hansen wrote:
> On 11/9/23 08:35, Jeremi Piotrowski wrote:
>> On 09/11/2023 17:25, Dave Hansen wrote:
>>> On 11/9/23 08:14, Jeremi Piotrowski wrote:
>>> ...
>>>>pr_info("Memory Encryption Features active:");
>>>
On 09/11/2023 17:25, Dave Hansen wrote:
> On 11/9/23 08:14, Jeremi Piotrowski wrote:
> ...
>> pr_info("Memory Encryption Features active:");
>>
>> -if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
>> +if (cc_vendor == CC_VENDOR_INTEL)
from
tdx_early_init() or hv_vtom_init(), so the new code correctly handles both
cases. The previous check relied on the Linux-controlled TDX_GUEST CPU feature
which is only set in tdx_early_init().
Signed-off-by: Jeremi Piotrowski
---
arch/x86/mm/mem_encrypt.c | 2 +-
1 file changed, 1 insertion(+), 1 del
33 matches
Mail list logo
