[Xen-devel] [PATCH for-next v2 01/10] x86/mm: make free_perdomain_mappings idempotent

Signed-off-by: Wei Liu --- Cc: Tim Deegan Cc: George Dunlap Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/mm.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff

[Xen-devel] [PATCH for-next v2 08/10] x86/domain: factor out pv_domain_initialise

Lump everything PV related in arch_domain_create into pv_domain_initialise. Though domcr_flags and config are not necessary, the new function is given those to match hvm counterpart. Since it cleans up after itself there is no need to clean up in arch_domain_create in case of failure. Remove the

[Xen-devel] [PATCH for-next v2 00/10] x86: refactor x86/domain.c

Can be found at https://xenbits.xen.org/git-http/people/liuw/xen.git wip.x86-domain-v2 Cc: Jan Beulich Cc: Andrew Cooper Cc: Tim Deegan Cc: George Dunlap Wei Liu (10): x86/mm: make

[Xen-devel] [PATCH for-next v2 04/10] x86/domain: factor out pv_vcpu_destroy

The function is made idempotent on purpose. No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/domain.c | 20 1 file changed, 12 insertions(+), 8

[Xen-devel] [PATCH for-next v2 06/10] x86/domain: push some code down to hvm_domain_initialise

We want to have a single entry point to initialise hvm guest. Now the timing to set hap bit and create per domain mapping is deferred, but that's not a problem. No functional change. Signed-off-by: Wei Liu --- v2: 1. reorder things to avoid rename labels 2. add config to

[Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

Move PV specific vcpu initialisation code to said function, but leave the only line needed by idle domain in vcpu_initialise. Use pv_vcpu_destroy in error path to simplify code. It is safe to do so because the destruction function accepts partially initialised vcpu struct. Signed-off-by: Wei Liu

[Xen-devel] [PATCH for-next v2 02/10] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

This patch encapsulates the perdomain creation and destruction into helper functions and use them where appropriate. Since destroy_perdomain_mapping is idempotent, it is safe to call the destruction function multiple times. Signed-off-by: Wei Liu --- Cc: Jan Beulich

[Xen-devel] [PATCH for-next v2 03/10] x86/domain: make release_compact_l4 NULL tolerant

Push the check in caller down to that function so that it becomes idempotent. No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/domain.c | 7 +++ 1 file changed, 3

[Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

Move all the PV specific code along with the supporting code to pv/domain.c. This in turn requires exporting a few functions in header files. Create pv/domain.h for that. No functional change. Signed-off-by: Wei Liu --- Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [ovmf baseline-only test] 71229: all pass

This run is configured for baseline tests only. flight 71229 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71229/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d5a67b3da18f815c83593d9329a353ec3a739d66 baseline

Re: [Xen-devel] [PATCH for-next 6/8] x86/domain: factor out pv_domain_initialise

On Mon, Apr 24, 2017 at 04:20:36AM -0600, Jan Beulich wrote: > > +if ( d->arch.pv_domain.gdt_ldt_l1tab ) > > +{ > > +free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab); > > +d->arch.pv_domain.gdt_ldt_l1tab = NULL; > > +} > > + > > +if ( d->arch.pv_domain.cpuidmasks

Re: [Xen-devel] [PATCH v2 8/9] vpci/msi: add MSI handlers

On Tue, Apr 25, 2017 at 01:00:06PM +0100, Julien Grall wrote: > Hi Roger, > > On 25/04/17 12:49, Roger Pau Monne wrote: > > On Mon, Apr 24, 2017 at 04:31:57PM +0100, Julien Grall wrote: > > > > +static int vpci_init_msi(struct pci_dev *pdev) > > > > +{ > > > > +uint8_t seg = pdev->seg, bus =

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

le: device id = >> 0x700, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3 >> (XEN) [2017-04-25 10:25:25.331] AMD-Vi: Setup I/O page table: device id = >> 0x800, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3 >> (XEN) [2017-04-25 10:25:25.3

[Xen-devel] Release manager deputy for Xen 4.9 rc3

Hi all, I will be away from tomorrow (26th April) until the 1rst of May. Ian Jackson volunteered to handle the release management for Xen 4.9 rc3 (expected on Friday 28th April). When sending a patch for Xen 4.9, please CC relevant maintainers, him (ian.jack...@eu.citrix.com) and me

Re: [Xen-devel] [PATCH] xen/blkback: fix disconnect while I/Os in flight

On Fri, Apr 21, 2017 at 10:51:00AM +0200, Juergen Gross wrote: > Today disconnecting xen-blkback is broken in case there are still > I/Os in flight: xen_blkif_disconnect() will bail out early without > releasing all resources in the hope it will be called again when > the last request has

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

Hi Stefano, On 24/04/17 20:16, Stefano Stabellini wrote: Given the outstanding regression we need to fix as soon as possible, I'll queue these patches on the xentip tree for 4.12. It looks like there is another rc for 4.11. I am wondering whether you could try to send a pull request to Linus

[Xen-devel] Xen Debugging through Lauterbach on ARMv8

Hello, Has anybody even debugged xen via Lauterbach on ARMv8? Any Help would be appreciated. Best regards Amna ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

root table = 0x441ddb000, domain = 0, paging mode = 3 > (XEN) [2017-04-25 10:25:25.447] AMD-Vi: Setup I/O page table: device id = > 0xa04, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3 > (XEN) [2017-04-25 10:25:25.465] AMD-Vi: Setup I/O page table: device id = >

Re: [Xen-devel] [for-4.9] 8250-uart: Fix typo in the header

>>> On 25.04.17 at 14:36, wrote: > --- a/xen/include/xen/8250-uart.h > +++ b/xen/include/xen/8250-uart.h > @@ -42,7 +42,7 @@ > #define UART_IER_ELSI 0x04/* rx line status */ > #define UART_IER_EMSI 0x08/* MODEM status */ > > -/* Interrupt

Re: [Xen-devel] [for-4.9] 8250-uart: Fix typo in the header

On 25/04/17 13:36, Julien Grall wrote: > Signed-off-by: Julien Grall Acked-by: Andrew Cooper and queued. > --- > xen/include/xen/8250-uart.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/xen/8250-uart.h

[Xen-devel] [for-4.9] 8250-uart: Fix typo in the header

Signed-off-by: Julien Grall --- xen/include/xen/8250-uart.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h index c6b62c8cf4..632aa527f2 100644 --- a/xen/include/xen/8250-uart.h +++

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

On 25/04/17 13:20, Vijay Kilari wrote: On Tue, Apr 25, 2017 at 5:34 PM, Julien Grall wrote: Hello Vijay, On 25/04/17 07:54, Vijay Kilari wrote: On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall wrote: Hi Vijay, On 28/03/17 16:53,

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

On Tue, Apr 25, 2017 at 5:34 PM, Julien Grall wrote: > Hello Vijay, > > On 25/04/17 07:54, Vijay Kilari wrote: >> >> On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall >> wrote: >>> >>> Hi Vijay, >>> >>> On 28/03/17 16:53, vijay.kil...@gmail.com wrote:

Re: [Xen-devel] [PATCH for-next 4/8] x86/domain: push some code down to hvm_domain_initialise

On Mon, Apr 10, 2017 at 04:19:12PM +0100, Andrew Cooper wrote: > On 10/04/17 14:27, Wei Liu wrote: > > We want to have a single entry point to initialise hvm guest. The > > timing to set hap bit and create per domain mapping is deferred, but > > that's not a problem. > > > > No functional change.

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

Hello Vijay, On 25/04/17 07:54, Vijay Kilari wrote: On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall wrote: Hi Vijay, On 28/03/17 16:53, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Add accessor functions for acpi_numa and numa_off static

Re: [Xen-devel] [PATCH v2 8/9] vpci/msi: add MSI handlers

Hi Roger, On 25/04/17 12:49, Roger Pau Monne wrote: On Mon, Apr 24, 2017 at 04:31:57PM +0100, Julien Grall wrote: +static int vpci_init_msi(struct pci_dev *pdev) +{ +uint8_t seg = pdev->seg, bus = pdev->bus; +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn); +

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

>>> On 25.04.17 at 12:59, wrote: > Hi, > > At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: >> Jann's explanation of the problem: >> >> "start situation: >> - domain A and domain B are PV domains >> - domain A and B both have currently scheduled vCPUs, and the vCPUs >>

Re: [Xen-devel] [PATCH 06/10] xen/arm: vpl011: Add new parameters to xenstore for the virtual console

On Tue, Apr 25, 2017 at 03:48:47PM +0530, Bhupinder Thakur wrote: > Hi Wei, > > > >> } > >> @@ -3159,6 +3162,13 @@ int libxl__device_console_add(libxl__gc *gc, > >> uint32_t domid, > >> flexarray_append(ro_front, GCSPRINTF("%"PRIu32, > >> state->console_port)); > >>

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 13:38, Juergen Gross wrote: > On 25/04/17 13:28, Sander Eikelenboom wrote: >> On 25/04/17 13:00, Juergen Gross wrote: >>> On 25/04/17 12:33, Sander Eikelenboom wrote: On 25/04/17 09:01, Juergen Gross wrote: > On 25/04/17 08:57, Sander Eikelenboom wrote: >> On 25/04/17

Re: [Xen-devel] [PATCH v2 8/9] vpci/msi: add MSI handlers

On Mon, Apr 24, 2017 at 04:31:57PM +0100, Julien Grall wrote: > Hi Roger, > > On 20/04/17 16:17, Roger Pau Monne wrote: > > diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c > > new file mode 100644 > > index 00..aea6c68907 > > --- /dev/null > > +++ b/xen/drivers/vpci/msi.c > >

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

On 24/04/17 22:41, Volodymyr Babchuk wrote: Julien, Hi Volodymyr, We will also need another type of application: one which is periodically called by XEN itself, not actually servicing any domain request. This is needed for a coprocessor sharing framework scheduler implementation. EL0

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 13:28, Sander Eikelenboom wrote: > On 25/04/17 13:00, Juergen Gross wrote: >> On 25/04/17 12:33, Sander Eikelenboom wrote: >>> On 25/04/17 09:01, Juergen Gross wrote: On 25/04/17 08:57, Sander Eikelenboom wrote: > On 25/04/17 08:42, Juergen Gross wrote: >> On 25/04/17

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 13:00, Juergen Gross wrote: > On 25/04/17 12:33, Sander Eikelenboom wrote: >> On 25/04/17 09:01, Juergen Gross wrote: >>> On 25/04/17 08:57, Sander Eikelenboom wrote: On 25/04/17 08:42, Juergen Gross wrote: > On 25/04/17 08:35, Sander Eikelenboom wrote: >> (XEN)

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

LE(1b, 3b) >>> : [err] "=r" (err), "=a" (eax), "=d" (edx) >>> : "c" (0)); >>> >>> return err == 0; >> >> I hoped so. :-) >> >> I posted a patch to repair

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 12:33, Sander Eikelenboom wrote: > On 25/04/17 09:01, Juergen Gross wrote: >> On 25/04/17 08:57, Sander Eikelenboom wrote: >>> On 25/04/17 08:42, Juergen Gross wrote: On 25/04/17 08:35, Sander Eikelenboom wrote: > (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode

Re: [Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

Hi, At 02:59 -0600 on 25 Apr (1493089158), Jan Beulich wrote: > Jann's explanation of the problem: > > "start situation: > - domain A and domain B are PV domains > - domain A and B both have currently scheduled vCPUs, and the vCPUs >are not scheduled away > - domain A has XSM_TARGET

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

-Vi: Setup I/O page table: device id = 0xf00, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3 (XEN) [2017-04-25 10:25:25.610] AMD-Vi: Setup I/O page table: device id = 0xf01, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3 (XEN) [2017-04-25 10:25:25

[Xen-devel] [qemu-mainline test] 107636: tolerable FAIL - PUSHED

flight 107636 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/107636/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 107610 test-armhf-armhf-libvirt-xsm 13

Re: [Xen-devel] [PATCH 06/10] xen/arm: vpl011: Add new parameters to xenstore for the virtual console

Hi Wei, >> } >> @@ -3159,6 +3162,13 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t >> domid, >> flexarray_append(ro_front, GCSPRINTF("%"PRIu32, >> state->console_port)); >> flexarray_append(ro_front, "ring-ref"); >> flexarray_append(ro_front,

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Dear Stefano, Thank you for such a wide explanation. I have to read it carefully and consider it. Also some internal discussion is needed. So I'll get back later with comments. -- *Andrii Anisov* ___ Xen-devel mailing list

[Xen-devel] [ovmf test] 107641: all pass - PUSHED

flight 107641 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/107641/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf d5a67b3da18f815c83593d9329a353ec3a739d66 baseline version: ovmf

Re: [Xen-devel] [PATCH v2 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

>>> On 25.04.17 at 11:25, wrote: > On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote: >> My understanding is BARs may be allocated by the kernel because the firmware >> didn't do it. This is the current case on ARM (and I guess x86) where Linux >> will always go

Re: [Xen-devel] [PATCH v2 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

On Tue, Apr 25, 2017 at 10:09:34AM +0100, Julien Grall wrote: > On 25/04/2017 09:01, Roger Pau Monne wrote: > > On Mon, Apr 24, 2017 at 03:42:08PM +0100, Julien Grall wrote: > > > On 20/04/17 16:17, Roger Pau Monne wrote: > > > > +unsigned long nr_pages, const bool map) > > > > +{

Re: [Xen-devel] [PATCH v2 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

Hi Roger, On 25/04/2017 09:01, Roger Pau Monne wrote: On Mon, Apr 24, 2017 at 03:42:08PM +0100, Julien Grall wrote: On 20/04/17 16:17, Roger Pau Monne wrote: /* Populate a HVM memory range using the biggest possible order. */ diff --git a/xen/common/memory.c b/xen/common/memory.c index

[Xen-devel] [PATCH] x86emul: correct stub invocation constraints

Stub invocations need to have the space the stub occupies as an input, to prevent the compiler from re-ordering (or omitting) writes to it. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -837,7 +837,8 @@

[Xen-devel] [PATCH] x86/32on64: properly honor add-to-physmap-batch's size

Commit 407a3c00ff ("compat/memory: fix build with old gcc") "fixed" a build issue by switching to the use of uninitialized data. Due to - the bounding of the uninitialized data item - the accessed area being outside of Xen space - arguments being properly verified by the native hypercall function

Re: [Xen-devel] [PATCH] xen: Revert commits da72ff5bfcb0 and 72a9b186292d

On 24/04/17 21:04, Boris Ostrovsky wrote: > Recent discussion (http://marc.info/?l=xen-devel=149192184523741) > established that commit 72a9b186292d ("xen: Remove event channel > notification through Xen PCI platform device") (and thus commit > da72ff5bfcb0 ("partially revert "xen: Remove event

[Xen-devel] [PATCH v2] x86/mm: also flush TLB when putting writable foreign page reference

Jann's explanation of the problem: "start situation: - domain A and domain B are PV domains - domain A and B both have currently scheduled vCPUs, and the vCPUs are not scheduled away - domain A has XSM_TARGET access to domain B - page X is owned by domain B and has no mappings - page X is

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

Dear Julien, I just read Volodymyr's emails, looked through his code and we had a discussion. So I'm not ready to present technical details. I guess Volodymyr is a right person while he is up to this topic. On 24.04.17 22:11, Julien Grall wrote: Do you have numbers for part that take times

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

On 17-04-25 02:24:40, Jan Beulich wrote: > >>> On 25.04.17 at 09:15, wrote: > > Sorry, this may cause potential issue and is not a good example. But from SW > > view, there is another case where the per-socket supporting is important in > > real-time scenarios. You may

Re: [Xen-devel] [PATCH for-4.9] x86/mm: Add missing newline to a printk() in get_page_from_l1e()

>>> On 24.04.17 at 19:13, wrote: > This avoids the log message being followed by > > <1>mm.c:5374:d0v0 could not get_page_from_l1e() > > Signed-off-by: Andrew Cooper Acked-by: Jan Beulich

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

>>> On 24.04.17 at 19:54, wrote: > --- a/arch/x86/include/arch/msr-index.h > +++ b/arch/x86/include/arch/msr-index.h > @@ -38,6 +38,17 @@ > #define MSR_GS_BASE 0xc101 > #define MSR_SHADOW_GS_BASE 0xc102 > > +#define

Re: [Xen-devel] [PATCH v2 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

> -Original Message- > From: Roger Pau Monne > Sent: 25 April 2017 09:27 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com; > boris.ostrov...@oracle.com; Ian Jackson ; Wei Liu > ; Jan

Re: [Xen-devel] [PATCH v2 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

On Mon, Apr 24, 2017 at 12:50:58PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Roger Pau Monne > > Sent: 24 April 2017 12:03 > > To: Paul Durrant > > Cc: xen-de...@lists.xenproject.org; konrad.w...@oracle.com; > > boris.ostrov...@oracle.com; Ian

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

>>> On 25.04.17 at 09:15, wrote: > Sorry, this may cause potential issue and is not a good example. But from SW > view, there is another case where the per-socket supporting is important in > real-time scenarios. You may have a real-time domain on one socket that >

Re: [Xen-devel] [PATCH v2 3/9] xen/mm: move modify_identity_mmio to global file and drop __init

On Mon, Apr 24, 2017 at 03:42:08PM +0100, Julien Grall wrote: > On 20/04/17 16:17, Roger Pau Monne wrote: > > /* Populate a HVM memory range using the biggest possible order. */ > > diff --git a/xen/common/memory.c b/xen/common/memory.c > > index 52879e7438..0d970482cb 100644 > > ---

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

On 20 April 2017 at 00:10, Stefano Stabellini wrote: > We don't have a formal protocol spec for PV console, but if we had, it > would say that the frontend (Xen in this case) should send notifications > every time there is new data to write. Thus, once per character in

Re: [Xen-devel] [Qemu-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

Stefano Stabellini writes: > On Mon, 24 Apr 2017, Peter Maydell wrote: >> On 24 April 2017 at 22:25, Stefano Stabellini wrote: >> > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h >> > new file mode 100644 >> > index 000..18f0ec0 >> > ---

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

On 17-04-24 00:55:38, Jan Beulich wrote: > >>> On 24.04.17 at 08:40, wrote: > > As what we talked on IRC last Friday, I have got answers for your > > two final questions below: > > 1. Why domain setting is designed to per-socket, any reason? > > Answer: There is a real

[Xen-devel] [ovmf baseline-only test] 71226: all pass

This run is configured for baseline tests only. flight 71226 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/71226/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 1a5ae661754625b8f4bba39214006e87216747e9 baseline

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 08:57, Sander Eikelenboom wrote: > On 25/04/17 08:42, Juergen Gross wrote: >> On 25/04/17 08:35, Sander Eikelenboom wrote: >>> (XEN) [2017-04-24 21:20:53.203] d0v0 Unhandled invalid opcode fault/trap >>> [#6, ec=] >>> (XEN) [2017-04-24 21:20:53.203] domain_crash_sync called

Re: [Xen-devel] [RFC PATCH v2 05/25] x86: NUMA: Move generic dummy_numa_init to separate function

On Thu, Apr 20, 2017 at 9:42 PM, Julien Grall wrote: > Hi Vijay, > > > On 28/03/17 16:53, vijay.kil...@gmail.com wrote: >> >> From: Vijaya Kumar K >> >> Split numa_initmem_init() so that the numa fallback code is moved >> as separate function which

Re: [Xen-devel] [PATCH v2] xen/pvh: Do not fill kernel's e820 map in init_pvh_bootparams()

On 21/04/17 17:13, Boris Ostrovsky wrote: > e820 map is updated with information from the zeropage (i.e. pvh_bootparams) > by default_machine_specific_memory_setup(). With the way things are done > now, we end up with a duplicated e820 map. > > Signed-off-by: Boris Ostrovsky

Re: [Xen-devel] [PATCH] xen/scsifront: use offset_in_page() macro

On 22/04/17 03:21, Geliang Tang wrote: > Use offset_in_page() macro instead of open-coding. > > Signed-off-by: Geliang Tang Pushed to xen/tip for-linus-4.12 Thanks, Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 08:42, Juergen Gross wrote: > On 25/04/17 08:35, Sander Eikelenboom wrote: >> On 25/04/17 08:14, Juergen Gross wrote: >>> On 24/04/17 22:15, Boris Ostrovsky wrote: On 04/24/2017 12:10 PM, Sander Eikelenboom wrote: > On 24/04/17 17:49, Boris Ostrovsky wrote: >> On

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall wrote: > Hi Vijay, > > On 28/03/17 16:53, vijay.kil...@gmail.com wrote: >> >> From: Vijaya Kumar K >> >> Add accessor functions for acpi_numa and numa_off static >> variables. Init value of acpi_numa is

[Xen-devel] [PATCH] x86/xen: fix xsave capability setting

Commit 690b7f10b4f9f ("x86/xen: use capabilities instead of fake cpuid values for xsave") introduced a regression as it tried to make use of the fixup feature before it being available. Fall back to the old variant testing via cpuid(). Signed-off-by: Juergen Gross ---

Re: [Xen-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

On Mon, 24 Apr 2017 16:44:53 -0700 (PDT) Stefano Stabellini wrote: > On Mon, 24 Apr 2017, Peter Maydell wrote: > > On 24 April 2017 at 22:25, Stefano Stabellini > > wrote: > > > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h > > > new

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 08:35, Sander Eikelenboom wrote: > On 25/04/17 08:14, Juergen Gross wrote: >> On 24/04/17 22:15, Boris Ostrovsky wrote: >>> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote: On 24/04/17 17:49, Boris Ostrovsky wrote: > On 04/24/2017 10:20 AM, Sander Eikelenboom wrote: >> Hi

[Xen-devel] [xen-unstable test] 107635: tolerable FAIL - PUSHED

flight 107635 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/107635/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail like 107619 test-armhf-armhf-libvirt

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 25/04/17 08:14, Juergen Gross wrote: > On 24/04/17 22:15, Boris Ostrovsky wrote: >> On 04/24/2017 12:10 PM, Sander Eikelenboom wrote: >>> On 24/04/17 17:49, Boris Ostrovsky wrote: On 04/24/2017 10:20 AM, Sander Eikelenboom wrote: > Hi Boris, > > Nope, not that i am aware of.

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

On 24/04/17 22:15, Boris Ostrovsky wrote: > On 04/24/2017 12:10 PM, Sander Eikelenboom wrote: >> On 24/04/17 17:49, Boris Ostrovsky wrote: >>> On 04/24/2017 10:20 AM, Sander Eikelenboom wrote: Hi Boris, Nope, not that i am aware of. >>> If you can keep console while running this,

<    1   2