[Xen-devel] [PATCH 26/45] gntdev.h: include stdint.h in userspace

Fixes compilation error: xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’ Signed-off-by: Mikko Rapeli --- include/uapi/xen/gntdev.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/xen/gntdev.h b/include/uapi/xen/gntdev.h index 5304bd3..f724f75 100644 --- a/include/u

[Xen-devel] [PATCH 25/45] gntalloc.h: include stdint.h in userspace

Fixes compilation error: xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’ Signed-off-by: Mikko Rapeli --- include/uapi/xen/gntalloc.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/xen/gntalloc.h index 76bd580..184df7e 100644 --- a/i

[Xen-devel] [xen-4.5-testing test] 34638: regressions - FAIL

flight 34638 xen-4.5-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34638/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 5 xen-boot fail REGR. vs. 34200 test-amd64-amd64-

Re: [Xen-devel] [PATCH v4 14/29] MdePkg/BaseSynchronizationLib: implement 16-bit compare-exchange

On 17 February 2015 at 18:40, Jordan Justen wrote: > Ard, > > For the subject, I think > MdePkg/BaseSynchronizationLib: Add InterlockedCompareExchange16 > would be better. > OK > Acked-by: Jordan Justen > Thanks > Thanks for working to move this to a common location. > No problem > Mike, >

[Xen-devel] [PATCH 0/2] x86: tboot adjustments

1: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use 2: simplify DMAR table copying Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/2] x86/tboot: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use

In order for commit cbeeaa7d ("x86/nmi: fix shootdown of pcpus running in VMX non-root mode")'s re-use of that fixmap entry to not cause undesirable (in crash context) cross-CPU TLB flushes, invalidate the fixmap entry right after use. Signed-off-by: Jan Beulich --- a/xen/arch/x86/tboot.c +++ b/

[Xen-devel] [PATCH 2/2] x86/tboot: simplify DMAR table copying

There's no need for more than one variable, no need for casts, and no point in using the type-safe xmalloc_array() here. Signed-off-by: Jan Beulich --- a/xen/arch/x86/tboot.c +++ b/xen/arch/x86/tboot.c @@ -435,13 +435,12 @@ int __init tboot_protect_mem_regions(voi int __init tboot_parse_dmar_

Re: [Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions

>>> On 17.02.15 at 18:37, wrote: > On Tue, Feb 17, 2015 at 12:56 PM, Jan Beulich wrote: > On 13.02.15 at 17:33, wrote: >>> +static void hvm_event_cr(uint32_t reason, unsigned long value, >>> +unsigned long old) >>> +{ >>> +vm_event_request_t req = { >>> +

Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.

Dear Jan > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Tuesday, February 17, 2015 6:09 PM > To: Wang, Xiaoming > Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com; > lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com; > Liu, Chuansheng; Zh

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: > 64 bit pv-domains under Xen are limited to 512 GB of RAM today. The > main reason has been the 3 level p2m tree, which was replaced by the > virtual mapped linear p2m list. Parallel to the p2m list which is > being used by the kernel itself

Re: [Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

>>> On 17.02.15 at 19:20, wrote: > On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich wrote: > On 13.02.15 at 17:33, wrote: >>> rc = vm_event_enable(d, vec, ved, _VPF_mem_access, >>> -HVM_PARAM_MONITOR_RING_PFN, >>> -

Re: [Xen-devel] [PATCH V5 10/12] xen/vm_event: Relocate memop checks

>>> On 17.02.15 at 19:47, wrote: > On Tue, Feb 17, 2015 at 3:25 PM, Jan Beulich wrote: > On 13.02.15 at 17:33, wrote: >>> -int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo) >>> +int mem_paging_memop(unsigned long cmd, >>> + XEN_GUEST_HANDLE_PARAM(xen_mem_pa

Re: [Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl

>>> On 17.02.15 at 19:32, wrote: > On Tue, Feb 17, 2015 at 3:31 PM, Jan Beulich wrote: > On 13.02.15 at 17:33, wrote: >>> @@ -611,13 +611,22 @@ int vm_event_domctl(struct domain *d, > xen_domctl_vm_event_op_t *vec, >>> } >>> break; >>> >>> -case XEN_VM_EVENT_PAGING

Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.

>>> On 18.02.15 at 10:09, wrote: >> From: Jan Beulich [mailto:jbeul...@suse.com] >> Sent: Tuesday, February 17, 2015 6:09 PM >> >>> On 17.02.15 at 07:51, wrote: >> > --- a/Documentation/kernel-parameters.txt >> > +++ b/Documentation/kernel-parameters.txt >> > @@ -3438,10 +3438,12 @@ bytes respect

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On 02/18/2015 10:21 AM, Paul Bolle wrote: On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: 64 bit pv-domains under Xen are limited to 512 GB of RAM today. The main reason has been the 3 level p2m tree, which was replaced by the virtual mapped linear p2m list. Parallel to the p2m list whic

Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

>>> On 18.02.15 at 01:11, wrote: > diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c > similarity index 59% > rename from xen/common/mem_event.c > rename to xen/common/vm_event.c Looking at this already quite huge delta I can't really see why adjusting white space at once would make it

[Xen-devel] [xen-4.4-testing test] 34688: regressions - FAIL

flight 34688 xen-4.4-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34688/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xend 5 xen-build fail REGR. vs. 34151 build-amd64-xend

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

>>> On 18.02.15 at 10:37, wrote: > On 02/18/2015 10:21 AM, Paul Bolle wrote: >> On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: >>> --- a/arch/x86/xen/Kconfig >>> +++ b/arch/x86/xen/Kconfig >>> @@ -23,14 +23,29 @@ config XEN_PVHVM >>> def_bool y >>> depends on XEN && PCI && X86_LOC

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On 02/18/2015 10:49 AM, Jan Beulich wrote: On 18.02.15 at 10:37, wrote: On 02/18/2015 10:21 AM, Paul Bolle wrote: On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -23,14 +23,29 @@ config XEN_PVHVM def_bool y depen

Re: [Xen-devel] [PATCH v4] modify the IO_TLB_SEGSIZE and IO_TLB_DEFAULT_SIZE configurable as flexible requirement about SW-IOMMU.

Dear Jan > -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Wednesday, February 18, 2015 5:35 PM > To: Wang, Xiaoming > Cc: ch...@chris-wilson.co.uk; david.vra...@citrix.com; > lau...@codeaurora.org; heiko.carst...@de.ibm.com; li...@horizon.com; > Liu, Chuansheng;

Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes

On 17/02/15 07:39, Juergen Gross wrote: > > If we have neither XEN_PV nor XEN_PVH set, why do we have to build > enlighten.c? It will never be used. Same should apply to several other > files in arch/x86/xen. Can we limit this series to only Kconfig changes? I don't really like scope-creep in pa

Re: [Xen-devel] [RFC v1 0/8] xen: kconfig changes

On 02/18/2015 11:03 AM, David Vrabel wrote: On 17/02/15 07:39, Juergen Gross wrote: If we have neither XEN_PV nor XEN_PVH set, why do we have to build enlighten.c? It will never be used. Same should apply to several other files in arch/x86/xen. Can we limit this series to only Kconfig changes

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

On 18/02/15 06:51, Juergen Gross wrote: > The linear p2m list should be anchored in the shared info structure I'm not really sure what you mean by "anchored". > read by the Xen tools to be able to support 64 bit pv-domains larger > than 512 MB. Additionally the linear p2m list interface includes

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On Wed, 2015-02-18 at 10:37 +0100, Juergen Gross wrote: > On 02/18/2015 10:21 AM, Paul Bolle wrote: > > On Wed, 2015-02-18 at 07:52 +0100, Juergen Gross wrote: > >> +choice > >> + prompt "Support pv-domains larger than 512GB" > >> + default XEN_512GB_NONE > >> + help > >> +Support paravirtua

Re: [Xen-devel] [PATCH 1/2] x86/tboot: invalidate FIX_TBOOT_MAP_ADDRESS mapping after use

On 18/02/15 09:03, Jan Beulich wrote: > In order for commit cbeeaa7d ("x86/nmi: fix shootdown of pcpus > running in VMX non-root mode")'s re-use of that fixmap entry to not > cause undesirable (in crash context) cross-CPU TLB flushes, invalidate > the fixmap entry right after use. > > Signed-off-by

Re: [Xen-devel] [PATCH 2/2] x86/tboot: simplify DMAR table copying

On 18/02/15 09:03, Jan Beulich wrote: > There's no need for more than one variable, no need for casts, and no > point in using the type-safe xmalloc_array() here. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper > > --- a/xen/arch/x86/tboot.c > +++ b/xen/arch/x86/tboot.c > @@ -435,13 +

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

On 02/18/2015 11:32 AM, David Vrabel wrote: On 18/02/15 06:51, Juergen Gross wrote: The linear p2m list should be anchored in the shared info structure I'm not really sure what you mean by "anchored". Bad wording? What about: The virtual address of the linear p2m list should be stored in th

[Xen-devel] [PATCH OSSTEST] Debian: Add "fdt chosen" to boot script

This causes u-boot to fill in the various fields in the chosen node (specifically the bootargs) which would otherwise not be done until the bootz command. Doing it manually means the following "fdt print /chosen" will print what is actually going to be used. This change means that instead of whate

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

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 =

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

On 18/02/15 10:42, Juergen Gross wrote: > On 02/18/2015 11:32 AM, David Vrabel wrote: >> On 18/02/15 06:51, Juergen Gross wrote: >>> The linear p2m list should be anchored in the shared info structure >> >> I'm not really sure what you mean by "anchored". > > Bad wording? What about: > > The virt

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

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) ptechk = lookup_a

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

On 02/18/2015 11:50 AM, 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) ptechk = lookup_address(vaddr, &level);

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

On 02/18/2015 11:54 AM, 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)

Re: [Xen-devel] [PATCH 02/13] xen: anchor linear p2m list in shared info structure

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 *pt

Re: [Xen-devel] dprintk() and gdprintk() to be compiled out when NDEBUG

On Wed, 2015-02-11 at 07:50 +, Jan Beulich wrote: > All, > > I'd like to propose to honor the 'd' in these functions' names (which > I understand to mean "debug") in that such functions should be > no-ops in non-debug builds. I'd then be inclined to introduce a > gprintk() automatically adding

Re: [Xen-devel] dprintk() and gdprintk() to be compiled out when NDEBUG

>>> On 18.02.15 at 11:58, wrote: > On Wed, 2015-02-11 at 07:50 +, Jan Beulich wrote: >> Quite likely the (mis-)use of these >> two functions may then temporarily result in messages not meant >> to be debugging ones to become hidden in non-debug builds. If >> others agree, I'd try to make one

Re: [Xen-devel] [PATCH v18 05/16] x86/VPMU: Interface for setting PMU mode and flags

Am Montag 16 Februar 2015, 17:26:48 schrieb Boris Ostrovsky: > Add runtime interface for setting PMU mode and flags. Three main modes are > provided: > * XENPMU_MODE_OFF: PMU is not virtualized > * XENPMU_MODE_SELF: Guests can access PMU MSRs and receive PMU interrupts. > * XENPMU_MODE_HV: Same as

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On 18/02/15 06:52, Juergen Gross wrote: > > +if X86_64 > +choice > + prompt "Support pv-domains larger than 512GB" > + default XEN_512GB_NONE > + help > + Support paravirtualized domains with more than 512GB of RAM. > + > + The Xen tools and crash dump analysis tools might

Re: [Xen-devel] [RFC] Tweaking the release process for Xen 4.6

On Tue, 2015-02-10 at 15:04 +, Wei Liu wrote: Not much to add... a couple of comments. > Counting from the point that we forked the tree, it took ~11 months to > ship 4.5. The time spent on development was 7 months (Feb 21 to Sept > 24), and the time spent on freeze was ~4 months (Sept 24 to

Re: [Xen-devel] [PATCH 1/2] arm/xen: Correctly check if the event channel interrupt is present

On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: > The function irq_of_parse_and_map returns 0 when the IRQ is not found. > > Furthermore xen_events_irq is only read when the CPU is bring up, so > it's not necessary to use the attribute __read_mostly. Part of the purpose of __read_mostly is

Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier

On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: > Hello, > > This small patch series move the detection of running on Xen earlier. This is > required in order to support earlyprintk via Xen and selecting the preferred > console. Thanks for doing this, having all of the init done in an init

Re: [Xen-devel] dprintk() and gdprintk() to be compiled out when NDEBUG

On Wed, 2015-02-18 at 11:05 +, Jan Beulich wrote: > >>> On 18.02.15 at 11:58, wrote: > > On Wed, 2015-02-11 at 07:50 +, Jan Beulich wrote: > >> Quite likely the (mis-)use of these > >> two functions may then temporarily result in messages not meant > >> to be debugging ones to become hidd

Re: [Xen-devel] [PATCH 1/2] arm/xen: Correctly check if the event channel interrupt is present

Hi Ian, On 18/02/2015 11:27, Ian Campbell wrote: On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: The function irq_of_parse_and_map returns 0 when the IRQ is not found. Furthermore xen_events_irq is only read when the CPU is bring up, so it's not necessary to use the attribute __read_mos

Re: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver

Hi Manish, On 18/02/2015 01:02, Manish wrote: On 17/12/14 1:38 am, Julien Grall wrote: The main goal is to modify as little the Linux code to be able to port easily new feature added in Linux repo for the driver. To achieve that we: - Add helpers to Linux function not implemented on Xen

Re: [Xen-devel] [PATCH 1/2] arm/xen: Correctly check if the event channel interrupt is present

On 18/02/2015 11:41, Julien Grall wrote: Hi Ian, On 18/02/2015 11:27, Ian Campbell wrote: On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: The function irq_of_parse_and_map returns 0 when the IRQ is not found. Furthermore xen_events_irq is only read when the CPU is bring up, so it's n

Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier

Hi Ian, On 18/02/2015 11:30, Ian Campbell wrote: On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: Hello, This small patch series move the detection of running on Xen earlier. This is required in order to support earlyprintk via Xen and selecting the preferred console. Thanks for doing

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On 02/18/2015 12:18 PM, David Vrabel wrote: On 18/02/15 06:52, Juergen Gross wrote: +if X86_64 +choice + prompt "Support pv-domains larger than 512GB" + default XEN_512GB_NONE + help + Support paravirtualized domains with more than 512GB of RAM. + + The Xen too

Re: [Xen-devel] [PATCH 25/45] gntalloc.h: include stdint.h in userspace

On 16/02/15 23:05, Mikko Rapeli wrote: > Fixes compilation error: > > xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’ > > Signed-off-by: Mikko Rapeli > --- > include/uapi/xen/gntalloc.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/uapi/xen/gntalloc.h b/includ

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

Sorry, used Reply instead of Reply-all On 02/18/2015 12:18 PM, David Vrabel wrote: On 18/02/15 06:52, Juergen Gross wrote: +if X86_64 +choice + prompt "Support pv-domains larger than 512GB" + default XEN_512GB_NONE + help + Support paravirtualized domains with more th

Re: [Xen-devel] [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver

BTW, I have sent few versions of this series since then. Please comment on the latest series as the code may have change. Nonetheless, you are comment is still valid for the v3 :). Regards, On 18/02/2015 11:47, Julien Grall wrote: Hi Manish, On 18/02/2015 01:02, Manish wrote: On 17/12/14 1

Re: [Xen-devel] [PATCH 13/13] xen: allow more than 512 GB of RAM for 64 bit pv-domains

On 18/02/15 11:51, Juergen Gross wrote: > > >> People using crash analysis tools that need the 3-level p2m can clamp >> dom0 memory with the Xen command line option. FWIW, the tool we use >> doesn't need this. > > Interesting. Which tool are you using? https://github.com/xenserver/xen-crashdump-a

Re: [Xen-devel] [PATCH OSSTEST] Debian: Add "fdt chosen" to boot script

Ian Campbell writes ("[PATCH OSSTEST] Debian: Add "fdt chosen" to boot script"): > This causes u-boot to fill in the various fields in the chosen node > (specifically the bootargs) which would otherwise not be done until > the bootz command. Doing it manually means the following "fdt print > /chose

Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier

On Wed, 2015-02-18 at 11:51 +, Julien Grall wrote: > Hi Ian, > > On 18/02/2015 11:30, Ian Campbell wrote: > > On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: > >> Hello, > >> > >> This small patch series move the detection of running on Xen earlier. This > >> is > >> required in order

Re: [Xen-devel] [PATCH OSSTEST] Debian: Add "fdt chosen" to boot script

On Wed, 2015-02-18 at 11:56 +, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST] Debian: Add "fdt chosen" to boot > script"): > > This causes u-boot to fill in the various fields in the chosen node > > (specifically the bootargs) which would otherwise not be done until > > the bootz c

Re: [Xen-devel] [PATCH V5 06/12] x86/hvm: factor out and rename vm_event related functions

On Wed Feb 18 2015 10:07:29 AM CET, Jan Beulich wrote: > > > > On 17.02.15 at 18:37, wrote: > > On Tue, Feb 17, 2015 at 12:56 PM, Jan Beulich > > wrote: > > > > > > On 13.02.15 at 17:33, wrote: > > > > +static void hvm_event_cr(uint32_t reason, unsigned long value, > > > > +                   

Re: [Xen-devel] [PATCH V5 07/12] xen: Introduce monitor_op domctl

On Wed Feb 18 2015 10:26:00 AM CET, Jan Beulich wrote: > > > > On 17.02.15 at 19:20, wrote: > > On Tue, Feb 17, 2015 at 3:02 PM, Jan Beulich wrote: > > > > > > On 13.02.15 at 17:33, wrote: > > > > rc = vm_event_enable(d, vec, ved, _VPF_mem_access, > > > > -                                     

Re: [Xen-devel] [PATCH V5 10/12] xen/vm_event: Relocate memop checks

On Wed Feb 18 2015 10:29:40 AM CET, Jan Beulich wrote: > > > > On 17.02.15 at 19:47, wrote: > > On Tue, Feb 17, 2015 at 3:25 PM, Jan Beulich wrote: > > > > > > On 13.02.15 at 17:33, wrote: > > > > -int mem_paging_memop(struct domain *d, xen_mem_paging_op_t *mpo) > > > > +int mem_paging_memop(u

Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier

On 18/02/2015 12:03, Ian Campbell wrote: On Wed, 2015-02-18 at 11:51 +, Julien Grall wrote: Hi Ian, On 18/02/2015 11:30, Ian Campbell wrote: On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: Hello, This small patch series move the detection of running on Xen earlier. This is requi

Re: [Xen-devel] [PATCH V5 12/12] xen/vm_event: Add RESUME option to vm_event_op domctl

On Wed Feb 18 2015 10:31:06 AM CET, Jan Beulich wrote: > > > > On 17.02.15 at 19:32, wrote: > > On Tue, Feb 17, 2015 at 3:31 PM, Jan Beulich wrote: > > > > > > On 13.02.15 at 17:33, wrote: > > > > @@ -611,13 +611,22 @@ int vm_event_domctl(struct domain *d, > > xen_domctl_vm_event_op_t *vec, >

[Xen-devel] [PATCH v2 2/3] xen/arm: Add early printk support for ThunderX platform

From: Vijaya Kumar K ThunderX platform uses pl011 uart. Signed-off-by: Vijaya Kumar K --- xen/arch/arm/Rules.mk |4 1 file changed, 4 insertions(+) diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index c7bd227..54efa91 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/

[Xen-devel] [PATCH v2 1/3] xen/arm: Add ThunderX platform support

From: Vijaya Kumar K Add basic support for Cavium ThunderX platform Signed-off-by: Vijaya Kumar K --- xen/arch/arm/platforms/Makefile |1 + xen/arch/arm/platforms/thunderx.c | 66 + xen/arch/arm/setup.c |1 + 3 files changed, 68 inse

[Xen-devel] [PATCH v2 3/3] xen/arm: Skip parsing psci-0.2 from host device tree

From: Vijaya Kumar K psci node is generated by xen for dom0. if the host device tree has psci-0.2 skip parsing this node and avoid copying from host device tree to dom0 device tree Signed-off-by: Vijaya Kumar K --- xen/arch/arm/domain_build.c |1 + 1 file changed, 1 insertion(+) diff --gi

[Xen-devel] [PATCH v2 0/3] Add ThunderX platform support

From: Vijaya Kumar K Changes in v2: - Updated patch 3 commit message - Updated processor_implementers[] with implementor info in xen/arch/arm/setup.c Changes in v1: - Add support for ThunderX platform - Add early printk support - Add psci-0.2 check while parsing dt node Vijaya Kumar K (

Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich wrote: > > > > On 18.02.15 at 01:11, wrote: > > diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c > > similarity index 59% > > rename from xen/common/mem_event.c > > rename to xen/common/vm_event.c > > Looking at this already quite huge

[Xen-devel] [PATCH] x86: Adjust rdtsc inline assembly

Currently there are three related rdtsc macros, all of which are lowercase and not obviously macros, which write by value to their parameters. This is non-intuitive to program which, being contrary to C semantics for code appearing to be a regular function call. It is also causes Coverity to conc

Re: [Xen-devel] [PATCH v2 1/3] xen/arm: Add ThunderX platform support

Hello Vijay, On 18/02/2015 12:19, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K Add basic support for Cavium ThunderX platform Signed-off-by: Vijaya Kumar K --- xen/arch/arm/platforms/Makefile |1 + xen/arch/arm/platforms/thunderx.c | 66 +

Re: [Xen-devel] Inplace upgrading 4.4.x -> 4.5.0

On Mon, 2015-02-09 at 20:36 +1100, Steven Haigh wrote: > > This sounds like a packaging issue -- Debian's packages for example jump > > through some hoops to make sure multiple tools packages can be installed > > in parallel and the correct ones selected for the currently running > > hypervisor. >

Re: [Xen-devel] [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map

Hi Suravee, On 18/02/2015 05:28, Suravee Suthikulanit wrote: Actually, that seems to be more related to the PCI pass-through devices. Isn't the Cavium guys already done that work to support their PCI device pass-through? They were working on it, but so far there is no patch series on the ML.

Re: [Xen-devel] [PATCH v2] introduce and use relaxed cpumask bitops

On Wed, 2015-02-11 at 13:42 +, Jan Beulich wrote: > Using atomic (LOCKed on x86) bitops for certain of the operations on > cpumask_t is overkill when the variables aren't concurrently accessible > (e.g. local function variables, or due to explicit locking). Introduce > alternatives using non-at

[Xen-devel] [PATCH v1] xen/arm: Do not allocate pte entries for MAP_SMALL_PAGES

From: Vijaya Kumar K On x86, for the pages mapped with PAGE_HYPERVISOR attribute non-leaf page tables are allocated with valid pte entries. and with MAP_SMALL_PAGES attribute only non-leaf page tables are allocated with invalid (valid bit set to 0) pte entries. However on arm this is not the case

Re: [Xen-devel] [PATCH v1] xen/arm: Do not allocate pte entries for MAP_SMALL_PAGES

Hello Vijay, On 18/02/2015 12:56, vijay.kil...@gmail.com wrote: From: Vijaya Kumar K On x86, for the pages mapped with PAGE_HYPERVISOR attribute non-leaf page tables are allocated with valid pte entries. and with MAP_SMALL_PAGES attribute only non-leaf page tables are allocated with invalid (v

Re: [Xen-devel] [PATCH] x86: Adjust rdtsc inline assembly

>>> On 18.02.15 at 13:25, wrote: > The single use of the old rdtsc() in emulate_privileged_op() is altered to use > the new rdtsc() and the rdmsr_writeback path to set eax/edx appropriately. I'm not entirely sure about this one - the current code surely is slightly faster than the replacement. Qu

Re: [Xen-devel] [Qemu-devel] [v2][PATCH] libxl: add one machine property to support IGD GFX passthrough

On Wed, 2015-02-11 at 10:45 +0800, Chen, Tiejun wrote: > On 2015/2/9 19:05, Ian Campbell wrote: > > On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote: > > > >> What about this? > > > > I've not read the code in detail,since I'm travelling but from a quick > > glance it looks to be implementing

[Xen-devel] [ovmf test] 34650: regressions - trouble: broken/fail/pass

flight 34650 ovmf real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34650/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail REGR. vs. 33686 test-amd64-i386-xl-qemuu-ovm

Re: [Xen-devel] [PATCH] domctl: do away with tool stack based retrying

On Fri, 2015-02-13 at 14:34 +, Wei Liu wrote: > On Wed, Feb 11, 2015 at 01:47:09PM +, Jan Beulich wrote: > > XEN_DOMCTL_destroydomain so far is being special cased in libxc to > > reinvoke the operation when getting back EAGAIN. Quite a few other > > domctl-s have gained continuations, so I

Re: [Xen-devel] [PATCH V6 04/13] xen: Rename mem_event to vm_event

>>> On 18.02.15 at 13:21, wrote: > On Wed Feb 18 2015 10:46:02 AM CET, Jan Beulich wrote: > >> > > > On 18.02.15 at 01:11, wrote: >> > diff --git a/xen/common/mem_event.c b/xen/common/vm_event.c >> > similarity index 59% >> > rename from xen/common/mem_event.c >> > rename to xen/common/vm_event

Re: [Xen-devel] [PATCH 0/2] arm/arm64: Detect Xen support earlier

On Wed, 2015-02-18 at 12:13 +, Julien Grall wrote: > > On 18/02/2015 12:03, Ian Campbell wrote: > > On Wed, 2015-02-18 at 11:51 +, Julien Grall wrote: > >> Hi Ian, > >> > >> On 18/02/2015 11:30, Ian Campbell wrote: > >>> On Thu, 2015-02-12 at 06:34 +, Julien Grall wrote: > Hello,

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On Tue, 2015-02-17 at 17:33 +, Julien Grall wrote: > Hi Ian, > > On 24/10/14 10:58, Ian Campbell wrote: > > These properties are defined in ePAPR and the OpenFirmware PCI Bus Binding > > Specification (IEEE Std 1275-1994). > > > > This replaces the xgene specific mapping. Tested on Mustang an

Re: [Xen-devel] [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map

On Sun, 2015-02-15 at 21:49 -0600, Suravee Suthikulpanit wrote: > On 10/24/2014 04:58 AM, Ian Campbell wrote: > > This message has been archived. View the original item > >

[Xen-devel] [PATCH v2 0/3] arm/arm64: Detect Xen support earlier

Hello, This small patch series moves the detection of running on Xen earlier. This is required in order to support earlyprintk via Xen and selecting preferred console. Actually, the last patch of this patch series adds HVC0 as preferred console when running on Xen. The patch [1] was previously s

[Xen-devel] [PATCH v2 1/3] arm/xen: Correctly check if the event channel interrupt is present

The function irq_of_parse_and_map returns 0 when the IRQ is not found. Futhermore, move the check before notifying the user that we are running on Xen. Signed-off-by: Julien Grall Acked-by: Ian Campbell --- Changes in v2: - Add Ian's ack - Re-add __read_mostly --- arch/arm

[Xen-devel] [PATCH v2 3/3] xen/arm: allow console=hvc0 to be omitted for guests

From: Ard Biesheuvel This patch registers hvc0 as the preferred console if no console has been specified explicitly on the kernel command line. The purpose is to allow platform agnostic kernels and boot images (such as distro installers) to boot in a Xen/ARM domU without the need to modify the c

[Xen-devel] [PATCH v2 2/3] arm, arm64/xen: move Xen initialization earlier

From: Stefano Stabellini Currently, Xen is initialized/discovered in an initcall. This doesn't allow us to support earlyprintk or choosing the preferred console when running on Xen. The current function xen_guest_init is now split in 2 parts: - xen_early_init: Check if there is a Xen node in

Re: [Xen-devel] [PATCH] x86: Adjust rdtsc inline assembly

On 18/02/15 13:11, Jan Beulich wrote: On 18.02.15 at 13:25, wrote: >> The single use of the old rdtsc() in emulate_privileged_op() is altered to >> use >> the new rdtsc() and the rdmsr_writeback path to set eax/edx appropriately. > I'm not entirely sure about this one - the current code sure

[Xen-devel] [PATCH v2] x86: Adjust rdtsc inline assembly

Currently there are three related rdtsc macros, all of which are lowercase and not obviously macros, which write by value to their parameters. This is non-intuitive to program which, being contrary to C semantics for code appearing to be a regular function call. It is also causes Coverity to conc

Re: [Xen-devel] freemem-slack and large memory environments

On Tue, 2015-02-10 at 14:34 -0700, Mike Latimer wrote: > On Monday, February 09, 2015 06:27:54 PM Mike Latimer wrote: > > While testing commit 2563bca1, I found that libxl_get_free_memory returns 0 > > until there is more free memory than required for freemem-slack. This means > > that during the d

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

Hi Ian, On 18/02/2015 13:50, Ian Campbell wrote: On Tue, 2015-02-17 at 17:33 +, Julien Grall wrote: Hi Ian, On 24/10/14 10:58, Ian Campbell wrote: These properties are defined in ePAPR and the OpenFirmware PCI Bus Binding Specification (IEEE Std 1275-1994). This replaces the xgene specif

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote: > Hi Ian, > > On 18/02/2015 13:50, Ian Campbell wrote: > > On Tue, 2015-02-17 at 17:33 +, Julien Grall wrote: > >> Hi Ian, > >> > >> On 24/10/14 10:58, Ian Campbell wrote: > >>> These properties are defined in ePAPR and the OpenFirmware PC

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On 18/02/2015 14:37, Ian Campbell wrote: On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote: I think so, and we probably should consider the two cases separately since the right answer could reasonably differ for different resource types. I am reasonably convinced that for MMIO (+IO+CFG spa

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On 18/02/2015 14:37, Ian Campbell wrote: I am reasonably convinced that for MMIO (+IO+CFG space) we should map everything as described by the ranges property of the top most node, it can be considered an analogue to / extension of the reg property of that node. BTW, the CFG space is part of t

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On 18/02/2015 15:05, Julien Grall wrote: On 18/02/2015 14:37, Ian Campbell wrote: On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote: I think so, and we probably should consider the two cases separately since the right answer could reasonably differ for different resource types. I am rea

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On Wed, 2015-02-18 at 15:05 +, Julien Grall wrote: > > On 18/02/2015 14:37, Ian Campbell wrote: > > On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote: > > I think so, and we probably should consider the two cases separately > > since the right answer could reasonably differ for different r

[Xen-devel] [PATCH] xen: arm64: more useful logging on bad trap.

Dump the register state before panicing so we have some clue where the issue occurred. Also decode the ESR register a bit to save having to grab a pen and paper. ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as we already do correctly in the main trap handler. While here noti

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On Wed, 2015-02-18 at 15:13 +, Julien Grall wrote: > > On 18/02/2015 14:37, Ian Campbell wrote: > > I am reasonably convinced that for MMIO (+IO+CFG space) we should map > > everything as described by the ranges property of the top most node, it > > can be considered an analogue to / extension

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

flight 34656 qemu-mainline real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/34656/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64 7 debian-hvm-install fail REGR. vs. 33480 test-amd64-i38

Re: [Xen-devel] BUG - xen-netback stats interface limited to 32-bit values on 64 bit systems

create ^ thanks On Thu, 2015-02-12 at 20:47 +0100, Atom2 wrote: > Hi guys, > I am forwarding this message after initially having confirmed with Ian > Campbell on the user list that there's really an issue - please see > further below. > > I am currently running xen-4.3.3 on gentoo (dom0 is base

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: allow console=hvc0 to be omitted for guests

On Wed, 2015-02-18 at 13:51 +, Julien Grall wrote: > From: Ard Biesheuvel > > This patch registers hvc0 as the preferred console if no console > has been specified explicitly on the kernel command line. > > The purpose is to allow platform agnostic kernels and boot images > (such as distro i

[Xen-devel] Processed: Re: BUG - xen-netback stats interface limited to 32-bit values on 64 bit systems

Processing commands for x...@bugs.xenproject.org: > create ^ Created new bug #49 rooted at `<54dd036e.4060...@web2web.at>' Title: `Re: BUG - xen-netback stats interface limited to 32-bit values on 64 bit systems' > thanks Finished processing. Modified/created Bugs: - 49: http://bugs.xenproject.

Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

On 18/02/2015 15:18, Ian Campbell wrote: On Wed, 2015-02-18 at 15:05 +, Julien Grall wrote: On 18/02/2015 14:37, Ian Campbell wrote: On Wed, 2015-02-18 at 14:19 +, Julien Grall wrote: I think so, and we probably should consider the two cases separately since the right answer could re

[Xen-devel] [PATCH v3] vsprintf: Make sure argument to %pX specifier is valid

If invalid pointer (i.e. something smaller than HYPERVISOR_VIRT_START) is passed for %*ph/%pv/%ps/%pS format specifiers then print value of the pointer in parentheses. For example: struct vcpu *v0 = NULL; struct vcpu *v1 = (void *)0xffUL; unsigned val = 0xab; unsigned *ptr = &val; unsigned *

  1   2   >