On 23/06/2020 19:26, Andy Lutomirski wrote:
> On Tue, Jun 23, 2020 at 8:23 AM Andrew Cooper
> wrote:
>> On 23/06/2020 14:03, Peter Zijlstra wrote:
>>> On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote:
>>>> On Tue, Jun 23, 2020 at 01:50:14PM +0200, P
On 23/06/2020 16:23, Peter Zijlstra wrote:
> On Tue, Jun 23, 2020 at 04:59:14PM +0200, Joerg Roedel wrote:
>> On Tue, Jun 23, 2020 at 04:53:44PM +0200, Peter Zijlstra wrote:
>>> +noinstr void idtentry_validate_ist(struct pt_regs *regs)
>>> +{
>>> + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) ==
>>> +
On 23/06/2020 16:16, Peter Zijlstra wrote:
> On Tue, Jun 23, 2020 at 04:49:40PM +0200, Joerg Roedel wrote:
>>> We're talking about the 3rd case where the only reason things 'work' is
>>> because we'll have to panic():
>>>
>>> - #MC
>> Okay, #MC is special and can only be handled on a best-effort b
On 23/06/2020 14:03, Peter Zijlstra wrote:
> On Tue, Jun 23, 2020 at 02:12:37PM +0200, Joerg Roedel wrote:
>> On Tue, Jun 23, 2020 at 01:50:14PM +0200, Peter Zijlstra wrote:
>>> If SNP is the sole reason #VC needs to be IST, then I'd strongly urge
>>> you to only make it IST if/when you try and mak
On 23/06/2020 13:47, Peter Zijlstra wrote:
> On Tue, Jun 23, 2020 at 12:51:03PM +0100, Andrew Cooper wrote:
>
>> There are cases which are definitely non-recoverable.
>>
>> For both ES and SNP, a malicious hypervisor can mess with the guest
>> physmap to make the t
On 23/06/2020 12:30, Joerg Roedel wrote:
> On Tue, Jun 23, 2020 at 01:07:06PM +0200, Peter Zijlstra wrote:
>> On Tue, Apr 28, 2020 at 09:55:12AM +0200, Joerg Roedel wrote:
>> So what happens if this #VC triggers on the first access to the #VC
>> stack, because the malicious host has craftily mucked
On 28/04/2020 08:55, Joerg Roedel wrote:
> On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote:
>> I have a somewhat serious question: should we use IST for #VC at all?
>> As I understand it, Rome and Naples make it mandatory for hypervisors
>> to intercept #DB, which means that, due to
On 27/04/2020 18:37, Andy Lutomirski wrote:
> On Sat, Apr 25, 2020 at 3:10 PM Andy Lutomirski wrote:
>> On Sat, Apr 25, 2020 at 1:23 PM Joerg Roedel wrote:
>>> On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote:
I assume the race you mean is:
#VC
Immediate NMI bef
On 16/07/2019 01:05, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 4:30 PM Andrew Cooper
> wrote:
>> On 15/07/2019 19:17, Nadav Amit wrote:
>>>> On Jul 15, 2019, at 8:16 AM, Andrew Cooper
>>>> wrote:
>>>>
>>>> There is a lot of inf
On 15/07/2019 19:17, Nadav Amit wrote:
>> On Jul 15, 2019, at 8:16 AM, Andrew Cooper wrote:
>>
>> There is a lot of infrastructure for functionality which is used
>> exclusively in __{save,restore}_processor_state() on the suspend/resume
>> path.
>>
>
On 15/07/2019 18:28, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote:
>> Juergen Gross writes:
>>
>>> The long term plan has been to replace Xen PV guests by PVH. The first
>>> victim of that plan are now 32-bit PV guests, as those are used only
>>> rather seldom these d
the Local APIC state isn't a clever thing to be doing.
Delete the suspend/resume cr8 handling, which shrinks the size of struct
saved_context, and allows for the removal of both PVOPS.
Signed-off-by: Andrew Cooper
---
CC: x...@kernel.org
CC: virtualization@lists.linux-foundation.org
CC: Bor
On 15/07/2019 15:52, Juergen Gross wrote:
> On 15.07.19 16:26, Andy Lutomirski wrote:
>> On Mon, Jul 15, 2019 at 6:23 AM Juergen Gross wrote:
>>>
>>> On 15.07.19 15:00, Andrew Cooper wrote:
>>>> There is a lot of infrastructure for functionality which is u
, which allows for the removal
of both PVOPS.
Signed-off-by: Andrew Cooper
---
CC: x...@kernel.org
CC: virtualization@lists.linux-foundation.org
CC: Borislav Petkov
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Nadav Amit
CC: Stephane Eranian
CC: Feng Tang
CC: Juergen Gross
CC: Boris Ostrovsky
On 03/07/2019 18:02, Nadav Amit wrote:
>> On Jul 3, 2019, at 7:04 AM, Juergen Gross wrote:
>>
>> On 03.07.19 01:51, Nadav Amit wrote:
>>> To improve TLB shootdown performance, flush the remote and local TLBs
>>> concurrently. Introduce flush_tlb_multi() that does so. Introduce
>>> paravirtual vers
On 12/10/17 20:11, Boris Ostrovsky wrote:
> On 10/06/2017 10:32 AM, Josh Poimboeuf wrote:
>> On Thu, Oct 05, 2017 at 04:35:03PM -0400, Boris Ostrovsky wrote:
#ifdef CONFIG_PARAVIRT
+/*
+ * Paravirt alternatives are applied much earlier than normal
alternatives.
+ * They a
On 14/02/17 14:46, Waiman Long wrote:
> On 02/14/2017 04:39 AM, Peter Zijlstra wrote:
>> On Mon, Feb 13, 2017 at 05:34:01PM -0500, Waiman Long wrote:
>>> It is the address of &steal_time that will exceed the 32-bit limit.
>> That seems extremely unlikely. That would mean we have more than 4G
>> wor
On 20/12/15 09:25, Michael S. Tsirkin wrote:
> On Thu, Dec 17, 2015 at 03:39:10PM +0100, Peter Zijlstra wrote:
>> On Thu, Dec 17, 2015 at 04:33:44PM +0200, Michael S. Tsirkin wrote:
>>> On Thu, Dec 17, 2015 at 02:57:26PM +0100, Peter Zijlstra wrote:
You could of course go fix that instead of m
On 19/11/15 22:07, Andy Lutomirski wrote:
> On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky
> wrote:
>> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike
>> the
>> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
>> (and sysret32 in compat m
On 29/10/14 05:19, Andy Lutomirski wrote:
> Here's a draft CommonHV spec. It's also on github:
>
> https://github.com/amluto/CommonHV
>
> So far, this provides a two-way RNG interface, a way to detect it, and
> a way to detect other hypervisor leaves. The latter is because, after
> both the enorm
On 22/02/13 17:53, Yinghai Lu wrote:
> On Fri, Feb 22, 2013 at 9:24 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Feb 22, 2013 at 11:55:31AM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Feb 21, 2013 at 04:34:06PM -0800, H. Peter Anvin wrote:
Hi Linus,
This is a huge set of severa
On 07/01/13 10:25, Ian Campbell wrote:
On Fri, 2013-01-04 at 19:11 +, Konrad Rzeszutek Wilk wrote:
On Fri, Jan 04, 2013 at 06:07:51PM +0100, Daniel Kiper wrote:
Because current KEXEC_CMD_kexec_load does not load kernel
image and other things into Xen memory. It means that it
should live som
On 27/12/12 18:02, Eric W. Biederman wrote:
Andrew Cooper writes:
On 27/12/2012 07:53, Eric W. Biederman wrote:
The syscall ABI still has the wrong semantics.
Aka totally unmaintainable and umergeable.
The concept of domU support is also strange. What does domU support even mean,
when
On 27/12/2012 07:53, Eric W. Biederman wrote:
> The syscall ABI still has the wrong semantics.
>
> Aka totally unmaintainable and umergeable.
>
> The concept of domU support is also strange. What does domU support even
> mean, when the dom0 support is loading a kernel to pick up Xen when Xen fall
On 23/11/2012 01:38, H. Peter Anvin wrote:
> I still don't really get why it can't be isolated from dom0, which would make
> more sense to me, even for a Xen crash.
>
The crash region (as specified by crashkernel= on the Xen command line)
is isolated from dom0.
dom0 (using the kexec utility etc)
On 22/11/2012 17:47, H. Peter Anvin wrote:
> The other thing that should be considered here is how utterly
> preposterous the notion of doing in-guest crash dumping is in a system
> that contains a hypervisor. The reason for kdump is that on bare metal
> there are no other options, but in a hyp
ng memory, and possibly get corrupt.
>
> -hpa
>
I agree that regular guests should not be using the kexec/kdump.
However, this patch series is required for allowing a pvops kernel to be
a crash kernel for Xen, which is very important from dom0/Xen's point of
view.
--
Andrew Cooper
27 matches
Mail list logo