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,
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
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
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
da
> ---
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
applies 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
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
>
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/protvirt: Add
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/s390/mm/fau
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 files
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
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 and it'
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 becau
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 information")
Cc: st
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 access
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/s390/mm/fau
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).
time 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
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..830
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
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 Frank
&
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:
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,
ftest 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/kvm-s3
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: */
> +
_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
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
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
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 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: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
>&
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
>&
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
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
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 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
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
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
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
5U);
>
> 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
5U);
>
> 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
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
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
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
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
> 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
> 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
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
u 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.
> ---
> arch/s390/m
u 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.
> ---
> arch/s390/m
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 n
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 n
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
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
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
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
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
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 reset the
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 reset the
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
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
74 matches
Mail list logo
