Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.14, v5.4.42, v4.19.124, v4.14.181,
v4.9.224, v4.4.224.
v5.6.14: Build OK!
On 27/05/20 09:48, Marc Zyngier wrote:
>
> My own question is whether this even makes any sense 10 years later.
> The HW has massively changed, and this adds a whole lot of complexity
> to both the hypervisor and the guest.
It still makes sense, but indeed it's for different reasons. One
On Wed, May 27, 2020 at 10:34:09AM +0100, Marc Zyngier wrote:
> HI Mark,
>
> On 2020-05-19 11:44, Mark Rutland wrote:
> > On Wed, Apr 22, 2020 at 01:00:50PM +0100, Marc Zyngier wrote:
> > > -static unsigned long get_except64_pstate(struct kvm_vcpu *vcpu)
> > > +static void enter_exception(struct
On 2020-05-26 17:29, James Morse wrote:
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
As ELR-EL1 is a VNCR-capable register with ARMv8.4-NV, let's move it
to
the sys_regs array and repaint the accessors. While we're at it, let's
kill the now useless accessors used only on the fault
On 2020-05-26 17:29, James Morse wrote:
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
struct kvm_regs is used by userspace to indicate which register gets
accessed by the {GET,SET}_ONE_REG API. But as we're about to refactor
the layout of the in-kernel register structures, we need the
On 2020-05-26 17:28, James Morse wrote:
Hi Marc,
On 22/04/2020 13:00, Marc Zyngier wrote:
Extract the direct HW accessors for later reuse.
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 51db934702b64..46f218982df8c 100644
--- a/arch/arm64/kvm/sys_regs.c
+++
HI Mark,
On 2020-05-19 11:44, Mark Rutland wrote:
On Wed, Apr 22, 2020 at 01:00:50PM +0100, Marc Zyngier wrote:
We currently assume that an exception is delivered to EL1, always.
Once we emulate EL2, this no longer will be the case. To prepare
for this, add a target_mode parameter.
While
Hi Catalin,
On 2020/5/26 19:49, Catalin Marinas wrote:
> On Mon, May 25, 2020 at 07:24:01PM +0800, Keqian Zhu wrote:
>> diff --git a/arch/arm64/include/asm/pgtable-prot.h
>> b/arch/arm64/include/asm/pgtable-prot.h
>> index 1305e28225fc..f9910ba2afd8 100644
>> ---
On Wed, May 27, 2020 at 08:40:47AM +, Tian, Kevin wrote:
> > From: Xiang Zheng
> > Sent: Wednesday, May 27, 2020 2:45 PM
> >
> >
> > On 2020/5/27 11:27, Tian, Kevin wrote:
> > >> From: Xiang Zheng
> > >> Sent: Monday, May 25, 2020 7:34 PM
> > >>
> > >> [+cc Kirti, Yan, Alex]
> > >>
> > >>
On 2020-05-13 10:06, Andrew Scull wrote:
On Tue, May 12, 2020 at 01:04:31PM +0100, James Morse wrote:
Hi Andrew,
On 07/05/2020 16:13, Andrew Scull wrote:
>> @@ -176,7 +177,7 @@ static void clear_stage2_pud_entry(struct kvm_s2_mmu
*mmu, pud_t *pud, phys_addr
>>pmd_t *pmd_table
Hi Marc,
On 5/27/20 9:41 AM, Marc Zyngier wrote:
> Hi Alex,
>
> On 2020-05-12 17:53, Alexandru Elisei wrote:
>> Hi,
>>
>> On 5/12/20 12:17 PM, James Morse wrote:
>>> Hi Alex, Marc,
>>>
>>> (just on this last_vcpu_ran thing...)
>>>
>>> On 11/05/2020 17:38, Alexandru Elisei wrote:
On 4/22/20
Hi Marc,
On 2020/5/27 15:55, Marc Zyngier wrote:
Hi Zenghui,
On 2020-05-27 08:41, Zenghui Yu wrote:
On 2020/5/27 0:11, Marc Zyngier wrote:
On a system that uses SPIs to implement MSIs (as it would be
the case on a GICv2 system exposing a GICv2m to its guests),
we deny the possibility of
Hi Alex,
On 2020-05-12 17:53, Alexandru Elisei wrote:
Hi,
On 5/12/20 12:17 PM, James Morse wrote:
Hi Alex, Marc,
(just on this last_vcpu_ran thing...)
On 11/05/2020 17:38, Alexandru Elisei wrote:
On 4/22/20 1:00 PM, Marc Zyngier wrote:
From: Christoffer Dall
As we are about to reuse our
> From: Xiang Zheng
> Sent: Wednesday, May 27, 2020 2:45 PM
>
>
> On 2020/5/27 11:27, Tian, Kevin wrote:
> >> From: Xiang Zheng
> >> Sent: Monday, May 25, 2020 7:34 PM
> >>
> >> [+cc Kirti, Yan, Alex]
> >>
> >> On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
> >>> Hi,
> >>>
> >>> On Tue, May
Hi Zenghui,
On 2020-05-27 08:41, Zenghui Yu wrote:
On 2020/5/27 0:11, Marc Zyngier wrote:
On a system that uses SPIs to implement MSIs (as it would be
the case on a GICv2 system exposing a GICv2m to its guests),
we deny the possibility of injecting SPIs on the in-atomic
fast-path.
This
On 2020-05-27 03:39, Gavin Shan wrote:
Hi Mark,
[...]
Can you run tests with a real workload? For example, a kernel build
inside the VM?
Yeah, I agree it's far from a realistic workload. However, it's the
test case
which was suggested when async page fault was proposed from day one,
On 2020/5/27 0:11, Marc Zyngier wrote:
On a system that uses SPIs to implement MSIs (as it would be
the case on a GICv2 system exposing a GICv2m to its guests),
we deny the possibility of injecting SPIs on the in-atomic
fast-path.
This results in a very large amount of context-switches
(roughly
On 2020-05-27 05:05, Gavin Shan wrote:
Hi Mark,
[...]
+struct kvm_vcpu_pv_apf_data {
+ __u32 reason;
+ __u8pad[60];
+ __u32 enabled;
+};
What's all the padding for?
The padding is ensure the @reason and @enabled in different cache
line. @reason is shared by
On 2020-05-27 03:43, Gavin Shan wrote:
Hi Mark,
On 5/26/20 8:42 PM, Mark Rutland wrote:
On Fri, May 08, 2020 at 01:29:13PM +1000, Gavin Shan wrote:
Since kvm/arm32 was removed, this renames kvm_vcpu_get_hsr() to
kvm_vcpu_get_esr() to it a bit more self-explaining because the
functions returns
On 2020/4/27 13:40, Huacai Chen wrote:
Reviewed-by: Huacai Chen
On Mon, Apr 27, 2020 at 12:35 PM Tianjia Zhang
wrote:
In the current kvm version, 'kvm_run' has been included in the 'kvm_vcpu'
structure. For historical reasons, many kvm-related function parameters
retain the 'kvm_run' and
Hi Mark,
On 5/26/20 8:58 PM, Mark Rutland wrote:
On Fri, May 08, 2020 at 01:29:16PM +1000, Gavin Shan wrote:
This renames user_mem_abort() to kvm_handle_user_mem_abort(), and
then export it. The function will be used in asynchronous page fault
to populate a page table entry once the
> -Original Message-
> From: zhengxiang (A)
> Sent: Monday, May 25, 2020 7:34 PM
> To: Jean-Philippe Brucker
> Cc: linux-arm-ker...@lists.infradead.org; kvmarm@lists.cs.columbia.edu;
> Will Deacon; Wanghaibin (D); Zengtao (B); m...@kernel.org; James Morse;
> julien.thierry.k...@gmail.com;
Hi Mark,
On 5/26/20 10:34 PM, Mark Rutland wrote:
On Fri, May 08, 2020 at 01:29:17PM +1000, Gavin Shan wrote:
There are two stages of fault pages and the stage one page fault is
handled by guest itself. The guest is trapped to host when the page
fault is caused by stage 2 page table, for
Hi Mark,
On 5/26/20 8:42 PM, Mark Rutland wrote:
On Fri, May 08, 2020 at 01:29:13PM +1000, Gavin Shan wrote:
Since kvm/arm32 was removed, this renames kvm_vcpu_get_hsr() to
kvm_vcpu_get_esr() to it a bit more self-explaining because the
functions returns ESR instead of HSR on aarch64. This
Hi Mark,
On 5/26/20 8:45 PM, Mark Rutland wrote:
On Fri, May 08, 2020 at 01:29:15PM +1000, Gavin Shan wrote:
This replace the variable names to make them self-explaining. The
tracepoint isn't changed accordingly because they're part of ABI:
* @hsr to @esr
* @hsr_ec to @ec
* Use
Hi Mark,
On 5/26/20 11:09 PM, Mark Rutland wrote:
At a high-level I'm rather fearful of this series. I can see many ways
that this can break, and I can also see that even if/when we get things
into a working state, constant vigilance will be requried for any
changes to the entry code.
I'm not
Hi Mark,
On 5/26/20 8:51 PM, Mark Rutland wrote:
On Fri, May 08, 2020 at 01:29:14PM +1000, Gavin Shan wrote:
There are a set of inline functions defined in kvm_emulate.h. Those
functions reads ESR from vCPU fault information struct and then operate
on it. So it's tied with vCPU fault
On 2020/5/27 12:20, Paul Mackerras wrote:
On Mon, Apr 27, 2020 at 12:35:10PM +0800, Tianjia Zhang wrote:
The 'kvm_run' field already exists in the 'vcpu' structure, which
is the same structure as the 'kvm_run' in the 'vcpu_arch' and
should be deleted.
Signed-off-by: Tianjia Zhang
Thanks,
Hi Gavin,
I definitely appreciate the work, but this is repeating most of the
mistakes done in the x86 implementation. In particular:
- the page ready signal can be done as an interrupt, rather than an
exception. This is because "page ready" can be handled asynchronously,
in contrast to "page
On 2020/5/27 11:27, Tian, Kevin wrote:
>> From: Xiang Zheng
>> Sent: Monday, May 25, 2020 7:34 PM
>>
>> [+cc Kirti, Yan, Alex]
>>
>> On 2020/5/23 1:14, Jean-Philippe Brucker wrote:
>>> Hi,
>>>
>>> On Tue, May 19, 2020 at 05:42:55PM +0800, Xiang Zheng wrote:
Hi all,
Is there any
Hi Steven,
> -Original Message-
> From: Steven Price
> Sent: Tuesday, May 26, 2020 7:02 PM
> To: Jianyong Wu ; net...@vger.kernel.org;
> yangbo...@nxp.com; john.stu...@linaro.org; t...@linutronix.de;
> pbonz...@redhat.com; sean.j.christopher...@intel.com; m...@kernel.org;
>
31 matches
Mail list logo
