On 15/07/14 14:48, Frediano Ziglio wrote:
> sync_test_bit function require a long* read access to pointer.
> This is a problem if the you are using last entry in the page causing
> an access to next page. If this page is not readable you get a memory
> access failure (page fault).
> All other x64 b
On 05/02/2014 20:23, Zoltan Kiss wrote:
> On 04/02/14 19:47, Michael Chan wrote:
>> On Fri, 2014-01-31 at 14:29 +0100, Zoltan Kiss wrote:
>>> [ 5417.275472] WARNING: at net/sched/sch_generic.c:255
>>> dev_watchdog+0x156/0x1f0()
>>> [ 5417.275474] NETDEV WATCHDOG: eth1 (bnx2): transmit queue 2 timed
On 18/12/13 15:14, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 18, 2013 at 11:51:22AM +, Ian Campbell wrote:
>> On Tue, 2013-12-17 at 17:53 +, Stefano Stabellini wrote:
>>> There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
>>> As a matter of fact ARM guests, HVM from Li
On 28/08/2014 19:01, Stefan Bader wrote:
>>> So not much further... but then I think I know what I do next. Probably
>>> should
>>> have done before. I'll replace the WARN_ON in vmalloc that triggers by a
>>> panic
>>> and at least get a crash dump of that situation when it occurs. Then I can
>>
On 03/09/14 15:49, Boris Ostrovsky wrote:
> On 09/03/2014 09:58 AM, David Vrabel wrote:
>
>> #endif
>> diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
>> index 485b695..a64b464 100644
>> --- a/arch/x86/xen/xen-head.S
>> +++ b/arch/x86/xen/xen-head.S
>> @@ -47,6 +47,40 @@ ENTRY(star
On 04/09/14 13:59, David Vrabel wrote:
> On 04/09/14 13:38, Juergen Gross wrote:
>> Direct Xen to place the initial P->M table outside of the initial
>> mapping, as otherwise the 1G (implementation) / 2G (theoretical)
>> restriction on the size of the initial mapping limits the amount
>> of memory
On 04/09/14 15:31, Jan Beulich wrote:
On 04.09.14 at 15:02, wrote:
>> On 04/09/14 13:59, David Vrabel wrote:
>>> On 04/09/14 13:38, Juergen Gross wrote:
Direct Xen to place the initial P->M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
On 05/09/14 08:55, Juergen Gross wrote:
> On 09/04/2014 04:43 PM, Andrew Cooper wrote:
>> On 04/09/14 15:31, Jan Beulich wrote:
>>>>>> On 04.09.14 at 15:02, wrote:
>>>> On 04/09/14 13:59, David Vrabel wrote:
>>>>> On 04/09/14 13:38, Juergen Gr
On 29/08/14 09:37, Stefan Bader wrote:
> On 29.08.2014 00:42, Andrew Cooper wrote:
>> On 28/08/2014 19:01, Stefan Bader wrote:
>>>>> So not much further... but then I think I know what I do next. Probably
>>>>> should
>>>>> have done before.
On 29/08/14 15:32, Stefan Bader wrote:
> On 29.08.2014 16:19, Andrew Cooper wrote:
>> On 29/08/14 09:37, Stefan Bader wrote:
>>> On 29.08.2014 00:42, Andrew Cooper wrote:
>>>> On 28/08/2014 19:01, Stefan Bader wrote:
>>>>>>> So not much further.
On 02/09/14 12:01, David Vrabel wrote:
> On 01/09/14 18:34, David Vrabel wrote:
>> On 29/08/14 16:17, Stefan Bader wrote:
>>> This change might not be the fully correct approach as it basically
>>> removes the pre-set page table entry for the fixmap that is compile
>>> time set (level2_fixmap_pgt[5
On 21/10/14 20:01, Boris Ostrovsky wrote:
> When hardware supports APIC/x2APIC virtualization we don't need to use pirqs
> for MSI handling and instead use APIC since most APIC accesses (MMIO or MSR)
> will now be processed without VMEXITs.
>
> As an example, netperf on the original code produces t
On 28/10/14 09:51, Ian Campbell wrote:
> On Tue, 2014-10-28 at 06:00 +0100, Juergen Gross wrote:
>> On 10/27/2014 04:16 PM, David Vrabel wrote:
>>> On 27/10/14 14:52, Juergen Gross wrote:
Paravirtualized kernels running on Xen use a three level tree for
translation of guest specific physi
On 28/10/14 12:39, David Vrabel wrote:
> On 28/10/14 12:07, Juergen Gross wrote:
>> Okay, back to the original question: is the (up to) 64 MB virtual
>> mapping of the p2m list on 32-bit pv domains a problem or not?
> I think up-to 64 MiB of vmalloc area is fine. The vmalloc space can be
> increas
On 28/10/14 12:44, David Vrabel wrote:
> On 28/10/14 12:42, Andrew Cooper wrote:
>> On 28/10/14 12:39, David Vrabel wrote:
>>> On 28/10/14 12:07, Juergen Gross wrote:
>>>> Okay, back to the original question: is the (up to) 64 MB virtual
>>>> mapping of t
On 28/07/15 15:05, Boris Ostrovsky wrote:
> On 07/28/2015 06:29 AM, Andrew Cooper wrote:
>>
>>>> After forward-porting my virtio patches, I got this thing to run on
>>>> Xen. After several tries, I got:
>>>>
>>>> [ 53.985707] --
On 28/07/15 15:50, Boris Ostrovsky wrote:
> On 07/28/2015 10:35 AM, Andrew Cooper wrote:
>> On 28/07/15 15:05, Boris Ostrovsky wrote:
>>> On 07/28/2015 06:29 AM, Andrew Cooper wrote:
>>>>>> After forward-porting my virtio patches, I got this thing to run on
>
On 28/07/15 16:43, Andy Lutomirski wrote:
>
After forward-porting my virtio patches, I got this thing to run on
Xen. After several tries, I got:
[ 53.985707] [ cut here ]
[ 53.986314] kernel BUG at arch/x86/xen/enlighten.c:496!
[ 53.98667
On 28/07/15 22:06, H. Peter Anvin wrote:
> On 07/28/2015 08:02 AM, Julien Grall wrote:
>> Hi all,
>>
>> This patch series aims to use the memory terminologies described in
>> include/linux/mm.h [1] for Linux xen code.
>>
>> Linux is using mistakenly MFN when GFN is meant, I suspect this is because
On 29/07/2015 01:21, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
> wrote:
>> On 07/28/2015 01:07 PM, Andy Lutomirski wrote:
>>> On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
>>> wrote:
>>>> I suspect that the set_l
On 29/07/15 06:28, Andy Lutomirski wrote:
> On Tue, Jul 28, 2015 at 8:01 PM, Boris Ostrovsky
> wrote:
>> On 07/28/2015 08:47 PM, Andrew Cooper wrote:
>>> On 29/07/2015 01:21, Andy Lutomirski wrote:
>>>> On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
>>
On 29/07/15 15:43, Boris Ostrovsky wrote:
> FYI, I have got a repro now and am investigating.
Good and bad news. This bug has nothing to do with LDTs themselves.
I have worked out what is going on, but this:
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 5abeaac..7e1a82e
On 29/07/2015 22:26, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky
> wrote:
>> On 07/29/2015 03:03 PM, Andrew Cooper wrote:
>>> On 29/07/15 15:43, Boris Ostrovsky wrote:
>>>> FYI, I have got a repro now and am investigating.
>>>
On 29/07/2015 23:05, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper
> wrote:
>> On 29/07/2015 22:26, Andy Lutomirski wrote:
>>> On Wed, Jul 29, 2015 at 2:23 PM, Boris Ostrovsky
>>> wrote:
>>>> On 07/29/2015 03:03 PM, Andrew Co
On 29/07/2015 23:49, Boris Ostrovsky wrote:
> On 07/29/2015 06:46 PM, David Vrabel wrote:
>>
>> On 29/07/2015 23:11, Andrew Cooper wrote:
>>> On 29/07/2015 23:05, Andy Lutomirski wrote:
>>>> On Wed, Jul 29, 2015 at 2:37 PM, Andrew Cooper
>>>> w
On 30/07/2015 00:13, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
> wrote:
>> On 29/07/2015 23:49, Boris Ostrovsky wrote:
>>> On 07/29/2015 06:46 PM, David Vrabel wrote:
>>>> On 29/07/2015 23:11, Andrew Cooper wrote:
>>>>
On 30/07/15 17:05, Borislav Petkov wrote:
> On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
>> As far as Xen guests are concerned,
>>
>> Tested-by: Boris Ostrovsky
> Does that mean, this patch 1/4 fixes the 32bit issue you guys are still
> debugging on the v4 thread? Or does that
On 30/07/15 17:31, Boris Ostrovsky wrote:
> On 07/30/2015 12:12 PM, Andrew Cooper wrote:
>> On 30/07/15 17:05, Borislav Petkov wrote:
>>> On Thu, Jul 30, 2015 at 11:53:34AM -0400, Boris Ostrovsky wrote:
>>>> As far as Xen guests are concerned,
>>>>
>
On 30/07/15 19:30, Andy Lutomirski wrote:
> On Wed, Jul 29, 2015 at 5:29 PM, Andrew Cooper
> wrote:
>> On 30/07/2015 00:13, Andy Lutomirski wrote:
>>> On Wed, Jul 29, 2015 at 4:02 PM, Andrew Cooper
>>> wrote:
>>>> On 29/07/2015 23:49, Boris Ostrovsky
On 30/07/2015 22:31, Andy Lutomirski wrote:
> Note to -stable maintainers: by itself, this patch makes a
> pre-existing Xen bug much easier to trigger; on a 32-bit Xen guest,
> the new ldt_gdt selftest is likely to OOPS. Even without this
> patch, the test can OOPS, but it's much less likely to ha
On 30/07/15 22:31, Andy Lutomirski wrote:
> This is intended for x86/urgent. Sorry for taking so long, but it
> seemed nice to avoid breaking Xen.
Very much appreciated. Thanks!
>
> This fixes the "dazed and confused" issue which was exposed by the
> CVE-2015-5157 fix. It's also probably a goo
On 23/07/2015 17:49, Andy Lutomirski wrote:
> Hi-
Hi. Apologies for the delay. I have been out of the office for a few days.
>
> In entry_64.S, we have:
>
> ENTRY(entry_SYSCALL_64)
> /*
> * Interrupts are off on entry.
> * We do not frame this tiny irq-off block with TRACE_IRQS_OF
On 26/07/2015 23:08, Andy Lutomirski wrote:
>
>>> If so, can we just
>>> enter later on:
>>>
>>> pushq%r11/* pt_regs->flags */
>>> pushq$__USER_CS/* pt_regs->cs */
>>> pushq%rcx/* pt_regs->ip */
>>>
>>> <-- Xen enters here
>>>
>>
On 27/07/15 00:27, Andy Lutomirski wrote:
>
> For SYSRET, I think the way to go is to force Xen to always use the
> syscall slow path. Instead, Xen could hook into
> syscall_return_via_sysret or even right before the opportunistic
> sysret stuff. Then we could remove the USERGS_SY
On 28/07/15 04:16, Andy Lutomirski wrote:
> On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski wrote:
>> On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
>> wrote:
>>> On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 8:36 AM, Boris Ostrovsky
wrote:
> On 07/25/20
On 24/05/16 23:48, Andy Lutomirski wrote:
> In aa1acff356bb ("x86/xen: Probe target addresses in
> set_aliased_prot() before the hypercall"), I added an explicit probe
> to work around a hypercall issue. The code can be simplified by
> using probe_kernel_read.
>
> Cc
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 24/11/15 13:39, Jan Beulich wrote:
>>>> On 24.11.15 at 13:57, wrote:
>> V Tue, 24 Nov 2015 10:35:03 +0000
>> Andrew Cooper napsáno:
>>
>>> On 24/11/15 10:17, Petr Tesarik wrote:
>>>> On Tue, 24 Nov 2015 10:09:01 +
>>>> Davi
On 24/11/15 13:41, Andrew Cooper wrote:
> On 24/11/15 13:39, Jan Beulich wrote:
>>>>> On 24.11.15 at 13:57, wrote:
>>> V Tue, 24 Nov 2015 10:35:03 +
>>> Andrew Cooper napsáno:
>>>
>>>> On 24/11/15 10:17, Petr Tesarik wrote:
>>&
On 21/07/2015 22:53, Boris Ostrovsky wrote:
> On 07/21/2015 03:59 PM, Andy Lutomirski wrote:
>> --- a/arch/x86/include/asm/mmu_context.h
>> +++ b/arch/x86/include/asm/mmu_context.h
>> @@ -34,6 +34,44 @@ static inline void load_mm_cr4(struct mm_struct
>> *mm) {}
>> #endif
>> /*
>> + * ldt_stru
On 22/07/2015 01:07, Andy Lutomirski wrote:
> On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
> wrote:
>> On 21/07/2015 22:53, Boris Ostrovsky wrote:
>>> On 07/21/2015 03:59 PM, Andy Lutomirski wrote:
>>>> --- a/arch/x86/include/asm/mmu_context.h
>>>
On 22/07/2015 01:28, Andy Lutomirski wrote:
> On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
> wrote:
>> On 22/07/2015 01:07, Andy Lutomirski wrote:
>>> On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
>>> wrote:
>>>> On 21/07/2015 22:53, Boris Ostrovsky
On 22/01/2016 23:32, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 04:35:50PM -0500, Boris Ostrovsky wrote:
>> +/*
>> + * See Documentation/x86/boot.txt.
>> + *
>> + * Version 2.12 supports Xen entry point but we will use default x86/PC
>> + * environment (i.e. hardware_sub
On 23/01/2016 00:55, Luis R. Rodriguez wrote:
> On Fri, Jan 22, 2016 at 4:30 PM, Andrew Cooper
> wrote:
>> the DMLite boot
>> protocol is OS agnostic, and will be staying that way.
> What's the DMLite boot protocol?
It is a statement of the initial state of a DMLite
On 08/02/16 15:55, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 10:39:43AM -0500, Boris Ostrovsky wrote:
>> It does. Very much IIRC, the problem was not caused by an access to MSR but
>> rather some sort of address not being available somewhere.
> See below.
>
>>> - microcode application on Xen
On 08/02/16 16:12, Boris Ostrovsky wrote:
>
>
> On 02/08/2016 11:05 AM, Andrew Cooper wrote:
>>
>> For compatibility with other virtualisation specs, Xen's cpuid leaves
>> shift depending on configuration.
>>
>> Spec at
>> http://xenbits.xen.org/
On 08/02/16 16:31, Boris Ostrovsky wrote:
>
>
> On 02/08/2016 11:26 AM, Andrew Cooper wrote:
>> On 08/02/16 16:12, Boris Ostrovsky wrote:
>>>
>>> On 02/08/2016 11:05 AM, Andrew Cooper wrote:
>>>> For compatibility with other virtualisation spec
On 08/02/16 16:35, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 11:31:04AM -0500, Boris Ostrovsky wrote:
>> I think we are OK for PV because this code will be executed after pvops are
>> set and so we will be calling xen_cpuid().
> Not for the early loader - it is too early for pvops then. So y
On 08/02/16 16:45, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 04:38:40PM +0000, Andrew Cooper wrote:
>> Does the early loader have extable support? If so, this is fairly easy
>> to fix. If not, we have a problem.
> It doesn't and regardless, you want to have this CPU
On 24/02/16 14:12, David Vrabel wrote:
> On 22/02/16 22:06, Boris Ostrovsky wrote:
>> Baremetal kernels clear .bss early in the boot. Since Xen PV guests don't
>> excecute that early code they should do it too.
>>
>> (Since we introduce macros for specifying 32- and 64-bit registers we
>> can get r
On 24/02/16 17:18, Konrad Rzeszutek Wilk wrote:
>> I could do the same here by dropping the if (!xen_pv_domain()) check
>> above, but then if somebody specifies earlyprintk=xenboot on a non-Xen
>> environment, I expect Linux would crash.
> Nah, you made it "Work" with:
> commit eb5ef07151ba3c3cb4bc
On 24/02/16 15:19, Boris Ostrovsky wrote:
> Baremetal kernels clear .bss early in the boot but Xen PV guests don't
> execute that code. They have been able to run without problems because
> Xen domain builder happens to give out zeroed pages. However, since this
> is not really guaranteed, .bss sho
On 12/11/14 15:55, Jan Beulich wrote:
On 12.11.14 at 16:25, wrote:
>> +u64
>> +xen_swiotlb_get_required_mask(struct device *dev)
>> +{
>> +u64 max_mfn;
>> +
>> +max_mfn = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
>> +
>> +return DMA_BIT_MASK(fls64(max_mfn << PAGE_SHIFT)
On 27/11/14 18:36, Luis R. Rodriguez wrote:
> On Thu, Nov 27, 2014 at 07:36:31AM +0100, Juergen Gross wrote:
>> On 11/26/2014 11:26 PM, Luis R. Rodriguez wrote:
>>> From: "Luis R. Rodriguez"
>>>
>>> Some folks had reported that some xen hypercalls take a long time
>>> to complete when issued from
On 11/11/14 05:43, Juergen Gross wrote:
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index fa75842..f67f8cf 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -268,6 +271,22 @@ static void p2m_init(unsigned long *p2m)
> p2m[i] = INVALID_P2M_ENTRY;
> }
>
>
On 02/12/2014 20:48, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 02, 2014 at 03:19:11PM -0500, Boris Ostrovsky wrote:
>> Changes in v4:
>> * Added comment describing what we check for in pci_xen_init()
>>
> Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Andrew Coo
On 22/01/15 02:17, Luis R. Rodriguez wrote:
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -32,6 +32,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #ifdef CONFIG_X86
> #include
> @@ -1243,6 +1245,17 @@ void xen_evtchn_do_upcall
On 20/02/15 01:49, Linus Torvalds wrote:
> On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
> wrote:
>> I'm feeling I miss very basic background on how Xen works, but why does it
>> set _PAGE_GLOBAL on userspace entries? It sounds strange to me.
> It is definitely strange. I'm guessing that it'
On 20/02/15 11:29, Kirill A. Shutemov wrote:
> On Fri, Feb 20, 2015 at 10:47:52AM +0000, Andrew Cooper wrote:
>> On 20/02/15 01:49, Linus Torvalds wrote:
>>> On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
>>> wrote:
>>>> I'm feeling I miss very bas
On 18/02/15 10:42, Juergen Gross wrote:
>
>>> /* Set up p2m_top to point to the domain-builder provided p2m
>>> pages */
>>> @@ -469,8 +473,10 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
>>> pte_t *pte_pg)
>>>
>>> ptechk = lookup_address(vaddr, &level);
>>> if (ptechk =
On 18/02/15 10:54, David Vrabel wrote:
> On 18/02/15 10:50, Andrew Cooper wrote:
>> On 18/02/15 10:42, Juergen Gross wrote:
>>>>> /* Set up p2m_top to point to the domain-builder provided p2m
>>>>> pages */
>>>>> @@ -469,8 +473,10 @@ stati
On 08/04/2016 01:24, Andy Lutomirski wrote:
> I can't see any reason that we need the __KERNEL_DS segment at all --
> I think that everything that uses __KERNEL_DS could use __USER_DS
> instead. Am I missing anything? This has been bugging me for a
> while.
>
> I mulled over this a bit when tryin
On 08/04/16 23:06, Andy Lutomirski wrote:
> On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini wrote:
>>
>> On 08/04/2016 18:00, Andy Lutomirski wrote:
>>> But %ss can be loaded with 0 on 64-bit kernels. (I assume that
>>> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on
>>> this
On 24/11/15 10:17, Petr Tesarik wrote:
> On Tue, 24 Nov 2015 10:09:01 +
> David Vrabel wrote:
>
>> On 24/11/15 09:55, Malcolm Crossley wrote:
>>> On 24/11/15 08:59, Jan Beulich wrote:
>>> On 24.11.15 at 07:55, wrote:
> What about:
>
> 4) Instead of relying on the kernel mainta
Ping?
None of the discussion on this thread altered the contents of this
patch, and the bug is still present.
~Andrew
On 03/06/15 10:31, Andrew Cooper wrote:
> There appears to be no formal statement of what pv_irq_ops.save_fl() is
> supposed to return precisely. Native returns the full
On 17/11/15 18:49, Andy Lutomirski wrote:
> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" wrote:
>> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
>>> On 11/16/15 12:22, Borislav Petkov wrote:
Huh, so what's wrong with a jump:
jmp 1f
swapgs
1:
>>>
On 17/11/15 19:16, Andy Lutomirski wrote:
> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
> wrote:
>> On 17/11/15 18:49, Andy Lutomirski wrote:
>>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky"
>>> wrote:
>>>> On 11/16/2015 04:55 PM, H. Peter A
On 06/09/2019 15:01, Christoph Hellwig wrote:
> On Fri, Sep 06, 2019 at 09:52:12AM -0400, Boris Ostrovsky wrote:
>> We need nop definitions of these two for x86.
>>
>> Everything builds now but that's probably because the calls are under
>> 'if (!dev_is_dma_coherent(dev))' which is always false so
On 06/09/2019 16:39, Arnd Bergmann wrote:
> HYPERVISOR_platform_op() is an inline function and should not
> be exported. Since commit 15bfc2348d54 ("modpost: check for
> static EXPORT_SYMBOL* functions"), this causes a warning:
>
> WARNING: "HYPERVISOR_platform_op" [vmlinux] is a static EXPORT_SYMB
On 06/09/2019 17:00, Arnd Bergmann wrote:
> On Fri, Sep 6, 2019 at 5:55 PM Andrew Cooper
> wrote:
>> On 06/09/2019 16:39, Arnd Bergmann wrote:
>>> HYPERVISOR_platform_op() is an inline function and should not
>>> be exported. Since commit 15bfc2348d54 (
On 04/09/2019 12:45, Masami Hiramatsu wrote:
> Hi,
>
> These patches allow x86 instruction decoder to decode
> xen-cpuid which has XEN_EMULATE_PREFIX, and prohibit
> kprobes to probe on it.
>
> Josh reported that the objtool can not decode such special
> prefixed instructions, and I found that we a
On 05/09/2019 02:49, Masami Hiramatsu wrote:
> On Wed, 4 Sep 2019 12:54:55 +0100
> Andrew Cooper wrote:
>
>> On 04/09/2019 12:45, Masami Hiramatsu wrote:
>>> Hi,
>>>
>>> These patches allow x86 instruction decoder to decode
>>> xen-cpuid which
On 05/09/2019 09:26, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote:
>
>> I don't know if you've spotted, but the prefix is a ud2a instruction
>> followed by 'xen' in ascii.
>>
>> The KVM version was add
On 05/09/2019 10:26, Peter Zijlstra wrote:
> On Thu, Sep 05, 2019 at 09:53:32AM +0100, Andrew Cooper wrote:
>> On 05/09/2019 09:26, Peter Zijlstra wrote:
>>> On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote:
>>>
>>>> I don't know if you'
On 05/09/2019 14:09, Masami Hiramatsu wrote:
> On Thu, 5 Sep 2019 20:32:24 +0900
> Masami Hiramatsu wrote:
>
>> On Thu, 5 Sep 2019 08:54:17 +0100
>> Andrew Cooper wrote:
>>
>>> On 05/09/2019 02:49, Masami Hiramatsu wrote:
>>>> On Wed, 4 S
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: virtualizat...@lists.linux-foundation.org
CC: Bor
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
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 18/07/2019 07:52, Juergen Gross wrote:
> Today there is a global limit of pages mapped via /dev/xen/gntdev set
> to 1 million pages per default.
The Xen default limit even for dom0 is 1024 pages * 16 entries per page,
which is far lower than this limit.
> There is no reason why that limit is
>
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 09/02/2019 18:54, Linus Torvalds wrote:
> On Sat, Feb 9, 2019 at 12:24 AM Sander Eikelenboom
> wrote:
>> I haven't got a reproducer so i might be hard to hit it again,
>> system is AMD and this is from the host kernel running under
>> the Xen hypervisor might it matter.
> I think this is a Xen
On 17/01/2019 00:00, Andy Lutomirski wrote:
> On Wed, Jan 16, 2019 at 1:24 PM Fenghua Yu wrote:
>> IA32_UMWAIT_CONTROL[31:2] determines the maximum time in TSC-quanta
>> that processor can stay in C0.1 or C0.2.
>>
>> The maximum time value in IA32_UMWAIT_CONTROL[31-2] is set as zero which
>> means
On 11/07/2019 03:15, Zhenzhong Duan wrote:
> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
> selftest") is used to ensure there is a gap setup in exception stack
> which could be used for inserting call return address.
>
> This gap is missed in XEN PV int3 exception entry path, th
On 15/07/2019 07:54, Jan Beulich wrote:
> On 15.07.2019 07:05, Zhenzhong Duan wrote:
>> On 2019/7/12 22:06, Andrew Cooper wrote:
>>> On 11/07/2019 03:15, Zhenzhong Duan wrote:
>>>> Commit 7457c0da024b ("x86/alternatives: Add int3_emulate_call()
>>>&
chance that a certain class of device malfunctions crashes the
>> kernel in hard-to-debug ways.
>>
>> Cc: Nadav Amit
>> Cc: Stephane Eranian
>> Cc: Feng Tang
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Andy Lutomirski
>> ---
>> arch
, which allows for the removal
of both PVOPS.
Signed-off-by: Andrew Cooper
---
CC: x...@kernel.org
CC: virtualizat...@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 04/07/2019 16:51, Thomas Gleixner wrote:
> 2) The loop termination logic is interesting at best.
>
> If the machine has no TSC or cpu_khz is not known yet it tries 1
> million times to ack stale IRR/ISR bits. What?
>
> With TSC it uses the TSC to calculate the loop termination.
On 05/07/2019 20:06, Andy Lutomirski wrote:
> On Fri, Jul 5, 2019 at 8:47 AM Andrew Cooper
> wrote:
>> On 04/07/2019 16:51, Thomas Gleixner wrote:
>>> 2) The loop termination logic is interesting at best.
>>>
>>> If the machine has no TSC
On 05/07/2019 20:19, Nadav Amit wrote:
>> On Jul 5, 2019, at 8:47 AM, Andrew Cooper wrote:
>>
>> On 04/07/2019 16:51, Thomas Gleixner wrote:
>>> 2) The loop termination logic is interesting at best.
>>>
>>> If the machine has no TSC or cpu_kh
On 05/07/2019 21:49, Paolo Bonzini wrote:
> On 05/07/19 22:25, Thomas Gleixner wrote:
>> In practice, this makes Linux vulnerable to CVE-2011-1898 / XSA-3, which
>> I'm disappointed to see wasn't shared with other software vendors at the
>> time.
> Oh, that brings back memories. At the time I was
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
thing, but a gradual "let's stop
>>> supporting xyz under PV, because it causes pain and isn't worth it".
>> So Juergen recently introduced PARAVIRT_XXL, which are exactly those
>> bits of PV we can get rid of.
>>
>> This paravirt-me-harder config d
On 09/05/18 11:21, Roger Pau Monne wrote:
> On PVH MTRR is not initialized by the firmware (because there's no
> firmware), so the kernel is started with MTRR disabled which means all
> memory accesses are UC.
>
> So far there have been no issues (ie: slowdowns) caused by this
> because PVH only su
On 07/07/16 10:45, Roger Pau Monne wrote:
> On Thu, Jul 07, 2016 at 01:38:58AM -0600, Jan Beulich wrote:
>> The functions such get passed to have been taking pointers to const
>> since at least 2.6.16.
>>
>> Signed-off-by: Jan Beulich
> Acked-by: Roger Pau Monné
>
> Although the wording in the co
On 27/10/16 15:25, Boris Ostrovsky wrote:
>
>
> On 10/14/2016 03:01 PM, Boris Ostrovsky wrote:
>> On 10/14/2016 02:41 PM, Andrew Cooper wrote:
>>> On 14/10/16 19:05, Boris Ostrovsky wrote:
>>>> PVH guests don't receive ACPI hotplug interrupts and theref
On 10/10/16 01:35, Haozhong Zhang wrote:
> Overview
>
> This RFC kernel patch series along with corresponding patch series of
> Xen, QEMU and ndctl implements Xen vNVDIMM, which can map the host
> NVDIMM devices to Xen HVM domU as vNVDIMM devices.
>
> Xen hypervisor does not include an NVD
On 11/10/16 18:51, Dan Williams wrote:
> On Tue, Oct 11, 2016 at 9:58 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Tue, Oct 11, 2016 at 08:53:33AM -0700, Dan Williams wrote:
>>> On Tue, Oct 11, 2016 at 6:08 AM, Jan Beulich wrote:
>>>>>>> Andrew Cooper 10
On 11/10/16 06:52, Haozhong Zhang wrote:
> On 10/10/16 17:43, Andrew Cooper wrote:
>> On 10/10/16 01:35, Haozhong Zhang wrote:
>>> Overview
>>>
>>> This RFC kernel patch series along with corresponding patch series of
>>> Xen, QEMU and ndctl i
On 11/10/16 20:48, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 11, 2016 at 12:28:56PM -0700, Dan Williams wrote:
>> On Tue, Oct 11, 2016 at 11:33 AM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Tue, Oct 11, 2016 at 10:51:19AM -0700, Dan Williams wrote:
>> [..]
Right, but why does the libnvdimm core
101 - 200 of 315 matches
Mail list logo
