On 2/4/25 9:48 AM, Colin Ian King wrote:
There is a spelling mistake in a literal string. Fix it.
Signed-off-by: Colin Ian King
---
tools/testing/selftests/kvm/s390/cmma_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/s390/cmma_test.c
b
On 8/23/24 3:05 PM, Hariharan Mari wrote:
This patch series introduces a set of regression tests for various s390x
CPU subfunctions in KVM. The tests ensure that the KVM implementation accurately
reflects the behavior of actual CPU instructions for these subfunctions.
The series adds tests for a
On 2/28/21 7:10 AM, Masahiro Yamada wrote:
> scripts/Kbuild.include is included everywhere, but macros such as
> cc-option are needed by build targets only.
>
> For example, when 'make clean' traverses the tree, it does not need
> to evaluate $(call cc-option,).
>
> Split cc-option, ld-option, et
On 3/8/21 4:19 PM, Christian Borntraeger wrote:
> On 02.03.21 18:44, Claudio Imbrenda wrote:
>> The current handling of the MVPG instruction when executed in a nested
>> guest is wrong, and can lead to the nested guest hanging.
>>
>> This patchset fixes the behaviour to be more architecturally corr
On 2/23/21 8:13 PM, Claudio Imbrenda wrote:
> The current handling of the MVPG instruction when executed in a nested
> guest is wrong, and can lead to the nested guest hanging.
>
> This patchset fixes the behaviour to be more architecturally correct,
> and fixes the hangs observed.
Could you plea
On 2/13/21 4:32 PM, Bhaskar Chowdhury wrote:
>
> s/oustanding/outstanding/
Hey Bhaskar,
while I do encourage anyone to send in changes I'm not a big fan of
comment fixes if they are only a couple of characters and when the
meaning is still intact despite the spelling mistake.
You're creating mo
gt; ---
Thanks for fixing this.
Acked-by: Janosch Frank
> arch/s390/kvm/vsie.c | 93 +---
> 1 file changed, 88 insertions(+), 5 deletions(-)
>
> diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
> index 7db022141db3..7dbb0d93c25f 10
because of the
> protection bit in the segment (or, if EDAT, region) tables
> NOT_PTE: indicates that the address of the DAT table entry returned
> does not refer to a PTE, but to a segment or region table.
>
> Signed-off-by: Claudio Imbrenda
> Cc: sta...@vger.kernel.org
R
On 2/5/21 1:15 PM, Claudio Imbrenda wrote:
> On Thu, 4 Feb 2021 17:34:00 +0100
> Janosch Frank wrote:
>
>> On 2/2/21 7:00 PM, Claudio Imbrenda wrote:
>>> Extend kvm_s390_shadow_fault to return the pointer to the valid leaf
>>> DAT table entry, or to the invali
On 2/2/21 7:00 PM, Claudio Imbrenda wrote:
> Correctly handle the MVPG instruction when issued by a VSIE guest.
>
> Fixes: a3508fbe9dc6d ("KVM: s390: vsie: initial support for nested
> virtualization")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Claudio Imbrenda
So far the patch looks ok to m
On 2/4/21 5:34 PM, Janosch Frank wrote:
> On 2/2/21 7:00 PM, Claudio Imbrenda wrote:
>> Extend kvm_s390_shadow_fault to return the pointer to the valid leaf
>> DAT table entry, or to the invalid entry.
>>
>> Also return some flags in the lower bits of the address:
>
On 2/2/21 7:00 PM, Claudio Imbrenda wrote:
> Extend kvm_s390_shadow_fault to return the pointer to the valid leaf
> DAT table entry, or to the invalid entry.
>
> Also return some flags in the lower bits of the address:
> DAT_PROT: indicates that DAT protection applies because of the
> pr
The number reported by the query is N-1 and I think people reading the
sysfs file would expect N instead. For users creating VMs there's no
actual difference because KVM's limit is currently below the UV's
limit.
Signed-off-by: Janosch Frank
Fixes: a0f60f8431999 ("s390
who caused the exception.
Signed-off-by: Janosch Frank
Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions
handlers")
Cc: sta...@vger.kernel.org
---
arch/s390/mm/fault.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/s390/mm/fault.c b/arch/s
text
Janosch Frank (2):
s390: uv: Fix sysfs max number of VCPUs reporting
s390: mm: Fix secure storage access exception handling
arch/s390/boot/uv.c| 2 +-
arch/s390/include/asm/uv.h | 4 ++--
arch/s390/kernel/uv.c | 2 +-
arch/s390/mm/fault.c | 14 ++
4
On 12/18/20 3:18 PM, Claudio Imbrenda wrote:
> Extend guest_translate to optionally return the address of the guest
> DAT table which caused the exception, and change the return value to int.
>
> Also return the appropriate values in the low order bits of the address
> indicating protection or EDA
On 12/18/20 3:18 PM, Claudio Imbrenda wrote:
> The addresses in the SIE control block of the host should not be
> forwarded to the guest. They are only meaningful to the host, and
> moreover it would be a clear security issue.
>
> Subsequent patches will actually put the right values in the guest
On 1/19/21 11:25 AM, Christian Borntraeger wrote:
>
>
> On 19.01.21 11:04, Janosch Frank wrote:
>> Turns out that the bit 61 in the TEID is not always 1 and if that's
>> the case the address space ID and the address are
>> unpredictable. Without an address an
On 1/19/21 11:11 AM, Christian Borntraeger wrote:
>
>
> On 19.01.21 11:04, Janosch Frank wrote:
>> The number reported by the query is N-1 and I think people reading the
>> sysfs file would expect N instead. For users creating VMs there's no
>> actual difference
is
used like ID and starts at 0. The query field denotes the maximum
number that can be put into the VCPU number field in the "create
secure CPU" UV call.
Signed-off-by: Janosch Frank
Fixes: a0f60f8431999 ("s390/protvirt: Add sysfs firmware interface for
Ultravisor informatio
Two small fixes:
* Handle 3d PGMs where the address space id is not known
* Clean up the UV query VCPU number field naming (it's N-1 not N as number
in this context means ID)
Janosch Frank (2):
s390: uv: Fix sysfs max number of VCPUs reporting
s390: mm: Fix secure storage a
g on who caused the exception.
Signed-off-by: Janosch Frank
Fixes: 084ea4d611a3d ("s390/mm: add (non)secure page access exceptions
handlers")
Cc: sta...@vger.kernel.org
---
arch/s390/mm/fault.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/s390/mm/fault.c b/a
On 9/23/20 2:47 PM, Paolo Bonzini wrote:
> On 22/09/20 03:48, Sean Christopherson wrote:
>> This should be genericized to not be SEV specific. TDX has a similar
>> scarcity issue in the form of key IDs, which IIUC are analogous to SEV ASIDs
>> (gave myself a quick crash course on SEV ASIDs). Func
sometime in the future.
>
> Cc: sta...@vger.kernel.org
> Reviewed-by: David Hildenbrand
> Reviewed-by: Christian Borntraeger
> Signed-off-by: Thomas Huth
Reviewed-by: Janosch Frank
signature.asc
Description: OpenPGP digital signature
Sean Christopherson
Definitely necessary
Reviewed-by: Janosch Frank
> ---
> virt/kvm/kvm_main.c | 40 ++--
> 1 file changed, 18 insertions(+), 22 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ea8f2f37096f
On 9/12/19 11:20 AM, Thomas Huth wrote:
> On 12/09/2019 11.14, David Hildenbrand wrote:
>> On 12.09.19 11:00, Thomas Huth wrote:
>>> When the userspace program runs the KVM_S390_INTERRUPT ioctl to inject
>>> an interrupt, we convert them from the legacy struct kvm_s390_interrupt
>>> to the new stru
On 9/12/19 9:02 AM, Thomas Huth wrote:
> It's not required, so drop it to make it clear that this interrupt
> does not have any extra parameters.
>
> Signed-off-by: Thomas Huth
Well there's no real use for any other parameter than the target cpu, so:
Reviewed-by: Janosch
On 9/11/19 9:52 AM, Igor Mammedov wrote:
> If userspace doesn't set KVM_MEM_LOG_DIRTY_PAGES on memslot before calling
> kvm_s390_vm_start_migration(), kernel will oops with:
>
> Unable to handle kernel pointer dereference in virtual kernel address space
> Failing address: TEID
On 9/4/19 10:51 AM, Thomas Huth wrote:
> Avoid invalid bits in kvm_valid_regs and kvm_dirty_regs on s390x.
>
> v2:
> - Split the single patch from v1 into two separate patches
>(I've kept the Reviewed-bys from v1, but if you don't agree with the
> patch description of the 2nd patch, pleas
checks this), so let's
> do the same on s390x now, too.
>
> Signed-off-by: Thomas Huth
I think it would make sense to split the kvm changes from the test.
Reviewed-by: Janosch Frank
> ---
> arch/s390/include/uapi/asm/kvm.h | 6
> arch/s390/kvm/k
On 8/29/19 2:14 PM, Thomas Huth wrote:
> Check that we can write and read the guest memory with this s390x
> ioctl, and that some error cases are handled correctly.
>
> Signed-off-by: Thomas Huth
> ---
> v2: Check the ioctl also with "size" set to 0
>
[...]
> +
> + /* Zero size: */
> +
gt;ar >= NUM_ACRS)
> return -EINVAL;
>
> if (mop->size > MEM_OP_MAX_SIZE)
>
By the way, I think we want to check mop->size for 0 before giving it to
vmalloc and working with it.
Reviewed-by: Janosch Frank
signature.asc
Description: OpenPGP digital signature
return 0;
> +
> /* copy only the wrapping keys */
> if (read_guest_real(vcpu, crycb_addr + 72,
> vsie_page->crycb.dea_wrapping_key_mask, 56))
>
I seemed to have forgotten to add this while being preoccupied with the
search for the validity discussion in #3.
Reviewed-by: Janosch Frank
signature.asc
Description: OpenPGP digital signature
On 8/23/18 12:25 PM, Pierre Morel wrote:
> Before adapting the CRYCB shadowing for a guest supporting
> the AP instructions we want to clean the CRYCB shadowing code.
>
> First patch seem obvious.
>
> Second patch introduce a change in the behavior of
> the virtual machine in that the CRYCB is va
On 8/23/18 2:03 PM, David Hildenbrand wrote:
> On 23.08.2018 13:53, Janosch Frank wrote:
>> On 8/23/18 1:47 PM, Pierre Morel wrote:
>>> On 23/08/2018 13:33, Janosch Frank wrote:
>>>> On 8/23/18 1:21 PM, David Hildenbrand wrote:
>>>>> On 23.08.2018 13:
On 8/23/18 1:47 PM, Pierre Morel wrote:
> On 23/08/2018 13:33, Janosch Frank wrote:
>> On 8/23/18 1:21 PM, David Hildenbrand wrote:
>>> On 23.08.2018 13:05, Janosch Frank wrote:
>>>> On 8/23/18 12:25 PM, Pierre Morel wrote:
>>>>> The comment preceding
On 8/23/18 1:21 PM, David Hildenbrand wrote:
> On 23.08.2018 13:05, Janosch Frank wrote:
>> On 8/23/18 12:25 PM, Pierre Morel wrote:
>>> The comment preceding the shadow_crycb function is
>>> misleading, we effectively accept FORMAT2 CRYCB in the
>>> gu
On 8/23/18 12:25 PM, Pierre Morel wrote:
> The comment preceding the shadow_crycb function is
> misleading, we effectively accept FORMAT2 CRYCB in the
> guest.
I beg to differ:
if (!(crycbd_o & vcpu->arch.sie_block->crycbd & CRYCB_FORMAT1))
return 0;
>
> When using FORMAT2 in th
On 23.08.2018 10:01, Pierre Morel wrote:
> On 23/08/2018 09:31, David Hildenbrand wrote:
>> On 23.08.2018 09:17, Pierre Morel wrote:
>>> On 22/08/2018 19:15, David Hildenbrand wrote:
On 22.08.2018 18:51, Pierre Morel wrote:
> When entering the SIE the CRYCB validation better
> be done
On 22.08.2018 18:53, David Hildenbrand wrote:
> On 22.08.2018 18:51, Pierre Morel wrote:
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> Reviewed-by: David Hildenbrand
>> ---
>> arch/s390/kvm/vsie.c | 3 ++-
>> 1 file changed, 2 insertions(+)
t AFP is still a thing in zArch mode. I would have
expected it to be a default 1. But then again, I just found out about it.
POP checks out:
Reviewed-by: Janosch Frank
>
> arch/s390/include/asm/ctl_reg.h | 1 +
> arch/s390/kvm/interrupt.c | 8
> 2 files changed, 9 in
s, 0x0035U);
>
> scb_s->ecb3 |= ecb3_flags;
>
Are we able to use offsetof and sizeof here? I'd rather have a few more
characters than magic offsets.
What about CC stable?
Reviewed-by: Janosch Frank
signature.asc
Description: OpenPGP digital signature
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Pierre Morel
> +#define ECA_APIE 0x0008
That shouldn't be necessary, it's defined in kvm_host.h which vsie.c
includes. Or is it not?
> +static int shadow_crycb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page)
> +{
> + struct kvm_s390_si
d is used to set the SIE bit for
>each vcpu during vcpu setup.
>
> Signed-off-by: Tony Krowiak
> Reviewed-by: Halil Pasic
> Acked-by: Christian Borntraeger
> Tested-by: Michael Mueller
> Tested-by: Farhan Ali
> Signed-off-by: Christian Borntraeger
Acked-by: Janosch F
crycb) when re-entering the vSIE
> interception handler the next time.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Janosch Frank
signature.asc
Description: OpenPGP digital signature
and make
> sure to process the updated crycb before reentering the vSIE again.
>
> Signed-off-by: David Hildenbrand
Finally found some time:
Reviewed-by: Janosch Frank
As the first user will be AP, I guess the patches will be queued with
them. Thanks for helping out :)
signature.asc
Description: OpenPGP digital signature
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
The patches are also available on git.kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git/log/?h=ap
signature.asc
Description: OpenPGP digital signature
enbrand
If you make the patch title more specific:
Reviewed-by: Janosch Frank
I considered getting rid of the last unlock with the !large check, but
in theory somebody could run a VM with the HPAGE CAP and 4k pages which
would then result in havoc if we wouldn't also adapt gmap_pmd_op_end.
> -
On 26.06.2018 19:00, Mike Kravetz wrote:
> On 06/26/2018 06:24 AM, Janosch Frank wrote:
>> Use huge_ptep_get to translate huge ptes to normal ptes so we can
>> check them with the huge_pte_* functions. Otherwise some architectures
>> will check the wrong values and will not
Use huge_ptep_get to translate huge ptes to normal ptes so we can
check them with the huge_pte_* functions. Otherwise some architectures
will check the wrong values and will not wait for userspace to bring
in the memory.
Signed-off-by: Janosch Frank
Fixes: 369cd2121be4 ("userfaultfd: huge
On 11.06.2018 13:32, Halil Pasic wrote:
>
>
> On 06/11/2018 11:23 AM, Pierre Morel wrote:
>> On 08/06/2018 23:59, Tony Krowiak wrote:
>>> On 06/07/2018 01:15 PM, Pierre Morel wrote:
>>
>> ...snip...
>>
>>
>>>
>>> Why maintain a list of kvm_ap_matrix structures if we don't have to
On 22.04.2018 17:37, Tony Krowiak wrote:
> Introduces a new function to reset the crypto attributes for all
> vcpus whether they are running or not. Each vcpu in KVM will
> be removed from SIE prior to resetting the crypto attributes in its
> SIE state description. After all vcpus have had their cr
On 20.04.2018 13:59, Janosch Frank wrote:
> Thanks, applied.
>
Well this does not compile, as you use kvm_s390_vcpu_crypto_setup before
declaration. Please fix, then I'll take the patch.
>
> On 19.04.2018 23:13, Tony Krowiak wrote:
>> Introduces a new function to rese
Thanks, applied.
On 19.04.2018 23:13, Tony Krowiak wrote:
> Introduces a new function to reset the crypto attributes for all
> vcpus whether they are running or not. Each vcpu in KVM will
> be removed from SIE prior to resetting the crypto attributes in its
> SIE state description. After all vcpu
54 matches
Mail list logo
