On Fri, Mar 15, 2019 at 01:06:06PM +0100, Cédric Le Goater wrote:
> The KVM XICS-over-XIVE device and the proposed KVM XIVE native device
> implement an IRQ space for the guest using the generic IPI interrupts
> of the XIVE IC controller. These interrupts are allocated at the OPAL
> level and
On Mon, Mar 18, 2019 at 03:12:10PM +0100, Cédric Le Goater wrote:
> On 3/18/19 4:23 AM, David Gibson wrote:
> > On Fri, Mar 15, 2019 at 01:05:58PM +0100, Cédric Le Goater wrote:
> >> These controls will be used by the H_INT_SET_QUEUE_CONFIG and
> >> H_INT_GET_QUEUE_CONFIG hcalls from QEMU to
On Fri, Mar 15, 2019 at 01:06:09PM +0100, Cédric Le Goater wrote:
> When the VM boots, the CAS negotiation process determines which
> interrupt mode to use and invokes a machine reset. At that time, the
> previous KVM interrupt device is 'destroyed' before the chosen one is
> created. Upon
On Fri, Mar 15, 2019 at 01:06:02PM +0100, Cédric Le Goater wrote:
> The state of the thread interrupt management registers needs to be
> collected for migration. These registers are cached under the
> 'xive_saved_state.w01' field of the VCPU when the VPCU context is
> pulled from the HW thread. An
On 2019/3/18 18:49, Sudeep Holla wrote:
> Add PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP support on arm64.
> We can just make sure of the generic ptrace_syscall_enter hook to
> support PTRACE_SYSEMU. We don't need any special handling for
> PTRACE_SYSEMU_SINGLESTEP.
This looks good to me. But
Hi Mark
Can this patch be accepted? Or need I do any update?
Best regards
Wang shengjiu
>
> There is very low possibility ( < 0.1% ) that channel swap happened in
> beginning when multi output/input pin is enabled. The issue is that
> hardware can't send data to correct pin in the
Hi Daniel,
Daniel Walker writes:
> Here are the generic command line changes for powerpc.
>
> These changes have been in linux-next for two cycles, with few problems
> reported.
> It's also been used at Cisco Systems, Inc. in production products for many
> many
> years with no problems.
>
>
Ard Biesheuvel writes:
> On Mon, 18 Mar 2019 at 09:41, Michael Ellerman wrote:
...
>>
>> I don't understand how the crypto core chooses which crypto_alg to use,
>> but I didn't expect enabling the tests to change it?
>
> This is not entirely unexpected. Based on the tests, algos that are
> found
On Mon, Mar 18, 2019 at 3:49 AM Sudeep Holla wrote:
>
> Hi,
>
> This patchset evolved from the discussion in the thread[0][1]. When we
> wanted to add PTRACE_SYSEMU support to ARM64, we thought instead of
> duplicating what other architectures like x86 and powerpc have done,
> let consolidate the
On Mon, Mar 18, 2019 at 06:33:41PM +0100, Oleg Nesterov wrote:
> On 03/18, Sudeep Holla wrote:
> >
> > On Mon, Mar 18, 2019 at 06:20:24PM +0100, Oleg Nesterov wrote:
> > >
> > > Again, to me this patch just makes the code look worse. Honestly, I don't
> > > think that the new (badly named)
On 03/18, Sudeep Holla wrote:
>
> On Mon, Mar 18, 2019 at 06:20:24PM +0100, Oleg Nesterov wrote:
> >
> > Again, to me this patch just makes the code look worse. Honestly, I don't
> > think that the new (badly named) ptrace_syscall_enter() hook makes any
> > sense.
> >
>
> Worse because we end up
On 03/18, Sudeep Holla wrote:
>
@@ -534,6 +534,10 @@ static int ptrace_detach(struct task_struct *child,
unsigned int data)
> /* Architecture-specific hardware disable .. */
> ptrace_disable(child);
>
> +#ifdef TIF_SYSCALL_EMU
> + clear_tsk_thread_flag(child, TIF_SYSCALL_EMU);
On Mon, Mar 18, 2019 at 06:20:24PM +0100, Oleg Nesterov wrote:
> On 03/18, Sudeep Holla wrote:
> >
> > --- a/arch/powerpc/kernel/ptrace.c
> > +++ b/arch/powerpc/kernel/ptrace.c
> > @@ -3278,35 +3278,29 @@ long do_syscall_trace_enter(struct pt_regs *regs)
> >
> > user_exit();
> >
> > - flags
On 03/18, Sudeep Holla wrote:
>
> --- a/arch/powerpc/kernel/ptrace.c
> +++ b/arch/powerpc/kernel/ptrace.c
> @@ -3278,35 +3278,29 @@ long do_syscall_trace_enter(struct pt_regs *regs)
>
> user_exit();
>
> - flags = READ_ONCE(current_thread_info()->flags) &
> -
On 03/18, Sudeep Holla wrote:
>
> --- a/arch/x86/entry/common.c
> +++ b/arch/x86/entry/common.c
> @@ -70,22 +70,16 @@ static long syscall_trace_enter(struct pt_regs *regs)
>
> struct thread_info *ti = current_thread_info();
> unsigned long ret = 0;
> - bool emulated = false;
>
On Mon, Mar 18, 2019 at 05:26:18PM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 18, 2019 at 10:49:23AM +, Sudeep Holla wrote:
> > Now that we have a new hook ptrace_syscall_enter that can be called from
> > syscall entry code and it handles PTRACE_SYSEMU in generic code, we
> > can do some
On Mon, Mar 18, 2019 at 05:41:15PM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 18, 2019 at 10:49:21AM +, Sudeep Holla wrote:
> > Currently each architecture handles PTRACE_SYSEMU in very similar way.
> > It's completely arch independent and can be handled in the code helping
> > to consolidate
[ ... ]
>>> + page = gfn_to_page(kvm, gpa_to_gfn(kvm_eq.qpage));
>>> + if (is_error_page(page)) {
>>> + pr_warn("Couldn't get guest page for %llx!\n", kvm_eq.qpage);
>>> + return -EINVAL;
>>> + }
>>
>> Yeah.. for the case of a 4kiB page host (these days weird, but not
On Mon, Mar 18, 2019 at 05:31:47PM +0300, Dmitry V. Levin wrote:
> On Mon, Mar 18, 2019 at 10:49:21AM +, Sudeep Holla wrote:
> > Currently each architecture handles PTRACE_SYSEMU in very similar way.
> > It's completely arch independent and can be handled in the code helping
> > to consolidate
On 3/18/19 4:23 AM, David Gibson wrote:
> On Fri, Mar 15, 2019 at 01:05:58PM +0100, Cédric Le Goater wrote:
>> These controls will be used by the H_INT_SET_QUEUE_CONFIG and
>> H_INT_GET_QUEUE_CONFIG hcalls from QEMU to configure the underlying
>> Event Queue in the XIVE IC. They will also be used
On Mon, Mar 18, 2019 at 10:49:21AM +, Sudeep Holla wrote:
> Currently each architecture handles PTRACE_SYSEMU in very similar way.
> It's completely arch independent and can be handled in the code helping
> to consolidate PTRACE_SYSEMU handling.
>
> Let's introduce a hook
On Mon, Mar 18, 2019 at 10:49:21AM +, Sudeep Holla wrote:
> Currently each architecture handles PTRACE_SYSEMU in very similar way.
> It's completely arch independent and can be handled in the code helping
> to consolidate PTRACE_SYSEMU handling.
>
> Let's introduce a hook
On Mon, Mar 18, 2019 at 10:49:23AM +, Sudeep Holla wrote:
> Now that we have a new hook ptrace_syscall_enter that can be called from
> syscall entry code and it handles PTRACE_SYSEMU in generic code, we
> can do some cleanup using the same in do_syscall_trace_enter.
>
> Cc: Oleg Nesterov
>
On Mon, Mar 18, 2019 at 04:17:30PM +0530, Srikar Dronamraju wrote:
> > > node 0 (because firmware doesn't provide the distance information for
> > > memoryless/cpuless nodes):
> > >
> > > node 0 1 2 3
> > > 0: 10 40 10 10
> > > 1: 40 10 40 40
> > > 2: 10 40 10 10
* Laurent Vivier [2019-03-15 12:12:45]:
>
> Another way to avoid the nodes overlapping for the offline nodes at
> startup is to ensure the default values don't define a distance that
> merge all offline nodes into node 0.
>
> A powerpc specific patch can workaround the kernel crash by doing
Add PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP support on arm64.
We can just make sure of the generic ptrace_syscall_enter hook to
support PTRACE_SYSEMU. We don't need any special handling for
PTRACE_SYSEMU_SINGLESTEP.
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Sudeep Holla
---
x86 and um use 31 and 32 for PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
while powerpc uses different value maybe for legacy reasons.
Though handling of PTRACE_SYSEMU can be made architecture independent,
it's hard to make these definations generic. To add to this existing
mess few architectures
Now that we have a new hook ptrace_syscall_enter that can be called from
syscall entry code and it handles PTRACE_SYSEMU in generic code, we
can do some cleanup using the same in do_syscall_trace_enter.
Cc: Oleg Nesterov
Cc: Paul Mackerras
Cc: Michael Ellerman
Signed-off-by: Sudeep Holla
---
Now that we have a new hook ptrace_syscall_enter that can be called from
syscall entry code and it handles PTRACE_SYSEMU in generic code, we
can do some cleanup using the same in syscall_trace_enter.
Further the extra logic to find single stepping PTRACE_SYSEMU_SINGLESTEP
in
Currently each architecture handles PTRACE_SYSEMU in very similar way.
It's completely arch independent and can be handled in the code helping
to consolidate PTRACE_SYSEMU handling.
Let's introduce a hook 'ptrace_syscall_enter' that arch specific syscall
entry code can call.
Cc: Oleg Nesterov
While the TIF_SYSCALL_EMU is set in ptrace_resume independent of any
architecture, currently only powerpc and x86 unset the TIF_SYSCALL_EMU
flag in ptrace_disable which gets called from ptrace_detach.
Let's move the clearing of TIF_SYSCALL_EMU flag to ptrace_detach after
we return from
Hi,
This patchset evolved from the discussion in the thread[0][1]. When we
wanted to add PTRACE_SYSEMU support to ARM64, we thought instead of
duplicating what other architectures like x86 and powerpc have done,
let consolidate the existing support and move it to the core as there's
nothing arch
> > node 0 (because firmware doesn't provide the distance information for
> > memoryless/cpuless nodes):
> >
> > node 0 1 2 3
> > 0: 10 40 10 10
> > 1: 40 10 40 40
> > 2: 10 40 10 10
> > 3: 10 40 10 10
>
> *groan*... what does it do for things like
On 3/18/19 1:19 AM, David Gibson wrote:
> On Fri, Mar 15, 2019 at 01:05:55PM +0100, Cédric Le Goater wrote:
>> The user interface exposes a new capability KVM_CAP_PPC_IRQ_XIVE to
>> let QEMU connect the vCPU presenters to the XIVE KVM device if
>> required. The capability is not advertised for now
Guenter Roeck writes:
> On 3/15/19 6:20 AM, Christophe Leroy wrote:
>> Michael,
>>
>> Are you able to get this merged before 5.1-rc1 comes out ?
>
> Looks like this patch got lost. I don't see it in Michael's most recent
> pull request, the one that got merged today.
Sorry, will pick it up for
On Mon, 18 Mar 2019 at 09:41, Michael Ellerman wrote:
>
> Eric Biggers writes:
> > On Fri, Mar 15, 2019 at 03:24:35PM +1100, Daniel Axtens wrote:
> ...
> >> >> This leads to corruption of the IV, which leads to subsequent blocks
> >> >> being corrupted.
> >> >>
> >> >> This can be detected with
Eric Biggers writes:
> On Fri, Mar 15, 2019 at 03:24:35PM +1100, Daniel Axtens wrote:
...
>> >> This leads to corruption of the IV, which leads to subsequent blocks
>> >> being corrupted.
>> >>
>> >> This can be detected with libkcapi test suite, which is available at
>> >>
On Sat, 16 Mar 2019, Enrico Weigelt, metux IT consult wrote:
> > No, it's just that those systems do not allow those devices to be
> > removed because they are probably not on a removable bus.
>
> Ok, devices (hw) might not be removable - that also the case for uarts
> builtin some SoCs, or the
On Fri, Mar 15, 2019 at 7:35 AM Enrico Weigelt, metux IT consult
wrote:
>
> Instead of fetching out data from a struct resource for passing
> it to devm_ioremap(), directly use devm_ioremap_resource()
>
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
NACK.
This patch would break my
On 3/17/19 2:31 PM, christophe leroy wrote:
Le 17/03/2019 à 17:28, Alexandre Ghiti a écrit :
On systems without CONTIG_ALLOC activated but that support gigantic
pages,
boottime reserved gigantic pages can not be freed at all. This patch
simply enables the possibility to hand back those pages
On Fri, Mar 15, 2019 at 01:06:08PM +0100, Cédric Le Goater wrote:
> The 'destroy' method is currently used to destroy all devices when the
> VM is destroyed after the vCPUs have been freed.
>
> This new KVM ioctl exposes the same KVM device method. It acts as a
> software reset of the VM to
On Fri, Mar 15, 2019 at 01:06:07PM +0100, Cédric Le Goater wrote:
> Full support for the XIVE native exploitation mode is now available,
> advertise the capability KVM_CAP_PPC_IRQ_XIVE for guests running on
> PowerNV KVM Hypervisors only. Support for nested guests (pseries KVM
> Hypervisor) is not
Daniel Axtens writes:
> The original assembly imported from OpenSSL has two copy-paste
> errors in handling CTR mode. When dealing with a 2 or 3 block tail,
> the code branches to the CBC decryption exit path, rather than to
> the CTR exit path.
>
> This leads to corruption of the IV, which leads
43 matches
Mail list logo
