On 16.08.2017 21:40, Radim Krčmář wrote:
> The goal is to increase KVM_MAX_VCPUS without worrying about memory
> impact of many small guests.
>
> This is a second out of three major "dynamic" options:
> 1) size vcpu array at VM creation time
> 2) resize vcpu array when new VCPUs are created
> 3
_RETRY))
> - return 1;
> + ret = kvm_mmu_page_fault(vcpu, gpa, PFERR_RSVD_MASK, NULL, 0);
> + if (ret >= 0)
> + return ret;
>
> /* It is the real ept misconfig */
> WARN_ON(1);
>
Reviewed-by: David Hildenbrand
--
Thanks,
David
On 11.08.2017 18:52, Paolo Bonzini wrote:
> From: Brijesh Singh
>
> When a guest causes a page fault which requires emulation, the
> vcpu->arch.gpa_available flag is set to indicate that cr2 contains a
> valid GPA.
>
> Currently, emulator_read_write_onepage() makes use of gpa_available flag
> to
On 11.08.2017 18:52, Paolo Bonzini wrote:
> Calling handle_mmio_page_fault() has been unnecessary since commit
> e9ee956e311d ("KVM: x86: MMU: Move handle_mmio_page_fault() call to
> kvm_mmu_page_fault()", 2016-02-22)
>
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/vmx.c | 13 +++--
On 11.08.2017 18:52, Paolo Bonzini wrote:
> There is currently some confusion between nested and L1 GPAs. The
> assignment to "direct" in kvm_mmu_page_fault tries to fix that, but
> it is not enough. What this patch does is fence off the MMIO cache
> completely when using shadow nested page table
On 16.08.2017 14:07, Radim Krčmář wrote:
> 2017-08-16 13:22+0200, Paolo Bonzini:
>> Microsoft pointed out privately to me that KVM's handling of
>> KVM_FAST_MMIO_BUS is invalid. Using skip_emulation_instruction is invalid
>> in EPT misconfiguration vmexit handlers, because neither EPT violations
>
On 17.08.2017 11:44, Paolo Bonzini wrote:
> On 17/08/2017 11:28, Cornelia Huck wrote:
>> On Thu, 17 Aug 2017 11:16:59 +0200
>> Paolo Bonzini wrote:
>>
>>> On 17/08/2017 09:36, Cornelia Huck wrote:
> What if we just sent a "vcpu move" request to all vcpus with the new
> pointer after it mo
On 17.08.2017 12:18, Paolo Bonzini wrote:
> On 17/08/2017 11:55, David Hildenbrand wrote:
>> On 17.08.2017 11:44, Paolo Bonzini wrote:
>>> On 17/08/2017 11:28, Cornelia Huck wrote:
>>>> On Thu, 17 Aug 2017 11:16:59 +0200
>>>> Paolo Bonzini wrote:
>
On 17.08.2017 12:23, Paolo Bonzini wrote:
> On 17/08/2017 12:20, David Hildenbrand wrote:
>> On 17.08.2017 12:18, Paolo Bonzini wrote:
>>> On 17/08/2017 11:55, David Hildenbrand wrote:
>>>> On 17.08.2017 11:44, Paolo Bonzini wrote:
>>>>> On 17/08/2017
> atomic_set(&kvm->online_vcpus, 0);
> mutex_unlock(&kvm->lock);
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index c8df733eed41..eb9fb5b493ac 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -386,12 +386,17 @@ struct kvm_memslots {
>
> Signed-off-by: Paolo Bonzini
> ---
> v1->v2: make the function static.
>
> arch/x86/kvm/mmu.c | 19 ++-
> arch/x86/kvm/mmu.h | 17 -
> arch/x86/kvm/vmx.c | 13 +++--
> 3 files changed, 21 insertions(+), 28 dele
exception, write);
> -
> if (ret < 0)
> return X86EMUL_PROPAGATE_FAULT;
just wondering if it makes sense to move this into the else branch (as
it logically only belongs to vcpu_mmio_gva_to_gpa)
Reviewed-by: David Hildenbrand
--
Thanks,
David
; {
> - vcpu->arch.mmio_gva = gva & PAGE_MASK;
> + /*
> + * If this is a shadow nested page table, the "GVA" is
s/"GVA"/GVA/ ?
> + * actually a nGPA.
> + */
> + vcpu->arch.mmio_gva = mmu_is_nested(vcpu) ? 0 : gva & PAGE_MASK;
> vcpu->arch.access = access;
> vcpu->arch.mmio_gfn = gfn;
> vcpu->arch.mmio_gen = kvm_memslots(vcpu->kvm)->generation;
>
Reviewed-by: David Hildenbrand
--
Thanks,
David
On 20.06.2017 18:44, Rik van Riel wrote:
> On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote:
>
>> The hypervisor is going to throw away the contents of these pages,
>> right? As soon as the spinlock is released, someone can allocate a
>> page, and put good data in it. What keeps the hypervis
On 20.06.2017 20:17, Michael S. Tsirkin wrote:
> On Tue, Jun 20, 2017 at 06:49:33PM +0200, David Hildenbrand wrote:
>> On 20.06.2017 18:44, Rik van Riel wrote:
>>> On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote:
>>>
>>>> The hypervisor is going to
>> IMHO even simply writing all-zeros to all free pages before starting
>> migration (or even when freeing a page) would be a cleaner interface
>> than this (because it atomically works with the entity the host cares
>> about for migration). But yes, performance is horrible that's why I am
>> not
On 21.06.2017 14:56, Christian Borntraeger wrote:
> On 06/20/2017 06:49 PM, David Hildenbrand wrote:
>> On 20.06.2017 18:44, Rik van Riel wrote:
>>> On Mon, 2017-06-12 at 07:10 -0700, Dave Hansen wrote:
>>>
>>>> The hypervisor is going to throw away the c
o not break some legacy/other user space doing
this in a different order, this will have to be enabled explicitly by
the caller. So the vm.alloc_pgste option has to stay.
Signed-off-by: David Hildenbrand
---
arch/s390/include/asm/pgtable.h | 15 +--
arch/s390/kvm/kvm-s390.c| 4 +--
emory regions
- Do all such mmap calls after the VM was created.
If user space fails to obey these rules, KVM will report -EFAULT
whenever an address in that incompatible range is accessed.
Signed-off-by: David Hildenbrand
---
Documentation/virtual/kvm/api.txt | 13 +
arch/s390/kvm/kvm-s
really a problem).
Only very quickly tested under KVM on z/VM. Will do some more testing if
this idea is worth working on.
Based on linux-next.git/master
David Hildenbrand (2):
s390x: mm: allow mixed page table types (2k and 4k)
KVM: s390: Introduce KVM_VM_S390_LATE_MMAP
Documentation/virtual
On 23.10.2017 16:15, Paolo Bonzini wrote:
> On 23/10/2017 14:39, Cornelia Huck wrote:
>> On Mon, 23 Oct 2017 11:52:51 +0200
>> David Hildenbrand wrote:
>>
>>> On 21.10.2017 01:25, Paolo Bonzini wrote:
>>>> Two KVM ioctls (KVM_GET/SET_CPUID2) directly acc
return 1;
> + vcpu->arch.pat = data;
> + svm->vmcb->save.g_pat = data;
> + mark_dirty(svm->vmcb, VMCB_NPT);
> + break;
> case MSR_IA32_TSC:
> kvm_write_tsc(vcpu, msr);
> break;
>
Although no SVM expert, looking at the way it is handled on VMX, this
looks good to me.
Reviewed-by: David Hildenbrand
--
Thanks,
David
On 13.11.2017 01:33, Wanpeng Li wrote:
> From: Wanpeng Li
>
> This patch reuses the preempted field in kvm_steal_time, and will export
> the vcpu running/pre-empted information to the guest from host. This will
> enable guest to intelligently send ipi to running vcpus and set flag for
> pre-empte
On 14.11.2017 06:12, Rik van Riel wrote:
> Currently, every time a VCPU is scheduled out, the host kernel will
> first save the guest FPU/xstate context, then load the qemu userspace
> FPU context, only to then immediately save the qemu userspace FPU
> context back to memory. When scheduling in a V
On 14.11.2017 19:07, Rik van Riel wrote:
> On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote:
>>
>>> diff --git a/arch/x86/include/asm/kvm_host.h
>>> b/arch/x86/include/asm/kvm_host.h
>>> index c73e493adf07..92e66685249e 100644
>>> --- a/arch/
ption would still be needed.
So all I can offer for now is the following (untested, can send as
proper patch if needed):
>From f32d06c8c621c6d68e073e9bdb81a6280b6c9544 Mon Sep 17 00:00:00 2001
From: David Hildenbrand
Date: Mon, 6 Nov 2017 12:35:39 +0100
Subject: [PATCH v1] KVM: x86: fix em_fxs
{
> shadow_user_mask = 0;
> shadow_accessed_mask = 0;
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
> On Nov 6, 2017 3:52 AM, "David Hildenbrand" <mailto:da...@redhat.com>> wrote:
>
> On 31.10.2017 12:34, syzbot wrote:
> > Hello,
> >
> > syzkaller hit the following crash on
> > 91dfed74eabcdae9378131546c446442c29bf769
>
On 06.11.2017 17:14, Paolo Bonzini wrote:
> On 06/11/2017 17:01, David Hildenbrand wrote:
>> On 06.11.2017 16:10, Nick Desaulniers wrote:
>>> Does it have to be stack allocated?
>>
>> We can't use kmalloc and friends in emulate.c. We would have to
>> intro
On 06.11.2017 17:37, Paolo Bonzini wrote:
> On 06/11/2017 17:19, David Hildenbrand wrote:
>> On 06.11.2017 17:14, Paolo Bonzini wrote:
>>> On 06/11/2017 17:01, David Hildenbrand wrote:
>>>> On 06.11.2017 16:10, Nick Desaulniers wrote:
>>>>> Does it h
ontrols =
> + VMX_VMFUNC_EPTP_SWITCHING;
> }
>
> /*
>
I think we talked about how that cannot happen. But you observe it, so
it seems to happen :)
Reviewed-by: David Hildenbrand
--
Thanks,
David
es are not allowed.
gmap_protect_range() is called quite frequently for managing shadow
page tables in vSIE environments.
Signed-off-by: David Hildenbrand
---
arch/s390/mm/gmap.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gm
On 07.08.2018 09:26, Janosch Frank wrote:
> On 06.08.2018 17:54, David Hildenbrand wrote:
>> Right now we temporarily take the page table lock in gmap_pmd_op_walk()
>> even though we know we won't need it (if we can never have 1mb pages
>> mapped into the gmap).
>&g
the
(v)SIE again).
The request will make sure that the vSIE handler is left, and that the
request will be processed (NOP), therefore forcing a reload of all
vSIE data (including rebuilding the crycb) when re-entering the vSIE
interception handler the next time.
Signed-off-by: David Hildenbrand
the crycb of the VCPU and make sure that any
masks also get applied to the VSIE crycb shadow (which uses masks from the
VCPU crycb), we will need a way to hinder the vSIE from running and make
sure to process the updated crycb before reentering the vSIE again.
Signed-off-by: David Hildenbrand
---
support blocking and also synchronous CPU requests.
Only compile tested.
David Hildenbrand (2):
KVM: s390: vsie: simulate VCPU SIE entry/exit
KVM: s390: introduce and use KVM_REQ_VSIE_RESTART
arch/s390/include/asm/kvm_host.h | 1 +
arch/s390/kvm/kvm-s390.c | 16 ++--
arch
On 07.08.2018 15:37, osalva...@techadventures.net wrote:
> From: Oscar Salvador
>
> This tries to fix [1], which was reported by David Hildenbrand, and also
> does some cleanups/refactoring.
>
> I am sending this as RFC to see if the direction I am going is right before
&g
On 07.08.2018 16:19, Oscar Salvador wrote:
> On Tue, Aug 07, 2018 at 04:16:35PM +0200, David Hildenbrand wrote:
>> On 07.08.2018 15:37, osalva...@techadventures.net wrote:
>>> From: Oscar Salvador
>>>
>>> This tries to fix [1], which was reported by David
On 07.08.2018 16:28, Oscar Salvador wrote:
> On Tue, Aug 07, 2018 at 04:20:37PM +0200, David Hildenbrand wrote:
>> On 07.08.2018 16:19, Oscar Salvador wrote:
>>> On Tue, Aug 07, 2018 at 04:16:35PM +0200, David Hildenbrand wrote:
>>>> On 07.08.2018 15:37, osal
On 07.08.2018 15:52, Jerome Glisse wrote:
> On Tue, Aug 07, 2018 at 03:37:56PM +0200, osalva...@techadventures.net wrote:
>> From: Oscar Salvador
>
> [...]
>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 9bd629944c91..e33555651e46 100644
>> --- a/mm/memory_hotplug.c
>> +++ b
On 07.08.2018 17:19, Jerome Glisse wrote:
> On Tue, Aug 07, 2018 at 04:54:57PM +0200, David Hildenbrand wrote:
>> On 07.08.2018 15:52, Jerome Glisse wrote:
>>> On Tue, Aug 07, 2018 at 03:37:56PM +0200, osalva...@techadventures.net
>>> wrote:
>>>> From: Osca
On 07.08.2018 19:15, Pierre Morel wrote:
> On 07/08/2018 14:51, David Hildenbrand wrote:
>> While discussing AP changes, we discovered that we will have to force
>> a CPU using the vSIE to regenerate/reload shadow data structures. For now,
>> we have no mechanism for that.
>
On 08.08.2018 09:38, Oscar Salvador wrote:
> On Tue, Aug 07, 2018 at 06:13:45PM -0400, Jerome Glisse wrote:
>>> And since we know for sure that memhotplug-code cannot call it with
>>> ZONE_DEVICE,
>>> I think this can be done easily.
>>
>> This might change down road but for now this is correct. T
On 08.08.2018 09:38, Oscar Salvador wrote:
> On Tue, Aug 07, 2018 at 06:13:45PM -0400, Jerome Glisse wrote:
>>> And since we know for sure that memhotplug-code cannot call it with
>>> ZONE_DEVICE,
>>> I think this can be done easily.
>>
>> This might change down road but for now this is correct. T
On 21.08.2018 12:44, David Hildenbrand wrote:
> This is the same approach as in the first RFC, but this time without
> exporting device_hotplug_lock (requested by Greg) and with some more
> details and documentation regarding locking. Tested only on x86 so far.
>
I'll be on
On 27.08.2018 14:47, Li Qiang wrote:
> Free the vdev->msi_perm in error path.
>
> Signed-off-by: Li Qiang
> ---
> drivers/vfio/pci/vfio_pci_config.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_config.c
> b/drivers/vfio/pci/vfio_pci_conf
On 08.08.2018 09:56, Oscar Salvador wrote:
> On Wed, Aug 08, 2018 at 09:45:37AM +0200, David Hildenbrand wrote:
>> On 08.08.2018 09:38, Oscar Salvador wrote:
>>> On Tue, Aug 07, 2018 at 06:13:45PM -0400, Jerome Glisse wrote:
>>>>> And since we know for sure that me
On 08.08.2018 14:47, Cornelia Huck wrote:
> On Tue, 7 Aug 2018 14:51:31 +0200
> David Hildenbrand wrote:
>
>> When we change the crycb (or execution controls), we also have to make sure
>> that the vSIE shadow datastructures properly consider the changed
>> values be
On 07.08.2018 14:51, David Hildenbrand wrote:
> VCPU requests and VCPU blocking right now don't take care of the vSIE
> (as it was not necessary until now). But we want to have VCPU requests
> that will also be handled before running the vSIE again.
>
> So let's simulate
erre Morel
Reviewed-by: Cornelia Huck
Reviewed-by: Janosch Frank
Signed-off-by: David Hildenbrand
---
arch/s390/kvm/kvm-s390.c | 9 -
arch/s390/kvm/kvm-s390.h | 1 +
arch/s390/kvm/vsie.c | 21 +
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arc
-by: Cornelia Huck
Reviewed-by: Janosch Frank
Signed-off-by: David Hildenbrand
---
arch/s390/include/asm/kvm_host.h | 1 +
arch/s390/kvm/kvm-s390.c | 7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h
way, we can support blocking and also synchronous CPU requests.
Only compile tested.
RFC -> v1:
- Move entry/exit simulation right to the sie64 code to minimize latency
- Added R-b's, dropped Tested-by.
David Hildenbrand (2):
KVM: s390: vsie: simulate VCPU SIE entry/exit
KVM: s390: i
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Pierre Morel
>
> When we clear the Crypto Control Block (CRYCB) used by a guest
> level 2, the vSIE shadow CRYCB for guest level 3 must be updated
> before the guest uses it.
>
> We achieve this by using the KVM_REQ_VSIE_RESTART synchronous
> requ
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Introduces a new CPU model feature and two CPU model
> facilities to support AP virtualization for KVM guests.
>
> CPU model feature:
>
> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
> AP instructions are available on the g
On 08.08.2018 16:44, Tony Krowiak wrote:
> From: Tony Krowiak
>
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
>
> 1. Prior to the introduction of AP device virtualization, it
>was n
return -EINVAL;
>
> - return remove_memory_section(0, section, 0);
> + return remove_memory_section(section);
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 13.08.2018 17:46, osalva...@techadventures.net wrote:
> From: Oscar Salvador
>
> Before calling to unregister_mem_sect_under_nodes(),
> remove_memory_section() already checks if we got a valid
> memory_block.
>
> No need to check that again in unregister_mem_sect_under_nodes().
>
> Signed-of
On 13.08.2018 17:46, osalva...@techadventures.net wrote:
> From: Oscar Salvador
>
> unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
> in order to check whithin the loop which nodes have already been unlinked,
> so we do not repeat the operation on them.
>
> NODEMASK_ALLOC calls
On 14.08.2018 11:36, Oscar Salvador wrote:
> On Tue, Aug 14, 2018 at 11:30:51AM +0200, David Hildenbrand wrote:
>
>>
>> While it is correct in current code, I wonder if this sanity check
>> should stay. I would completely agree if it would be a static function.
On 14.08.2018 12:06, Oscar Salvador wrote:
> On Tue, Aug 14, 2018 at 11:44:50AM +0200, David Hildenbrand wrote:
>>
>> Yes I know, as I said, if it would be local to a file I would not care.
>> Making this functions never return an error is nice, though (and as you
>>
facility_def {
>
> .name = "FACILITIES_KVM_CPUMODEL",
> .bits = (int[]){
> + 12, /* AP Query Configuration Information */
> + 15, /* AP Facilities Test */
> -1 /* END */
> }
> },
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 13.08.2018 23:48, Tony Krowiak wrote:
> From: Pierre Morel
>
> Shadowing the crypto control block now supports APCB shadowing.
>
> AP instruction interpretation for guest 3 through ECA.28 is shadowed when
> guest 2 ECA.28 is set.
>
> CRYCB is shadowed for APCB and wrapping keys.
>
> CRYCB f
device_online() should be called with device_hotplug_lock() held.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Rashmica Gupta
Cc: Balbir Singh
Cc: Michael Neuling
Signed-off-by: David Hildenbrand
---
arch/powerpc/platforms/powernv/memtrace.c | 2 ++
1 file
atches a bit.
- Try to improve powernv memtrace locking
- Add some documentation for locking that matches my knowledge
David Hildenbrand (6):
mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
mm/memory_hotplug: make add_memory() take the device_hotplug_lock
mm/memory_hot
> add_device_memory is in charge of
I wouldn't use the terminology of onlining/offlining here. That applies
rather to memory that is exposed to the rest of the system (e.g. buddy
allocator, has underlying memory block devices). I guess it is rather a
pure setup/teardown of that device memory.
>
On 21.08.2018 16:19, Pierre Morel wrote:
> Copy the key mask to the right offset inside the shadow CRYCB
"KVM: s390: vsie: copy wrapping keys to right place"
Indeed, we're writing it into the apcb0 mask (which is ignored).
Luckily, the xor-ing with the g2 keys seems to work.
On 21.08.2018 16:33, Cornelia Huck wrote:
> On Tue, 21 Aug 2018 16:19:38 +0200
> Pierre Morel wrote:
>
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> ---
>> arch/s390/kvm/vsie.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
On 21.08.2018 16:43, Janosch Frank wrote:
> On 21.08.2018 16:19, Pierre Morel wrote:
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> ---
>> arch/s390/kvm/vsie.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch
On 22.08.2018 09:50, Oscar Salvador wrote:
> On Tue, Aug 21, 2018 at 03:17:10PM +0200, David Hildenbrand wrote:
>>> add_device_memory is in charge of
>>
>> I wouldn't use the terminology of onlining/offlining here. That applies
>> rather to memory that is exp
On 22.08.2018 10:08, Pierre Morel wrote:
> Currently when shadowing the CRYCB on SIE entrance, the validation
> tests the following:
> - accept only FORMAT1 or FORMAT2
> - test if MSAext facility (76) is installed
> - accept the CRYCB if no keys are used
> - verifies that the CRYCB format1 is insid
On 22.08.2018 10:41, Pierre Morel wrote:
> On 22/08/2018 10:25, David Hildenbrand wrote:
>> On 22.08.2018 10:08, Pierre Morel wrote:
>>> Currently when shadowing the CRYCB on SIE entrance, the validation
>>> tests the following:
>>> - accept only FORMAT1 or F
debugging the
guest (concurrent PER events result in an intercept instead of an
injection of such interrupts).
Signed-off-by: David Hildenbrand
---
Only compile-tested.
arch/s390/include/asm/ctl_reg.h | 1 +
arch/s390/kvm/interrupt.c | 8
2 files changed, 9 insertions(+)
diff --git a
On 22.08.2018 12:42, Pierre Morel wrote:
> On 22/08/2018 10:44, David Hildenbrand wrote:
>> On 22.08.2018 10:41, Pierre Morel wrote:
>>> On 22/08/2018 10:25, David Hildenbrand wrote:
>>>> On 22.08.2018 10:08, Pierre Morel wrote:
>>>>> Currently
On 22.08.2018 12:31, Janosch Frank wrote:
> On 22.08.2018 11:53, David Hildenbrand wrote:
>> When DATA exceptions and vector-processing exceptions (program interrupts)
>> are injected, the DXC/VXC is also to be stored in the fpc, if AFP is
>> enabled in CR0.
>>
>>
On 13.08.2018 23:48, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Introduces a new CPU model feature and two CPU model
> facilities to support AP virtualization for KVM guests.
>
> CPU model feature:
>
> The KVM_S390_VM_CPU_FEAT_AP feature indicates that
> AP instructions are available on the g
On 22.08.2018 13:19, David Hildenbrand wrote:
> On 13.08.2018 23:48, Tony Krowiak wrote:
>> From: Tony Krowiak
>>
>> Introduces a new CPU model feature and two CPU model
>> facilities to support AP virtualization for KVM guests.
>>
>> CPU model feature:
&g
/
> - if (maxphyaddr == 52)
> + if (IS_ENABLED(CONFIG_X86_64) && maxphyaddr == 52)
> mask &= ~1ull;
> -#endif
>
> kvm_mmu_set_mmio_spte_mask(mask, mask);
> }
>
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
>>
>>> From the host, we control the guest1 and we start it without AP
>>> by not setting ECA.28.
>>> So that the guest1 can not know if APXA is installed or not since to know
>>> this it must use a AP instruction :)
>> No AP implies no APXA. On that logical level "host".
>
> hum.
> No seen, usab
On 22.08.2018 16:33, Pierre Morel wrote:
> On 22/08/2018 13:19, David Hildenbrand wrote:
>> On 13.08.2018 23:48, Tony Krowiak wrote:
>>> From: Tony Krowiak
>>>
>>> Introduces a new CPU model feature and two CPU model
>>> facilities to support AP vir
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(+), 1 deletion(-)
>
>
On 22.08.2018 18:51, Pierre Morel wrote:
> As the comment above the function suggested the shadowing
> of the guest2 CRYCB can only accept a format 1 since
> AP instructions are not supported in the guest.
>
> Let's modify the check which allowed to accept a format 2 too.
As the bit is ignored wi
>>>
>>> In this case we will have no problem with older guests not having idea
>>> about APXA.
>>>
>>> Would it be a solution?
>>
>> Any feature the guest sees, should be part of the CPU model. The whole
>> environment for cpu subfunctions is already in place both in KVM and
>> QEMU. Only disabli
On 22.08.2018 18:51, Pierre Morel wrote:
> Currently the CRYCB format used in the host for the
> shadowed CRYCB is FORMAT2 while no check is done if
> AP instructions are supported in the host.
>
> We better use the format the host calculated for the
> guest 1 as the host already tested it against
On 22.08.2018 18:51, Pierre Morel wrote:
> BUG: the crycbd must be tested for null even if
> not crossing a page boundary (which will never
> occur in this case anyway).
I don't see the BUG. Can you elaborate? (maybe it is too late for me)
Either we return or we check for !crycb_addr
>
> Signed
On 22.08.2018 18:51, Pierre Morel wrote:
> When entering the SIE the CRYCB validation better
> be done independently of the instruction's
> availability.
>
> Signed-off-by: Pierre Morel
> ---
> arch/s390/kvm/vsie.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --g
On 23.08.2018 08:44, Pierre Morel wrote:
> On 22/08/2018 19:06, David Hildenbrand wrote:
>> On 22.08.2018 18:51, Pierre Morel wrote:
>>> Currently the CRYCB format used in the host for the
>>> shadowed CRYCB is FORMAT2 while no check is done if
>>> AP in
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 independently of the instruction's
>>> availabi
On 22.08.2018 23:05, Tony Krowiak wrote:
> On 08/22/2018 12:57 PM, David Hildenbrand wrote:
>>>>> In this case we will have no problem with older guests not having idea
>>>>> about APXA.
>>>>>
>>>>> Would it be a solution?
>>>
On 22.08.2018 22:16, Tony Krowiak wrote:
> On 08/22/2018 07:24 AM, David Hildenbrand wrote:
>> On 22.08.2018 13:19, David Hildenbrand wrote:
>>> On 13.08.2018 23:48, Tony Krowiak wrote:
>>>> From: Tony Krowiak
>>>>
>>>> Introduces a new
>>>
>> I really wonder if we should also export the APXA facility.
>
> Given this comment is made within the context of the
> FACILITIES_KVM_CPUMODEL I might point out that APXA is not
> indicated by a facilities bit. It is indicated by a bit in
> the QCI control block returned from the PQAP(QCI)
On 23.08.2018 10:34, Janosch Frank wrote:
> 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
On 23.08.2018 12:00, Halil Pasic wrote:
>
>
> On 08/23/2018 09:44 AM, David Hildenbrand wrote:
>> On 22.08.2018 22:16, Tony Krowiak wrote:
>>> On 08/22/2018 07:24 AM, David Hildenbrand wrote:
>>>> On 22.08.2018 13:19, David Hildenbrand wrote:
>>&
On 23.08.2018 13:10, Pierre Morel wrote:
> On 23/08/2018 12:28, David Hildenbrand wrote:
>> On 23.08.2018 12:00, Halil Pasic wrote:
>>>
>>>
>>> On 08/23/2018 09:44 AM, David Hildenbrand wrote:
>>>> On 22.08.2018 22:16, Tony Krowiak wrote:
>&
e need to handle the validity checks for the crycb, no matter what the
> settings for the keywrappings are. So lets move the keywrapping checks
> after we have done the validy checks.
>
> ?
With that
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
On 23.08.2018 13:07, Christian Borntraeger wrote:
>
>
> On 08/23/2018 12:25 PM, Pierre Morel wrote:
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> Reviewed-by: David Hildenbrand
>> Reviewed-by: Corne
vsie_page->crycb) | CRYCB_FORMAT1 |
>> -CRYCB_FORMAT2;
>> +scb_s->crycbd = ((__u32)(__u64) &vsie_page->crycb) | CRYCB_FORMAT2;
>
> That's purely cosmetic but valid.
>
>>
>> /* xor both blocks in one run */
>> b1 = (unsigned long *) vsie_page->crycb.dea_wrapping_key_mask;
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
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:05, Janosch Frank wrote:
>>>>> On 8/23/18 12:
On 23.08.2018 15:12, Christian Borntraeger wrote:
>
>
> On 08/23/2018 12:25 PM, Pierre Morel wrote:
>> Copy the key mask to the right offset inside the shadow CRYCB
>>
>> Signed-off-by: Pierre Morel
>> Reviewed-by: David Hildenbrand
>> Reviewed-by: Corne
On 23.08.2018 15:22, Halil Pasic wrote:
>
>
> On 08/23/2018 02:47 PM, Pierre Morel wrote:
>> On 23/08/2018 13:12, David Hildenbrand wrote:
> [..]
>>>>>>
>>>>>> I'm confused, which 128 bit?
>>>>>
>>>>>
>&g
On 23.08.2018 19:35, Tony Krowiak wrote:
> On 08/23/2018 10:59 AM, Pierre Morel wrote:
>> On 23/08/2018 15:38, David Hildenbrand wrote:
>>> On 23.08.2018 15:22, Halil Pasic wrote:
>>>>
>>>>
>>>> On 08/23/2018 02:47 PM, Pierre Morel wro
1 - 100 of 3163 matches
Mail list logo
