Re: [Xen-devel] [PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

On 28/06/16 20:06, David Vrabel wrote: > /proc/xen/xenbus does not work correctly. A read blocked waiting for > a xenstore message holds the mutex needed for atomic file position > updates. This blocks any writes on the same file handle, which can > deadlock if the write is needed to unblock the

Re: [Xen-devel] Discussion about virtual iommu support for Xen guest

> From: Lan, Tianyu > Sent: Sunday, June 26, 2016 9:43 PM > > On 6/8/2016 4:11 PM, Tian, Kevin wrote: > > It makes sense... I thought you used this security issue against > > placing vIOMMU in Qemu, which made me a bit confused earlier. :-) > > > > We are still thinking feasibility of some

[Xen-devel] [ovmf test] 96339: regressions - FAIL

flight 96339 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/96339/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748

[Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection

AVX-512 is an extention of AVX2. Its spec can be found at: https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf This patch detects AVX-512 features by CPUID. Signed-off-by: Luwei Kang --- xen/arch/x86/hvm/hvm.c | 14

Re: [Xen-devel] [PATCH v12 4/6] IOMMU/x86: using a struct pci_dev* instead of SBDF

> From: Xu, Quan > Sent: Sunday, June 26, 2016 6:33 PM > > On June 24, 2016 7:46 PM, Tian, Kevin wrote: > > > From: Xu, Quan > > > Sent: Friday, June 24, 2016 1:52 PM > > > > > > From: Quan Xu > > > > > > a struct pci_dev* instead of SBDF is stored

Re: [Xen-devel] [PATCH v7 3/3] x86/vmx: Clean up TRAP_int3 handling

> From: Tamas K Lengyel [mailto:ta...@tklengyel.com] > Sent: Tuesday, June 28, 2016 2:08 AM > > Clean up the handling of TRAP_int3 VMEXITs to conform to the handling > of TRAP_debug. > > Signed-off-by: Tamas K Lengyel Acked-by: Kevin Tian

[Xen-devel] [PATCH] x86/cpuid: AVX-512 Feature Detection

AVX-512 is an extention of AVX2. Its spec can be found at: https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf This patch detects AVX-512 features by CPUID. Signed-off-by: Luwei Kang --- xen/arch/x86/hvm/hvm.c | 14

Re: [Xen-devel] [PATCH v7 2/3] x86/vm_event: Add HVM debug exception vm_events

> From: Tamas K Lengyel [mailto:ta...@tklengyel.com] > Sent: Tuesday, June 28, 2016 2:08 AM > > Since in-guest debug exceptions are now unconditionally trapped to Xen, adding > a hook for vm_event subscribers to tap into this new always-on guest event. We > rename along the way

Re: [Xen-devel] [PATCH v2] xen: x86: remove duplicated IA32_FEATURE_CONTROL MSR macro

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, June 28, 2016 9:46 PM > > >>> On 28.06.16 at 10:12, wrote: > > From: Kai Huang > > > > Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for > > IA32_FEATURE_CONTROL MSR

[Xen-devel] Xen 4.6 script calling conventions

I'm trying to package Xen 4.6 (specifically Xen 4.6.3) for use with NetBSD. I have it mostly done; however, when I try to create a domU, libxl goes into an infinite loop calling the scripts. If I try to create a domU with no network or disk, it works fine (albeit of rather limited use).

[Xen-devel] repeating 'd1v0 Over-allocation for domain 1' messages in xen 4.7 Host logs on PVHVM Guest launch

(relo'd from user list) I've launched an Ubuntu PVHVM guest, on a Xen 4.7 host cat guest1.cfg name = 'guest1' builder = 'hvm' xen_platform_pci = 1 device_model_version = 'qemu-xen' bios = 'ovmf'

[Xen-devel] [xen-4.3-testing test] 96336: regressions - FAIL

flight 96336 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96336/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 87893

[Xen-devel] [xen-unstable-smoke test] 96349: tolerable all pass - PUSHED

flight 96349 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/96349/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] [PATCH RESEND] MAINTAINERS/gdbsx: change maintainer

On Tue, Jun 28, 2016 at 04:26:40PM -0700, elena.ufimts...@oracle.com wrote: > From: Elena Ufimtseva > > Change gdbsx maintainer to myself. > > > Signed-off-by: Elena Ufimtseva Acked-by: Konrad Rzeszutek Wilk >

[Xen-devel] [PATCH RESEND] MAINTAINERS/gdbsx: change maintainer

From: Elena Ufimtseva Change gdbsx maintainer to myself. Signed-off-by: Elena Ufimtseva --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a8e0043..e91140f 100644 ---

[Xen-devel] [qemu-upstream-4.3-testing test] 96335: regressions - FAIL

flight 96335 qemu-upstream-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/96335/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 5 libvirt-build fail REGR. vs. 80927

Re: [Xen-devel] [PATCH] xen-blkfront: save uncompleted reqs in blkfront_resume()

On Mon, Jun 27, 2016 at 04:33:24PM +0800, Bob Liu wrote: > Uncompleted reqs used to be 'saved and resubmitted' in blkfront_recover() > during > migration, but that's too later after multi-queue introduced. > > After a migrate to another host (which may not have multiqueue support), the > number

[Xen-devel] [xen-unstable test] 96330: regressions - trouble: blocked/broken/fail/pass

flight 96330 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/96330/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt-raw 3 host-install(3) broken REGR. vs. 96296 build-armhf-xsm

[Xen-devel] Domain creation errors

On 28/06/16 18:56, Andrew Cooper wrote: > > > This is the first in a number of changes trying to clean up error reporting of > memory conditions. One area which is constantly causing problems is creation of domains in low memory conditions. In the case where the toolstack gets its calculations

Re: [Xen-devel] [PATCH v5 00/17] xen/arm: Use the typesafes gfn and mfn

On 28/06/16 17:17, Julien Grall wrote: > Julien Grall (17): > xen: Use typesafe gfn/mfn in guest_physmap_* helpers > xen: Use typesafe gfn in xenmem_add_to_physmap_one > xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the > typesafe gfn Committed patches 1-3. Thanks,

Re: [Xen-devel] [PATCH v4] xen: arm: Update arm64 image header

On 28/06/16 11:18, Julien Grall wrote: > >> This is acceptable as the support of Xen for ARM64 in Linux has been >> added >> in Linux 3.11 and the number of boards supported by Linux 3.11 on >> ARM64 is >> very limited: ARM models and X-gene. And for the latter it was an early >> support with only

[Xen-devel] [PATCHv3 1/2] libfs: allow simple_fill_super() to add symlinks

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK. The target is provided in the new "link" field. Signed-off-by: David Vrabel --- v2: - simplified. --- fs/libfs.c | 15 +-- include/linux/fs.h | 2 +- 2 files changed, 14

[Xen-devel] [PATCHv3 0/2] libfs, xenfs: replace /proc/xen/xenbus with a symlink

Using /proc/xen/xenbus can cause deadlocks on the atomic file position mutex since this file should behave like a character device and not a regular file. This is easiest to achive by making it a symlink to the existing /dev/xen/xenbus device. This requires extending simple_fill_super() to add

[Xen-devel] [PATCHv3 2/2] xenfs: replace xenbus and privcmd with symlinks

/proc/xen/xenbus does not work correctly. A read blocked waiting for a xenstore message holds the mutex needed for atomic file position updates. This blocks any writes on the same file handle, which can deadlock if the write is needed to unblock the read. /proc/xen/xenbus is supposed to be

Re: [Xen-devel] [PATCH] xen/page_alloc: Distinguish different errors from assign_pages()

On 28/06/16 18:56, Andrew Cooper wrote: > assign_pages() has a return type of int, but uses for a boolean value. As > there are two distinct failure cases, return a more meaningful error. Sorry - sent an out of date version. This sentence actually reads assign_pages() has a return type of int,

[Xen-devel] [PATCH] xen/page_alloc: Distinguish different errors from assign_pages()

assign_pages() has a return type of int, but uses for a boolean value. As there are two distinct failure cases, return a more meaningful error. All caller currently use its boolean nature, so there is no resulting change (yet). Signed-off-by: Andrew Cooper --- CC:

Re: [Xen-devel] [PATCH linux 0/8] xen: pvhvm: support bootup on secondary vCPUs

On 28/06/16 17:47, Vitaly Kuznetsov wrote: > It may happen that Xen's and Linux's ideas of vCPU id diverge. In > particular, when we crash on a secondary vCPU we may want to do kdump > and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting > on the vCPU which crashed. This

[Xen-devel] [qemu-mainline test] 96328: regressions - FAIL

flight 96328 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/96328/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 94856

Re: [Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

On 28/06/16 17:47, Vitaly Kuznetsov wrote: > @@ -1808,6 +1822,8 @@ static int xen_hvm_cpu_notify(struct notifier_block > *self, unsigned long action, > int cpu = (long)hcpu; > switch (action) { > case CPU_UP_PREPARE: > + /* vLAPIC_ID == Xen's vCPU_ID * 2 for HVM

Re: [Xen-devel] [PATCH v5 15/17] xen/arm: p2m: Introduce helpers to insert and remove mapping

On 28/06/16 17:17, Julien Grall wrote: > void guest_physmap_remove_page(struct domain *d, > gfn_t gfn, > mfn_t mfn, unsigned int page_order) > { > -apply_p2m_changes(d, REMOVE, > - pfn_to_paddr(gfn_x(gfn)),

Re: [Xen-devel] [PATCH v5 13/17] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...

On 28/06/16 17:17, Julien Grall wrote: > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c > index f11094e..5ffc3df 100644 > --- a/xen/arch/arm/p2m.c > +++ b/xen/arch/arm/p2m.c > @@ -1211,20 +1211,20 @@ int unmap_mmio_regions(struct domain *d, > } > > int map_dev_mmio_region(struct domain

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

On Tue, Jun 28, 2016 at 08:03:57AM -0600, Jan Beulich wrote: > ld associates __init_end, placed outside of any section by the linker > script, with the following section, resulting in a huge (wrapped, as it > would be negative) section relative offset. COFF symbol tables store > section relative

Re: [Xen-devel] [PATCH v5 07/17] xen: Use a typesafe to define INVALID_GFN

On 28/06/16 17:17, Julien Grall wrote: > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c > index a929e3b..b9ffce2 100644 > --- a/xen/arch/x86/hvm/hvm.c > +++ b/xen/arch/x86/hvm/hvm.c > @@ -5298,7 +5298,7 @@ static int do_altp2m_op( > a.u.enable_notify.vcpu_id !=

Re: [Xen-devel] [PATCH v5 06/17] xen: Use a typesafe to define INVALID_MFN

On 28/06/16 17:17, Julien Grall wrote: > @@ -60,16 +60,17 @@ dbg_hvm_va2mfn(dbgva_t vaddr, struct domain *dp, int > toaddr, > return INVALID_MFN; > } > > -mfn = mfn_x(get_gfn(dp, *gfn, )); > +mfn = get_gfn(dp, *gfn, ); > if ( p2m_is_readonly(gfntype) && toaddr ) >

Re: [Xen-devel] [PATCH v5 05/17] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

On 28/06/16 17:47, Juergen Gross wrote: On 28/06/16 18:43, Andrew Cooper wrote: On 28/06/16 17:17, Julien Grall wrote: A variable containing a guest frame should be compared to INVALID_GFN and not INVALID_GFN. I think the text should be changed? I'd expect one 'G' being replaced bay 'M'.

Re: [Xen-devel] GDBSX Maintainer

On 28/06/16 17:52, Elena Ufimtseva wrote: > Hi Julien, Andrew > > I was talking to Konrad some time ago about looking into this and the > possibility of maintaining gdbsx code. I am willing sign up for this > if there are no objections. Fine by me. The traditional way of doing this would be for

Re: [Xen-devel] GDBSX Maintainer

Hi Julien, Andrew I was talking to Konrad some time ago about looking into this and the possibility of maintaining gdbsx code. I am willing sign up for this if there are no objections. Elena On Tue, Jun 28, 2016 at 9:46 AM, Andrew Cooper wrote: > On 28/06/16 17:31,

Re: [Xen-devel] [PATCH v2] xen: xen-pciback: Remove create_workqueue

Ping! Thanks, Bhaktipriya On Wed, Jun 1, 2016 at 9:15 PM, Tejun Heo wrote: > On Wed, Jun 01, 2016 at 07:45:08PM +0530, Bhaktipriya Shridhar wrote: >> System workqueues have been able to handle high level of concurrency >> for a long time now and there's no reason to use

Re: [Xen-devel] [PATCH v2] xen: xenbus: Remove create_workqueue

Ping! Thanks, Bhaktipriya On Tue, May 31, 2016 at 10:59 PM, Tejun Heo wrote: > On Tue, May 31, 2016 at 10:26:30PM +0530, Bhaktipriya Shridhar wrote: >> System workqueues have been able to handle high level of concurrency >> for a long time now and there's no reason to use

[Xen-devel] [PATCH linux 4/8] x86/xen: use xen_vcpu_id mapping when pointing vcpu_info to the shared_info page

shared_info page has space for 32 vcpu info slots for first 32 vCPUs but these are the first 32 vCPUs from Xen's perspective and we should map them accordingly with the newly introduced xen_vcpu_id mapping. Signed-off-by: Vitaly Kuznetsov --- arch/x86/xen/enlighten.c | 15

[Xen-devel] [PATCH linux 8/8] xen/pvhvm: run xen_vcpu_setup() for the boot CPU

Historically we didn't call VCPUOP_register_vcpu_info for CPU0 for PVHVM guests (while we had it for PV and ARM guests). This is usually fine as we can use vcpu info in the sared_info page but when we try booting on a vCPU with Xen's vCPU id > 31 (e.g. when we try to kdump after crashing on this

[Xen-devel] [PATCH linux 2/8] xen: introduce xen_vcpu_id mapping

It may happen that Xen's and Linux's ideas of vCPU id diverge. In particular, when we crash on a secondary vCPU we may want to do kdump and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting on the vCPU which crashed. This doesn't work very well for PVHVM guests as we have a

[Xen-devel] [PATCH linux 5/8] xen/events: use xen_vcpu_id mapping in events_base

EVTCHNOP_bind_ipi and EVTCHNOP_bind_virq pass vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by: Vitaly Kuznetsov --- drivers/xen/events/events_base.c | 10 +- 1

[Xen-devel] [PATCH linux 6/8] xen/events: fifo: use xen_vcpu_id mapping

EVTCHNOP_init_control has vCPU id as a parameter and Xen's idea of vCPU id should be used. Use the newly introduced xen_vcpu_id mapping to convert it from Linux's id. Signed-off-by: Vitaly Kuznetsov --- drivers/xen/events/events_fifo.c | 2 +- 1 file changed, 1

[Xen-devel] [PATCH linux 7/8] xen/evtchn: use xen_vcpu_id mapping

Use the newly introduced xen_vcpu_id mapping to get Xen's idea of vCPU id for CPU0. Signed-off-by: Vitaly Kuznetsov --- drivers/xen/evtchn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c index

Re: [Xen-devel] [PATCH v5 05/17] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

On 28/06/16 18:43, Andrew Cooper wrote: > On 28/06/16 17:17, Julien Grall wrote: >> A variable containing a guest frame should be compared to INVALID_GFN >> and not INVALID_GFN. I think the text should be changed? I'd expect one 'G' being replaced bay 'M'. :-) Juergen >> >> Signed-off-by:

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

On 28/06/16 17:11, Jan Beulich wrote: >>> --- a/xen/arch/x86/xen.lds.S >>> +++ b/xen/arch/x86/xen.lds.S >>> @@ -40,9 +40,20 @@ SECTIONS >>> #if !defined(EFI) >>>. = __XEN_VIRT_START; >>>__image_base__ = .; >>> +#else >>> + . = __image_base__; >>> #endif >>> >>> +#if 0 >>> +/* >>> + *

Re: [Xen-devel] making xenstore domain easy configurable

On 6/28/16 11:27 AM, Jan Beulich wrote: On 28.06.16 at 15:59, wrote: >> For xenstored running in the same domain as the toolstack, sockets are >> less overhead than the shared memory ring, as no hypercalls are >> involved. There is also the unfortunate problem

[Xen-devel] [PATCH] xen/arm: io: Protect the handlers with a read-write lock

Currently, accessing the I/O handlers does not require to take a lock because new handlers are always added at the end of the array. In a follow-up patch, this array will be sort to optimize the look up. Given that most of the time the I/O handlers will not be modify, using a spinlock will add

[Xen-devel] GDBSX Maintainer

Hi, I had to modify some code in arch/x86/debug.c and noticed that Mukesh is still the maintainer. IIRC he left Oracle quite a while ago, so my e-mail was bounced by the server. Do we have a new e-mail address for me? If not, does anyone plan to maintain this code? Shall we mark the code as

Re: [Xen-devel] making xenstore domain easy configurable

>>> On 28.06.16 at 15:59, wrote: > For xenstored running in the same domain as the toolstack, sockets are > less overhead than the shared memory ring, as no hypercalls are > involved. There is also the unfortunate problem that one of the two > linux devices for

[Xen-devel] [PATCH v5 13/17] xen/arm: Use the typesafes mfn and gfn in map_dev_mmio_region...

to avoid mixing machine frame with guest frame. Also drop the prefix start_. Signed-off-by: Julien Grall --- Changes in v4: - Patch added --- xen/arch/arm/mm.c | 2 +- xen/arch/arm/p2m.c| 10 +- xen/include/asm-arm/p2m.h | 4 ++-- 3

[Xen-devel] [PATCH v5 16/17] xen/arm: p2m: Use typesafe gfn for {max, lowest}_mapped_gfn

Signed-off-by: Julien Grall --- Changes in v4: - Patch added --- xen/arch/arm/mm.c | 2 +- xen/arch/arm/p2m.c| 18 +- xen/include/asm-arm/p2m.h | 4 ++-- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git

[Xen-devel] [PATCH v5 08/17] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

The prototype and the declaration of p2m_lookup disagree on how the function should be used. One expect a frame number whilst the other an address. Thankfully, everyone is using with an address today. However, most of the callers have to convert a guest frame to an address. Modify the interface

[Xen-devel] [PATCH v5 12/17] xen/arm: p2m: Remove unused operation ALLOCATE

The operation ALLOCATE is unused. If we ever need it, it could be reimplemented with INSERT. Signed-off-by: Julien Grall --- Changes in v4: - Patch added --- xen/arch/arm/p2m.c| 67 ++-

[Xen-devel] [PATCH v5 06/17] xen: Use a typesafe to define INVALID_MFN

Also take the opportunity to convert arch/x86/debug.c to the typesafe mfn. Signed-off-by: Julien Grall --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew Cooper

[Xen-devel] [PATCH v5 11/17] xen/arm: dom0_build: Remove dead code in allocate_memory

The code to allocate memory when dom0 does not use direct mapping is relying on the presence of memory node in the DT. However, they are not present when booting using UEFI or when using ACPI. Rather than fixing the code, remove it because dom0 is always direct memory mapped and therefore the

[Xen-devel] [PATCH v5 05/17] xen/passthrough: x86: Use INVALID_GFN rather than INVALID_MFN

A variable containing a guest frame should be compared to INVALID_GFN and not INVALID_GFN. Signed-off-by: Julien Grall --- Cc: Suravee Suthikulpanit Cc: Jan Beulich Changes in v5: - Patch added ---

[Xen-devel] [PATCH v5 01/17] xen: Use typesafe gfn/mfn in guest_physmap_* helpers

Also rename some variables to gfn or mfn when it does not require much rework. Finally replace %hu with %d when printing the domain id in guest_physmap_add_entry (arch/x86/mm/p2m.c). Signed-off-by: Julien Grall Acked-by: Jan Beulich Acked-by: Stefano

[Xen-devel] [PATCH v5 03/17] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

The correct acronym for a guest physical frame is gfn. Also use the typesafe gfn to ensure that a guest frame is effectively used. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v4: - Add Stefano's acked-by

[Xen-devel] [PATCH v5 02/17] xen: Use typesafe gfn in xenmem_add_to_physmap_one

The x86 version of the function xenmem_add_to_physmap_one contains variable name gpfn and gfn which make the code very confusing. I have left unchanged for now. Also, rename gpfn to gfn in the ARM version as the latter is the correct acronym for a guest physical frame. Finally, remove the

[Xen-devel] [PATCH v5 07/17] xen: Use a typesafe to define INVALID_GFN

Also take the opportunity to convert arch/x86/debug.c to the typesafe gfn. Signed-off-by: Julien Grall --- Cc: Mukesh Rathor Cc: Jan Beulich Cc: Andrew Cooper Cc: Paul Durrant

[Xen-devel] [PATCH v5 15/17] xen/arm: p2m: Introduce helpers to insert and remove mapping

More the half of the arguments of INSERT and REMOVE are the same for each callers. Simplify the callers of apply_p2m_changes by adding new helpers which will fill common arguments with default values. Signed-off-by: Julien Grall --- Changes in v5: - Add missing

[Xen-devel] [PATCH v5 10/17] xen/arm: map_regions_rw_cache: Map the region with p2m->default_access

The parameter 'access' is used by memaccess to restrict temporarily the permission. This parameter should not be used for other purpose (such as restricting permanently the permission). The type p2m_mmio_direct will map the region Read-Write and non-executable. Note that this is already the

[Xen-devel] [PATCH v5 04/17] xen: Use the typesafe mfn and gfn in map_mmio_regions...

to avoid mixing machine frame with guest frame. Signed-off-by: Julien Grall Acked-by: Jan Beulich --- Cc: Stefano Stabellini Cc: Jan Beulich Cc: Andrew Cooper Cc: George Dunlap

[Xen-devel] [PATCH v5 17/17] xen/arm: p2m: Rework the interface of apply_p2m_changes and use typesafe

Most of the callers of apply_p2m_changes have a GFN, a MFN and the number of frame to change in hand. Rather than asking each caller to convert the frame to an address, rework the interfaces to pass the GFN, MFN and the number of frame. Note that it would be possible to do more clean-up in

[Xen-devel] [PATCH v5 14/17] xen/arm: Use the typesafes mfn and gfn in map_regions_rw_cache ...

to avoid mixing machine frame with guest frame. Also rename the parameters of the function and drop pointless PAGE_MASK in the caller. Signed-off-by: Julien Grall --- Changes in v4: - Patch added --- xen/arch/arm/domain_build.c | 8

[Xen-devel] [PATCH v5 09/17] xen/arm: Rework the interface of p2m_cache_flush and use typesafe gfn

p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename the variable to *gfn* and use typesafe to avoid possible misusage. Also, modify the prototype of the function to describe the range using the start and the number of GFNs. This will avoid to wonder whether the end if inclusive or

[Xen-devel] [PATCH v5 00/17] xen/arm: Use the typesafes gfn and mfn

Hello all, Some of the ARM functions are mixing gfn vs mfn and even physical vs frame. To avoid more confusion, this patch series makes use of the terminology described in xen/include/xen/mm.h and the associated typesafe. This series requires the patch [1] to be applied beforehand. I pushed a

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

>>> On 28.06.16 at 16:26, wrote: > On 28/06/16 15:03, Jan Beulich wrote: >> ld associates __init_end, placed outside of any section by the linker >> script, with the following section, resulting in a huge (wrapped, as it >> would be negative) section relative offset. >

[Xen-devel] [PATCH v2] xen/arm: gic-v3: No need to sort the Redistributor regions

The sorting was required by the vGIC emulation until commit 9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3: Correctly retrieve the vCPU associated to a re-distributor". Furthermore, the code is buggy because both local variables 'l' and 'r' point to the same region. So drop the code

[Xen-devel] [libvirt test] 96333: regressions - FAIL

flight 96333 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/96333/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 96299 Tests which did not

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 17:23, Andrew Cooper wrote: > On 28/06/16 16:17, Doug Goldstein wrote: >> On 6/28/16 8:59 AM, Andrew Cooper wrote: >>> On 28/06/16 14:36, Juergen Gross wrote: On 28/06/16 14:42, Andrew Cooper wrote: > On 28/06/16 12:56, Juergen Gross wrote: >> On 28/06/16 13:03, Ian

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 16:17, Doug Goldstein wrote: > On 6/28/16 8:59 AM, Andrew Cooper wrote: >> On 28/06/16 14:36, Juergen Gross wrote: >>> On 28/06/16 14:42, Andrew Cooper wrote: On 28/06/16 12:56, Juergen Gross wrote: > On 28/06/16 13:03, Ian Jackson wrote: >> Juergen Gross writes ("Re:

Re: [Xen-devel] making xenstore domain easy configurable

On 6/28/16 8:59 AM, Andrew Cooper wrote: > On 28/06/16 14:36, Juergen Gross wrote: >> On 28/06/16 14:42, Andrew Cooper wrote: >>> On 28/06/16 12:56, Juergen Gross wrote: On 28/06/16 13:03, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy >

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 15:58, Juergen Gross wrote: > On 28/06/16 15:59, Andrew Cooper wrote: >> On 28/06/16 14:36, Juergen Gross wrote: >>> On 28/06/16 14:42, Andrew Cooper wrote: On 28/06/16 12:56, Juergen Gross wrote: > On 28/06/16 13:03, Ian Jackson wrote: >> Juergen Gross writes ("Re:

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 15:59, Andrew Cooper wrote: > On 28/06/16 14:36, Juergen Gross wrote: >> On 28/06/16 14:42, Andrew Cooper wrote: >>> On 28/06/16 12:56, Juergen Gross wrote: On 28/06/16 13:03, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy >

Re: [Xen-devel] [PATCH V3 04/10] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

On 06/28/2016 08:51 AM, Shanker Donthineni wrote: Hi Julien, On 06/28/2016 05:40 AM, Julien Grall wrote: Hello Shanker, On 27/06/16 21:33, Shanker Donthineni wrote: @@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header, } static int __init

Re: [Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

On 28/06/16 15:03, Jan Beulich wrote: > ld associates __init_end, placed outside of any section by the linker > script, with the following section, resulting in a huge (wrapped, as it > would be negative) section relative offset. So in this case, the cause of the truncation is due to __init_end

[Xen-devel] [PATCH] x86/EFI + Live Patch: avoid symbol address truncation

ld associates __init_end, placed outside of any section by the linker script, with the following section, resulting in a huge (wrapped, as it would be negative) section relative offset. COFF symbol tables store section relative addresses, and hence the above leads to assembler truncation warnings

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 14:36, Juergen Gross wrote: > On 28/06/16 14:42, Andrew Cooper wrote: >> On 28/06/16 12:56, Juergen Gross wrote: >>> On 28/06/16 13:03, Ian Jackson wrote: Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy configurable"): > So you are telling me the

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 14:52, Juergen Gross wrote: > On 28/06/16 14:42, Andrew Cooper wrote: >> On 28/06/16 12:56, Juergen Gross wrote: >>> On 28/06/16 13:03, Ian Jackson wrote: Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy configurable"): > So you are telling me the

Re: [Xen-devel] [PATCH V3 04/10] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

Hi Julien, On 06/28/2016 05:40 AM, Julien Grall wrote: Hello Shanker, On 27/06/16 21:33, Shanker Donthineni wrote: @@ -1397,6 +1408,36 @@ gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header, } static int __init +gic_acpi_parse_cpu_redistributor(struct

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 14:42, Andrew Cooper wrote: > On 28/06/16 12:56, Juergen Gross wrote: >> On 28/06/16 13:03, Ian Jackson wrote: >>> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy >>> configurable"): So you are telling me the xenstore domain won't work for this case? >>> Yes.

Re: [Xen-devel] [PATCH v2] xen: x86: remove duplicated IA32_FEATURE_CONTROL MSR macro

>>> On 28.06.16 at 10:12, wrote: > From: Kai Huang > > Below commit introduced a new macro MSR_IA32_FEATURE_CONTROL for > IA32_FEATURE_CONTROL MSR but it didn't remove old IA32_FEATURE_CONTROL_MSR > macro. The new one has better naming

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

On 06/28/2016 07:03 AM, Shannon Zhao wrote: > > On 2016/6/27 20:05, Boris Ostrovsky wrote: >> >> On 06/27/2016 06:29 AM, Julien Grall wrote: >>> (CC Boris and Doug) >>> >>> Hi Shannon, >>> >>> On 27/06/16 07:01, Shannon Zhao wrote: On 2016/6/24 1:03, Julien Grall wrote: > On 23/06/16

Re: [Xen-devel] Crash in xen 4.7 adding nic during domu startup

>>> On 28.06.16 at 13:23, wrote: > A clue on doing this would be useful, I can't debug what is now release > code all day. Well, debugging (released code or not) is what's needed, I'm afraid. A first step would be to find out how far the corruption extends:

Re: [Xen-devel] [PATCH V3 09/10] xen/arm: io: Use binary search for mmio handler lookup

On 28/06/16 14:19, Shanker Donthineni wrote: On 06/28/2016 05:49 AM, Julien Grall wrote: On 27/06/16 21:33, Shanker Donthineni wrote: As the number of I/O handlers increase, the overhead associated with linear lookup also increases. The system might have maximum of 144 (assuming

Re: [Xen-devel] [PATCH V3 09/10] xen/arm: io: Use binary search for mmio handler lookup

Hi Julien, On 06/28/2016 05:49 AM, Julien Grall wrote: Hi Shanker, On 27/06/16 21:33, Shanker Donthineni wrote: As the number of I/O handlers increase, the overhead associated with linear lookup also increases. The system might have maximum of 144 (assuming CONFIG_NR_CPUS=128) mmio handlers.

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 12:56, Juergen Gross wrote: > On 28/06/16 13:03, Ian Jackson wrote: >> Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy >> configurable"): >>> So you are telling me the xenstore domain won't work for this case? >> Yes. > That's rather unfortunate. So in order to be

[Xen-devel] [xen-unstable-smoke test] 96340: tolerable all pass - PUSHED

flight 96340 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/96340/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12

Re: [Xen-devel] [PATCH v4 08/16] xen: Replace _mfn(INVALID_MFN) with MFN_INVALID_T

Hi Jan, On 28/06/16 08:19, Jan Beulich wrote: On 27.06.16 at 18:54, wrote: This patch is a mechanical replacement. Command used: 42sh> ack -l "_mfn\(INVALID_MFN\)" | xargs sed -i -e 's/_mfn(INVALID_MFN)/INVALID_MFN_T/g' Well, wait - if you do this, then I'm no longer

Re: [Xen-devel] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

On 28 June 2016 at 14:06, Julien Grall wrote: > Hi Ard, > > On 28/06/16 12:39, Ard Biesheuvel wrote: >> >> On 25 June 2016 at 09:16, Shannon Zhao wrote: >>> >>> From: Shannon Zhao >>> >>> Add ACPI support for Virt Xen ARM

Re: [Xen-devel] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

Hi Ard, On 28/06/16 12:39, Ard Biesheuvel wrote: On 25 June 2016 at 09:16, Shannon Zhao wrote: From: Shannon Zhao Add ACPI support for Virt Xen ARM and only for aarch64. It gets the ACPI tables through Xen ARM multiboot protocol.

Re: [Xen-devel] making xenstore domain easy configurable

On 28/06/16 13:03, Ian Jackson wrote: > Juergen Gross writes ("Re: [Xen-devel] making xenstore domain easy > configurable"): >> So you are telling me the xenstore domain won't work for this case? > > Yes. That's rather unfortunate. So in order to be able to make xenstore domain a common setup

Re: [Xen-devel] [PATCH v3] ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

On 25 June 2016 at 09:16, Shannon Zhao wrote: > From: Shannon Zhao > > Add ACPI support for Virt Xen ARM and only for aarch64. It gets the > ACPI tables through Xen ARM multiboot protocol. > > Contributed-under: TianoCore Contribution Agreement

[Xen-devel] [PATCH] xen/arm: gic-v3: No need to sort the Redistributor regions

The sorting was required by the vGIC emulation until commit 9b9d51e98edb8c5c731e2d06dfad3633053d88a4 "xen/arm: vgic-v3: Correctly retrieve the vCPU associated to a re-distributor". Furthermore, the code is buggy because both local variables 'l' and 'r' point to the same region. So drop the code

Re: [Xen-devel] Crash in xen 4.7 adding nic during domu startup

A clue on doing this would be useful, I can't debug what is now release code all day. 4.5 is absolutely fine. 4.6.3 (tried last night) does not fail either but refuses to start my domU that has two nics assigned to it in a vif line. I'm presuming other people are successfully running multiple

Re: [Xen-devel] xc_domain_maximum_gpfn

Hello, On 27/06/16 14:31, sepanta s wrote: On Sun, Jun 26, 2016 at 5:19 PM, sepanta s > wrote: Hi, what exactly does this module do? sorry, not module but the function. The function xc_domain_maximum_gpfn returns the highest frame

Re: [Xen-devel] [PATCH v2 11/17] libxl/arm: Construct ACPI DSDT table

On 2016/6/27 20:05, Boris Ostrovsky wrote: > > > On 06/27/2016 06:29 AM, Julien Grall wrote: >> (CC Boris and Doug) >> >> Hi Shannon, >> >> On 27/06/16 07:01, Shannon Zhao wrote: >>> On 2016/6/24 1:03, Julien Grall wrote: On 23/06/16 04:16, Shannon Zhao wrote: [...] >

  1   2   >