[PATCH] KVM: arm64: vgic-its: Fix wrong return value check in vgic_its_restore_device_tables

scan_its_table() return 1 on success. In the function vgic_its_restore_device_tables() the return value of scan_its_table() is checked against success value and returns -EINVAL. Hence migration fails for VM with ITS. With this patch the failure return value is checked while returning -EINVAL.

Re: [PATCH] KVM: arm64: vgic-its: Fix wrong return value check in vgic_its_restore_device_tables

Hi Vijaya, On 06/09/2017 07:26, Vijaya Kumar K wrote: > scan_its_table() return 1 on success. As mentioned in the kernel-doc comment of scan_its_table, this latter returns 1 if the last element is not found. Than can happen while scanning an L2 table but shouldn't happen if we scan an L1 table.

Re: [PATCH v3 51/59] KVM: arm/arm64: GICv4: Add doorbell interrupt handling

On 2017/8/1 1:26, Marc Zyngier wrote: > When a vPE is not running, a VLPI being made pending results in a > doorbell interrupt being delivered. Let's handle this interrupt > and update the pending_last flag that indicates that VLPIs are > pending. The corresponding vcpu is also kicked into

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 10:32, gengdongjiu wrote: > Hi Marc, > > On 2017/9/6 16:17, Marc Zyngier wrote: >> On 05/09/17 19:58, gengdongjiu wrote: >>> when exit from guest, some host PSTATE bits may be lost, such as >>> PSTATE.PAN or PSTATE.UAO. It is because host and hypervisor all run >>> in the EL2, host

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

Hi Marc, On 2017/9/6 16:17, Marc Zyngier wrote: > On 05/09/17 19:58, gengdongjiu wrote: >> when exit from guest, some host PSTATE bits may be lost, such as >> PSTATE.PAN or PSTATE.UAO. It is because host and hypervisor all run >> in the EL2, host PSTATE value cannot be saved and restored via >>

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 05/09/17 19:58, gengdongjiu wrote: > when exit from guest, some host PSTATE bits may be lost, such as > PSTATE.PAN or PSTATE.UAO. It is because host and hypervisor all run > in the EL2, host PSTATE value cannot be saved and restored via > SPSR_EL2. So if guest has changed the PSTATE, host

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

For UAO, if not save/restore PSTATE.UAO, we can use below fixing. diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c index 9341376..c3dd761 100644 --- a/arch/arm64/kvm/hyp/sysreg-sr.c +++ b/arch/arm64/kvm/hyp/sysreg-sr.c @@ -21,6 +21,8 @@ #include #include +#include

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 2017/9/6 20:00, Vladimir Murzin wrote: > On 06/09/17 11:35, gengdongjiu wrote: >> Vladimir, >> >> On 2017/9/6 17:41, Vladimir Murzin wrote: >>> Can you please elaborate on cases where PAN is not enabled? >> >> I mean the informal private usage, For example, he disabled the PAN >> dynamically

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 13:14, gengdongjiu wrote: > > > On 2017/9/6 20:00, Vladimir Murzin wrote: >> On 06/09/17 11:35, gengdongjiu wrote: >>> Vladimir, >>> >>> On 2017/9/6 17:41, Vladimir Murzin wrote: Can you please elaborate on cases where PAN is not enabled? >>> >>> I mean the informal private

Re: [PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

On 28 August 2017 at 11:38, Dongjiu Geng wrote: > In the firmware-first RAS solution, corrupt data is detected in a > memory location when guest OS application software executing at EL0 > or guest OS kernel El1 software are reading from the memory. The > memory node

Re: [PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

Hi Peter, On 2017/9/6 19:19, Peter Maydell wrote: > On 28 August 2017 at 11:38, Dongjiu Geng wrote: >> In the firmware-first RAS solution, corrupt data is detected in a >> memory location when guest OS application software executing at EL0 >> or guest OS kernel El1

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 2017/9/6 20:00, Vladimir Murzin wrote: > On 06/09/17 11:35, gengdongjiu wrote: >> Vladimir, >> >> On 2017/9/6 17:41, Vladimir Murzin wrote: >>> Can you please elaborate on cases where PAN is not enabled? >> >> I mean the informal private usage, For example, he disabled the PAN >> dynamically

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

Vladimir, On 2017/9/6 17:41, Vladimir Murzin wrote: > Can you please elaborate on cases where PAN is not enabled? I mean the informal private usage, For example, he disabled the PAN dynamically to let kernel space to access the user space. After he dynamic disabled the PAN, then switched to

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 11:35, gengdongjiu wrote: > Vladimir, > > On 2017/9/6 17:41, Vladimir Murzin wrote: >> Can you please elaborate on cases where PAN is not enabled? > > I mean the informal private usage, For example, he disabled the PAN > dynamically to let kernel space to access the user space. >

[PATCH v3 3/5] KVM: arm/arm64: vgic: Support level-triggered mapped interrupts

Level-triggered mapped IRQs are special because we only observe rising edges as input to the VGIC, and we don't set the EOI flag and therefore are not told when the level goes down, so that we can re-queue a new interrupt when the level goes up. One way to solve this problem is to side-step the

[PATCH v3 5/5] KVM: arm/arm64: Provide a vgic interrupt line level sample function

The GIC sometimes need to sample the physical line of a mapped interrupt. As we know this to be notoriously slow, provide a callback function for devices (such as the timer) which can do this much faster than talking to the distributor, for example by comparing a few in-memory values. Fall back

[PATCH v3 2/5] KVM: arm/arm64: vgic: restructure kvm_vgic_(un)map_phys_irq

From: Eric Auger We want to reuse the core of the map/unmap functions for IRQ forwarding. Let's move the computation of the hwirq in kvm_vgic_map_phys_irq and pass the linux IRQ as parameter. The host_irq is added to struct vgic_irq because it is needed in later patches

[PATCH v3 0/5] Handle forwarded level-triggered interrupts

This series illustrates an alternative approach to Eric Auger's direct EOI setup patches [1] in terms of the KVM VGIC support. The idea is to maintain existing semantics for the VGIC for mapped level-triggered IRQs and think support for the timer into it. Patch 1 is necessary to align the timer

[PATCH v3 1/5] KVM: arm/arm64: Don't cache the timer IRQ level

The timer was modeled after a strict idea of modelling an interrupt line level in software, meaning that only transitions in the level needed to be reported to the VGIC. This works well for the timer, because the arch timer code is in complete control of the device and can track the transitions

[RFC PATCH 1/3] kvm: arm/arm64: vgic-vits: separate vgic_its_free_list() function

We slightly refactor vgic_its_destroy, separate vgic_its_free_list() function for later patch invoke. The patch also take a functional change. If the its->device_list.next is NULL, we still should free the its. Honestly, I can't understand How does the its->device_list.next is NULL happened at

[RFC PATCH 2/3] kvm: arm/arm64: vgic-vits: free its resource when vm reboot/reset

This patch fix the migrate save tables failure. When the virtual machine is in booting and the devices haven't initialized, the all virtual dte/ite may be invalid. If migrate at this moment, the save tables interface traversal device list, and check the dte is valid or not. if not, it will return

Re: [PATCH] KVM: arm64: vgic-its: Fix wrong return value check in vgic_its_restore_device_tables

On 2017/9/6 15:22, Auger Eric wrote: > Hi Vijaya, > > On 06/09/2017 07:26, Vijaya Kumar K wrote: >> scan_its_table() return 1 on success. > > As mentioned in the kernel-doc comment of scan_its_table, this latter > returns 1 if the last element is not found. Than can happen while > scanning an

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 2017/9/6 20:30, Vladimir Murzin wrote: > On 06/09/17 13:14, gengdongjiu wrote: >> >> >> On 2017/9/6 20:00, Vladimir Murzin wrote: >>> On 06/09/17 11:35, gengdongjiu wrote: Vladimir, On 2017/9/6 17:41, Vladimir Murzin wrote: > Can you please elaborate on cases where PAN is

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 13:44, gengdongjiu wrote: > > > On 2017/9/6 20:30, Vladimir Murzin wrote: >> On 06/09/17 13:14, gengdongjiu wrote: >>> >>> >>> On 2017/9/6 20:00, Vladimir Murzin wrote: On 06/09/17 11:35, gengdongjiu wrote: > Vladimir, > > On 2017/9/6 17:41, Vladimir Murzin wrote:

[RFC PATCH 0/3] fix migrate failed when vm is in booting

We have a test scenario： vmlife and migrate fixed test. Here is a problem； VM migration failed caused the qemu core which gdb trace: #0 0xb023fe84 in raise () from /usr/lib64/libc.so.6 #1 0xb0241b80 in abort () from /usr/lib64/libc.so.6 #2 0x0046b408 in

[RFC PATCH 3/3] kvm: arm/arm64: vgic-its: fix return value for restore

This patch fix the migrate restore tables failure. The same scene, at the destination, the restore tables interface traversal guest memory, and check the dte/ite is valid or not. If all dtes/ites are invalid, we will do try next one, and the last it will take the 1 return value, but currently, it

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

Hi, Vladimir > >> Do you see effect of "PAN is unexpectedly enabled"? > > In fact I did not encounter this case, but I think it can exist. > > I think if host OS dynamically disable PAN, it wants the host kernel access > > the user space address space not through copy_to/from_user > API. > > Now

答复:re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

Fix a typo. It is similar with the PAN，when the guest traps to el2，it will reset the pstate.UAO to 0, and continue run。In fact the host pstate.UAO can be 1, but guest change it to 0 when trap to EL2, so after swich to host，need to check whether set

Re: [RFC PATCH 3/3] kvm: arm/arm64: vgic-its: fix return value for restore

Hi Wanghaibin, On 06/09/2017 15:05, wanghaibin wrote: > This patch fix the migrate restore tables failure. > > The same scene, at the destination, the restore tables interface traversal > guest > memory, and check the dte/ite is valid or not. > If all dtes/ites are invalid, we will do try next

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 16:08, gengdongjiu wrote: > It is similar with the PAN，when the guest traps to el2，it will reset the > pstate.PAN to 0, and continue run。In fact the host > pstate.UAO can be 1, but guest change it to 0 when trap > to EL2。so after swich to

re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

It is similar with the PAN，when the guest traps to el2，it will reset the pstate.PAN to 0, and continue run。In fact the host pstate.UAO can be 1, but guest change it to 0 when trap to EL2。so after swich to host，need to check whether set

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

Hi gengdongjiu, [auto build test ERROR on arm64/for-next/core] [also build test ERROR on v4.13 next-20170906] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/gengdongjiu/arm64-KVM-VHE-save

Re: [PATCH v2 19/28] arm64/sve: ptrace and ELF coredump support

On Wed, Sep 06, 2017 at 04:21:50PM +, Okamoto, Takayuki wrote: > Hi Dave, > > I am an engineer of the postK computer from Fujitsu. > > When I tried to read "max_vl" by ptrace with this patch on our local SVE > simulator, it was read as zero. > I think the cause of this incident is that

re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

The negative effect is that kernel can not access kernel space adress through copy_to/from_user even KERNEL_DS is set 发件人：vladimir.murzin 收件人：耿东久,marc.zyngier,christoffer.dall,pbonzini,rkrcmar,linux-arm-kernel,kvmarm,kvm,linux-kernel,suzuki.poulose,mark.rutland,Catalin Marinas

RE: [PATCH v2 19/28] arm64/sve: ptrace and ELF coredump support

Hi Dave, Thank you for your reply. > Your fix looks correct and seems to work. For stylistic reasons, I may > write it like this instead, but the effect should be the same: > > header->max_vl = sve_max_vl; > if (WARN_ON(!sve_vl_valid(sve_max_vl)) > header->max_vl =

Re: [PATCH] arm64: KVM: VHE: save and restore some PSTATE bits

On 06/09/17 15:10, gengdongjiu wrote: > Hi, Vladimir > Do you see effect of "PAN is unexpectedly enabled"? >>> In fact I did not encounter this case, but I think it can exist. >>> I think if host OS dynamically disable PAN, it wants the host kernel access >>> the user space address space

Re: [RFC PATCH 2/3] kvm: arm/arm64: vgic-vits: free its resource when vm reboot/reset

Hi, On 06/09/2017 15:05, wanghaibin wrote: > This patch fix the migrate save tables failure. > > When the virtual machine is in booting and the devices haven't initialized, > the all virtual dte/ite may be invalid. If migrate at this moment, the save > tables interface traversal device list, and

[PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

In VHE mode, host kernel runs in the EL2 and can enable 'User Access Override' when fs==KERNEL_DS so that it can access kernel memory. However, PSTATE.UAO is set to 0 on an exception taken from EL1 to EL2. Thus when VHE is used and exception taken from a guest UAO will be disabled and host will

Re: [RFC PATCH 2/3] kvm: arm/arm64: vgic-vits: free its resource when vm reboot/reset

On 2017/9/7 0:20, Auger Eric wrote: > Hi, > > On 06/09/2017 15:05, wanghaibin wrote: >> This patch fix the migrate save tables failure. >> >> When the virtual machine is in booting and the devices haven't initialized, >> the all virtual dte/ite may be invalid. If migrate at this moment, the save

RE: [PATCH v2 19/28] arm64/sve: ptrace and ELF coredump support

Hi Dave, I am an engineer of the postK computer from Fujitsu. When I tried to read "max_vl" by ptrace with this patch on our local SVE simulator, it was read as zero. I think the cause of this incident is that "max_vl" is set as "header->vl" only on warning case in sve_init_header_from_task().