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!
[
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 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 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
On 29/07/2015 01:21, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 10:10 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/28/2015 01:07 PM, Andy Lutomirski wrote:
On Tue, Jul 28, 2015 at 9:30 AM, Andrew Cooper
andrew.coop...@citrix.com wrote:
I suspect that the set_ldt(NULL, 0
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] [ cut here ]
[ 53.986314] kernel BUG at arch/x86/xen
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
Xen. After several tries, I got:
[ 53.985707
On 28/07/15 04:16, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 7:20 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Jul 27, 2015 at 9:18 AM, Boris Ostrovsky
boris.ostrov...@oracle.com wrote:
On 07/27/2015 11:53 AM, Andy Lutomirski wrote:
On Mon, Jul 27, 2015 at 8:36 AM, Boris
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.986677] invalid opcode:
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
the
first
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
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_SYSRET hooks entirely.
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 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
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_OFF/ON,
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
pushq%rax
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/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 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
>> /*
>> + *
On 22/07/2015 01:07, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
andrew.coop...@citrix.com 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
On 22/07/2015 01:28, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 5:21 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 22/07/2015 01:07, Andy Lutomirski wrote:
On Tue, Jul 21, 2015 at 4:38 PM, Andrew Cooper
andrew.coop...@citrix.com wrote:
On 21/07/2015 22:53, Boris Ostrovsky 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_structs can be
On 04/06/15 07:38, H. Peter Anvin wrote:
> On 06/03/2015 02:31 AM, 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 flags, while lguest
>> and
>> Xen only return t
On 04/06/15 07:38, H. Peter Anvin wrote:
On 06/03/2015 02:31 AM, 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 flags, while lguest
and
Xen only return the Interrupt Flag, and both have
, but not consistent for all builds. It has also been a sitting timebomb
since SMAP support was introduced.
Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.
Signed-off-by: Andrew Cooper
Reviewed-by: David Vrabel
Tested-by: Rusty Russell
CC: Thomas Gleixner
CC: Ingo
, but not consistent for all builds. It has also been a sitting timebomb
since SMAP support was introduced.
Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
Reviewed-by: David Vrabel david.vra...@citrix.com
Tested
On 30/05/15 16:39, Mikko Rapeli wrote:
> privcmd.h depends on xen/interface/xen.h which is now exported to userspace.
> xen/interface/xen.h then depends on asm/xen/interface.h which is now
> exported to userspace together with its dependencies asm/xen/interface_32.h,
> asm/xen/interface_64.h and
On 30/05/15 16:39, Mikko Rapeli wrote:
privcmd.h depends on xen/interface/xen.h which is now exported to userspace.
xen/interface/xen.h then depends on asm/xen/interface.h which is now
exported to userspace together with its dependencies asm/xen/interface_32.h,
asm/xen/interface_64.h and
On 21/04/2015 01:35, Andy Lutomirski wrote:
> On 04/20/2015 10:09 AM, 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 flags, while
>> lguest and
>> Xen only return t
On 21/04/2015 01:35, Andy Lutomirski wrote:
On 04/20/2015 10:09 AM, 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 flags, while
lguest and
Xen only return the Interrupt Flag, and both have
, but not consistent for all builds. It has also been a sitting timebomb
since SMAP support was introduced.
Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.
Signed-off-by: Andrew Cooper
CC: Thomas Gleixner
CC: Ingo Molnar
CC: H. Peter Anvin
CC: x...@kernel.org
CC
, but not consistent for all builds. It has also been a sitting timebomb
since SMAP support was introduced.
Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.
Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
CC: Thomas Gleixner t...@linutronix.de
CC: Ingo Molnar mi
On 06/04/2015 16:29, Andy Lutomirski wrote:
> On Mon, Apr 6, 2015 at 7:10 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Apr 03, 2015 at 03:52:30PM -0700, Andy Lutomirski wrote:
>>> [cc: Boris and Konrad. Whoops]
>>>
>>> On Fri, Apr 3, 2015 at 3:51 PM, Andy Lutomirski wrote:
We don't use
On 06/04/2015 16:29, Andy Lutomirski wrote:
On Mon, Apr 6, 2015 at 7:10 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Apr 03, 2015 at 03:52:30PM -0700, Andy Lutomirski wrote:
[cc: Boris and Konrad. Whoops]
On Fri, Apr 3, 2015 at 3:51 PM, Andy Lutomirski l...@kernel.org
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 basic ba
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
On 20/02/15 11:29, Kirill A. Shutemov wrote:
On Fri, Feb 20, 2015 at 10:47:52AM +, Andrew Cooper wrote:
On 20/02/15 01:49, Linus Torvalds wrote:
On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
kir...@shutemov.name wrote:
I'm feeling I miss very basic background on how Xen works
On 20/02/15 01:49, Linus Torvalds wrote:
On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
kir...@shutemov.name 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
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 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, );
>>> if (ptechk ==
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 == pte_pg) {
+
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 @@ static pte_t *alloc_p2m_pmd(unsigned long addr,
pte_t *pte_pg
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, wrote:
> Even if David told you this would be acceptable, I have to question
> an abstract model of fixing issues on only 64-bit kernels - this may
> be acceptable for distro purposes, but seems hardly the right
> approach for
On 27/01/15 08:35, Jan Beulich wrote:
On 27.01.15 at 02:51, mcg...@do-not-panic.com wrote:
Even if David told you this would be acceptable, I have to question
an abstract model of fixing issues on only 64-bit kernels - this may
be acceptable for distro purposes, but seems hardly the right
On 22/01/2015 20:58, Andy Lutomirski wrote:
> On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt wrote:
>> On Thu, 22 Jan 2015 12:24:47 -0800
>> Andy Lutomirski wrote:
>>
Also, please remove the "notrace", because function tracing goes an
extra step to not require RCU being visible. The
ondary hypercall page, calls made via
>>>>> the new page may be preempted.
>>>>>
>>>>> Andrew had originally submitted a version of this work [0].
>>>>>
>>>>> [0] http://lists.xen.org/archives/html/xen-devel/2014-02/msg01056.
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
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 linux/slab.h
#include linux/irqnr.h
#include linux/pci.h
+#include linux/sched.h
+#include linux/kprobes.h
#ifdef CONFIG_X86
On 22/01/2015 20:58, Andy Lutomirski wrote:
On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt rost...@goodmis.org wrote:
On Thu, 22 Jan 2015 12:24:47 -0800
Andy Lutomirski l...@amacapital.net wrote:
Also, please remove the notrace, because function tracing goes an
extra step to not require
that by adding a secondary hypercall page, calls made via
the new page may be preempted.
Andrew had originally submitted a version of this work [0].
[0] http://lists.xen.org/archives/html/xen-devel/2014-02/msg01056.html
Based on original work by: Andrew Cooper andrew.coop...@citrix.com
Cc
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 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 konrad.w...@oracle.com
Reviewed-by: Andrew Cooper andrew.coop
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 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 mcg...@suse.com
Some folks had reported that some xen hypercalls take a long time
to complete when issued from
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 <<
On 12/11/14 15:55, Jan Beulich wrote:
On 12.11.14 at 16:25, david.vra...@citrix.com 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
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 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;
}
+static
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/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
>
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
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 physical addresses
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
increased
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 the p2m list on 32-bit pv domains a problem or not?
I
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
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 this
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 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, andrew.coop...@citrix.com 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
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
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 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 a domain
On 04/09/14 15:31, Jan Beulich wrote:
On 04.09.14 at 15:02, andrew.coop...@citrix.com 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
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 @@
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(startup_xen)
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
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
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 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 bef
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. I'll replace the WARN_ON in vmalloc that triggers by a
panic
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... but then I think I know what I do next. Probably
should
have
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 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
dig
in there
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
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 bit
On 09/07/14 15:13, Konrad Rzeszutek Wilk wrote:
> On Wed, Jul 09, 2014 at 03:05:56PM +0100, Andrew Cooper wrote:
>> On 09/07/14 14:59, Konrad Rzeszutek Wilk wrote:
>>>>> +What: /sys/bus/pci/drivers/pciback/irq_handler_state
>>>>> +Date:
On 09/07/14 14:59, Konrad Rzeszutek Wilk wrote:
>
>>> +What: /sys/bus/pci/drivers/pciback/irq_handler_state
>>> +Date: Oct 2011
>>> +KernelVersion: 3.1
>>> +Contact:xen-de...@lists.xenproject.org
>>> +Description:
>>> +An option to toggle Xen PCI back
On 09/07/14 14:59, Konrad Rzeszutek Wilk wrote:
+What: /sys/bus/pci/drivers/pciback/irq_handler_state
+Date: Oct 2011
+KernelVersion: 3.1
+Contact:xen-de...@lists.xenproject.org
+Description:
+An option to toggle Xen PCI back to acknowledge (or
On 09/07/14 15:13, Konrad Rzeszutek Wilk wrote:
On Wed, Jul 09, 2014 at 03:05:56PM +0100, Andrew Cooper wrote:
On 09/07/14 14:59, Konrad Rzeszutek Wilk wrote:
+What: /sys/bus/pci/drivers/pciback/irq_handler_state
+Date: Oct 2011
+KernelVersion: 3.1
+Contact:xen
On 08/07/14 19:58, kon...@kernel.org wrote:
> From: Konrad Rzeszutek Wilk
>
> Which hadn't been done with the initial commit.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> Documentation/ABI/testing/sysfs-driver-pciback | 84
>
> 1 files changed, 84 insertions(+),
On 08/07/14 19:58, kon...@kernel.org wrote:
> From: Konrad Rzeszutek Wilk
>
> The life-cycle of a PCI device in Xen pciback is complex
> and is constrained by the PCI generic locking mechanism.
>
> It starts with the device being binded to us - for which
"being bound to us"
~Andrew
--
To
On 08/07/14 19:58, kon...@kernel.org wrote:
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
The life-cycle of a PCI device in Xen pciback is complex
and is constrained by the PCI generic locking mechanism.
It starts with the device being binded to us - for which
being bound to us
On 08/07/14 19:58, kon...@kernel.org wrote:
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Which hadn't been done with the initial commit.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
Documentation/ABI/testing/sysfs-driver-pciback | 84
On 16/05/14 21:41, Daniel Kiper wrote:
> @@ -0,0 +1,374 @@
> +/*
> + * EFI support for Xen.
> + *
> + * Copyright (C) 1999 VA Linux Systems
> + * Copyright (C) 1999 Walt Drummond
> + * Copyright (C) 1999-2002 Hewlett-Packard Co.
> + * David Mosberger-Tang
> + * Stephane Eranian
> + *
On 16/05/14 21:41, Daniel Kiper wrote:
@@ -0,0 +1,374 @@
+/*
+ * EFI support for Xen.
+ *
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond drumm...@valinux.com
+ * Copyright (C) 1999-2002 Hewlett-Packard Co.
+ * David Mosberger-Tang dav...@hpl.hp.com
+ *
On 09/04/14 15:29, David Vrabel wrote:
> On 09/04/14 15:21, Jan Beulich wrote:
> On 09.04.14 at 16:06, wrote:
>>> --- a/arch/x86/xen/xen-asm_32.S
>>> +++ b/arch/x86/xen/xen-asm_32.S
>>> @@ -88,7 +88,11 @@ ENTRY(xen_iret)
>>> * avoid having to reload %fs
>>> */
>>> #ifdef CONFIG_SMP
On 09/04/14 15:29, David Vrabel wrote:
On 09/04/14 15:21, Jan Beulich wrote:
On 09.04.14 at 16:06, boris.ostrov...@oracle.com wrote:
--- a/arch/x86/xen/xen-asm_32.S
+++ b/arch/x86/xen/xen-asm_32.S
@@ -88,7 +88,11 @@ ENTRY(xen_iret)
* avoid having to reload %fs
*/
#ifdef
On 26/03/2014 22:01, Daniel Kiper wrote:
> On Wed, Mar 26, 2014 at 01:57:23PM +, Matt Fleming wrote:
>> On Wed, 26 Mar, at 02:48:45PM, Daniel Kiper wrote:
>>> On my machine this function crashes on Xen so that is why I have changed
>>> condition. However, if you say that this issue could be
On 26/03/2014 22:01, Daniel Kiper wrote:
On Wed, Mar 26, 2014 at 01:57:23PM +, Matt Fleming wrote:
On Wed, 26 Mar, at 02:48:45PM, Daniel Kiper wrote:
On my machine this function crashes on Xen so that is why I have changed
condition. However, if you say that this issue could be solved in
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
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 out
The
401 - 500 of 522 matches
Mail list logo
