[Xen-devel] [PATCH V3] x86/monitor: Disallow setting mem_access_emulate_each_rep when vm_event is NULL

It is meaningless (and potentially dangerous - see hvmemul_virtual_to_linear()) to set mem_access_emulate_each_rep before xc_monitor_enable() (which allocates vcpu->arch.vm_event) has been called, so return an error from the XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP hypercall when that is the case.

[Xen-devel] [xen-4.6-testing baseline-only test] 44288: trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 44288 xen-4.6-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44288/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64

Re: [Xen-devel] [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Thu, Mar 17, 2016 at 03:56:47PM -0600, Toshi Kani wrote: > On Wed, 2016-03-16 at 00:29 +0100, Luis R. Rodriguez wrote: > > On x86 Linux code we now have ioremap_uc() that can't use MTRR behind the > > scenes, why would something like this on the BIOS not be possible? That > > ultimately uses

Re: [Xen-devel] [PATCH v6 21/24] xsplice: Stacking build-id dependency checking.

On Fri, Apr 08, 2016 at 07:19:37PM +0100, Andrew Cooper wrote: > On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: > > diff --git a/Config.mk b/Config.mk > > index db70638..4b6f3f5 100644 > > --- a/Config.mk > > +++ b/Config.mk > > @@ -134,6 +134,7 @@ ifeq ($(call ld-ver-build-id,$(LD)),n) > >

Re: [Xen-devel] [PATCH v6 07/24] arm/x86/vmap: Add vmalloc_type and vm_init_type

On Fri, Apr 08, 2016 at 11:19:24AM -0600, Jan Beulich wrote: > >>> On 08.04.16 at 16:22, wrote: > > On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: > >> +void vm_free_type(const void *, enum vmap_type); > >> +void vunmap_type(const void *, enum vmap_type); > >> +void

Re: [Xen-devel] [PATCH v6 11/24] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

> diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown > index d4e7d75..8d2d413 100644 > --- a/docs/misc/xsplice.markdown > +++ b/docs/misc/xsplice.markdown > @@ -330,6 +330,41 @@ When reverting a patch, the hypervisor iterates over > each `xsplice_patch_func` > and the core code

Re: [Xen-devel] [PATCH v6 09/24] xsplice: Implement payload loading

On Fri, Apr 08, 2016 at 04:50:10PM -0600, Jan Beulich wrote: > >>> On 09.04.16 at 00:45, wrote: > > On Fri, Apr 08, 2016 at 03:18:09PM -0600, Jan Beulich wrote: > >> >>> On 08.04.16 at 23:10, wrote: > >> >> > +int arch_xsplice_perform_rela(struct

[Xen-devel] [PATCH v1 0/2] x86/init: extend quirk use

...@kernel.org [2] https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160408-pv-disabled-v5 Luis R. Rodriguez (2): x86/init: disable pnpbios for X86_SUBARCH_INTEL_MID x86/init: disable pnpbios for X86_SUBARCH_CE4100 arch/x86/kernel/platform-quirks.c | 5 +++-- 1 file

[Xen-devel] [PATCH v1 1/2] x86/init: disable pnpbios for X86_SUBARCH_INTEL_MID

As per hpa Intel MID platforms can also disable pnpbios [0]. [0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com Suggested-by: H. Peter Anvin Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/platform-quirks.c | 4 +--- 1 file changed, 1 insertion(+),

[Xen-devel] [PATCH v1 2/2] x86/init: disable pnpbios for X86_SUBARCH_CE4100

As per hpa CE4100 platforms can also disable pnpbios [0]. [0] http://lkml.kernel.org/r/5702b5c2.7070...@zytor.com Suggested-by: H. Peter Anvin Signed-off-by: Luis R. Rodriguez --- arch/x86/kernel/platform-quirks.c | 3 +++ 1 file changed, 3 insertions(+)

Re: [Xen-devel] [PATCH v6 00/21] x86: Improvements to cpuid handling for guests

On Fri, Apr 08, 2016 at 09:31:36PM +0100, Andrew Cooper wrote: > This series is available in git form at: > http://xenbits.xen.org/git-http/people/andrewcoop/xen.git levelling-v6 And in 'for-staging'. > > Very few changes from v5: > * Change the PKU feature depdendency from PAE to LM > *

Re: [Xen-devel] [PATCH v5 00/14] x86: remove paravirt_enabled()

BTW also here's a tree if someone needs it: https://git.kernel.org/cgit/linux/kernel/git/mcgrof/linux-next.git/log/?h=20160408-pv-disabled-v5 Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 14/14] x86/paravirt: remove paravirt_enabled()

That that paravirt_enabled() is replaced with proper x86 semantics we can remove it. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 1 - arch/x86/include/asm/processor.h | 1 -

[Xen-devel] [PATCH v5 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

[Xen-devel] [PATCH v5 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[Xen-devel] [PATCH v5 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[Xen-devel] [PATCH v5 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [PATCH v5 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Reviewed-by: David Vrabel Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+)

[Xen-devel] [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

[Xen-devel] [PATCH v5 03/14] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly

Be explicit and make use of X86_SUBARCH_LGUEST directly. Signed-off-by: Luis R. Rodriguez --- tools/lguest/lguest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lguest/lguest.c b/tools/lguest/lguest.c index 80159e6811c2..ff0aa580c6e1 100644

[Xen-devel] [PATCH v5 08/14] apm32: remove paravirt_enabled() use

There is already a check for apm_info.bios == 0, the apm_info.bios is set from the boot_params.apm_bios_info. Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the apm_bios.info. The Xen folks are sure force disable to 0 is not needed because apm_info

[Xen-devel] [PATCH v5 14/14] x86/paravirt: remove paravirt_enabled()

That that paravirt_enabled() is replaced with proper x86 semantics we can remove it. Signed-off-by: Luis R. Rodriguez --- arch/x86/include/asm/paravirt.h | 5 - arch/x86/include/asm/paravirt_types.h | 1 - arch/x86/include/asm/processor.h | 1 -

[Xen-devel] [PATCH v5 02/14] x86/xen: use X86_SUBARCH_XEN for PV guest boots

The use of subarch should have no current effect on Xen PV guests, as such this should have no current functional effects. Reviewed-by: David Vrabel Signed-off-by: Luis R. Rodriguez --- arch/x86/xen/enlighten.c | 1 + 1 file changed, 1 insertion(+)

[Xen-devel] [PATCH v5 13/14] x86/init: rename ebda code file

This makes it clearer what this is. Signed-off-by: Luis R. Rodriguez --- arch/x86/Makefile | 2 +- arch/x86/kernel/Makefile | 2 +- arch/x86/kernel/{head.c => ebda.c} | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename

[Xen-devel] [PATCH v5 11/14] pnpbios: replace paravirt_enabled() check with legacy device check

Since we are removing paravirt_enabled() replace it with a logical equivalent. Even though PNPBIOS is x86 specific we add an arch-specific type call, which can be implemented by any architecture to show how other legacy attribute devices can later be also checked for with other ACPI legacy

[Xen-devel] [PATCH v5 00/14] x86: remove paravirt_enabled()

This v5 updates the subarch documentation to annotate that X86_SUBARCH_XEN can be use for both Xen dom0 and domU, and adds an optional x86_platform.set_legacy_features() in order to deal with further platform legacy fine tunings when the platform requires further semantics than what is currently

[Xen-devel] [PATCH v5 01/14] x86/boot: enumerate documentation for the x86 hardware_subarch

Although hardware_subarch has been in place since the x86 boot protocol 2.07 it hasn't been used much. Enumerate current possible values to avoid misuses and help with semantics later at boot time should this be used further. These enums should only ever be used by architecture x86 code, and all

[Xen-devel] [PATCH v5 07/14] tools/lguest: force disable tboot and apm

The paravirt_enabled() check is going away, the area tossed to the kernel on lguest is not zerored out, so ensure lguest force disables tboot and apm just in case the kernel file being read might have this set for whatever reason. Signed-off-by: Luis R. Rodriguez ---

[Xen-devel] [PATCH v5 12/14] x86, ACPI: parse ACPI_FADT_LEGACY_DEVICES

ACPI 5.2.9.3 IA-PC Boot Architecture flag ACPI_FADT_LEGACY_DEVICES can be used to determine if a system has legacy devices LPC or ISA devices. The x86 platform already has a struct which lists known associated legacy devices, we start off careful only by disabling root devices we should not

[Xen-devel] [PATCH v5 05/14] x86, ACPI: move ACPI_FADT_NO_CMOS_RTC check to ACPI boot code

This moves the ACPI specific check into the ACPI boot code, it also takes advantage of the x86_platform.legacy.rtc which is checked for already on the RTC initialization code. This lets us remove the nasty #ifdefery and consolidate the checks to use only one toggle to disable the RTC init code.

[Xen-devel] [PATCH v5 10/14] x86/cpu/intel: remove not needed paravirt_enabled() for f00f work around

The X86_BUG_F00F work around is responsible for fixing up the error generated on attempted F00F exploitation from an OOPS to a SIGILL. There is no reason why this code should not be allowed to run on PV guest on a F00F-affected CPU -- it would simply never trigger. The pv_enabled() check was there

[Xen-devel] [PATCH v5 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

We have 4 types of x86 platforms that disable RTC: * Intel MID * Lguest - uses paravirt * Xen dom-U - uses paravirt * x86 on legacy systems annotated with an ACPI legacy flag We can consolidate all of these into a platform specific legacy quirk set early in boot through

[Xen-devel] [PATCH v5 06/14] x86/init: use a platform legacy quirk for ebda

This replaces the paravirt_enabled() check with a proper x86 legacy platform quirk. As per 0-day, this bumps the vmlinux size using i386-tinyconfig as follows: TOTAL TEXT init.text x86_early_init_platform_quirks() +39 +35+35 +25 That's a 4 byte total overhead, the rest is

[Xen-devel] [PATCH v5 09/14] x86/tboot: remove paravirt_enabled()

There is already a check for boot_params.tboot_addr prior to paravirt_enabled(). Both Xen and lguest, which are also the only ones that set paravirt_enabled to true, never set the boot_params.tboot_addr. The Xen folks are sure a force disable to 0 is not needed, we recently forced disabled this on

Re: [Xen-devel] [RFC PATCH 2/2] build: convert crash_debug to Kconfig

>>> On 09.04.16 at 01:24, wrote: On 25.03.16 at 22:02, wrote: >> On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote: >>> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote: --- a/xen/Kconfig.debug +++ b/xen/Kconfig.debug @@ -4,3

Re: [Xen-devel] [RFC PATCH 2/2] build: convert crash_debug to Kconfig

>>> On 25.03.16 at 22:02, wrote: > On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote: >> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote: >>> --- a/xen/Kconfig.debug >>> +++ b/xen/Kconfig.debug >>> @@ -4,3 +4,14 @@ menuconfig DEBUG >>> ---help--- >>> If

Re: [Xen-devel] [RFC PATCH 1/2] build: add debug menu to Kconfig

>>> On 24.03.16 at 17:48, wrote: > There are a number of debugging options for Xen so the idea is to have a > menu to group them all together. > > Signed-off-by: Doug Goldstein > --- > This is more of an RFC than a merge request. If this seems reasonable

Re: [Xen-devel] x86 patch ping

>>> On 08.04.16 at 14:18, wrote: > The SMEP/SMAP series is still very concerning. I need to follow up on > the performance testing, but it currently looks like no real improvement > on the 40-70% performance hit for 32bit PV guests. Well, we didn't really expect much

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

flight 89432 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/89432/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454

Re: [Xen-devel] [PATCH v6 09/24] xsplice: Implement payload loading

>>> On 09.04.16 at 00:45, wrote: > On Fri, Apr 08, 2016 at 03:18:09PM -0600, Jan Beulich wrote: >> >>> On 08.04.16 at 23:10, wrote: >> >> > +int arch_xsplice_perform_rela(struct xsplice_elf *elf, >> >> > + const struct

Re: [Xen-devel] [PATCH v6 08/24] xsplice: Add helper elf routines

>>> On 09.04.16 at 00:10, wrote: > On 08/04/16 22:26, Konrad Rzeszutek Wilk wrote: >> On Fri, Apr 08, 2016 at 03:53:44PM +0100, Andrew Cooper wrote: >>> On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: +nsym = symtab_sec->sec->sh_size /

Re: [Xen-devel] [PATCH v6 09/24] xsplice: Implement payload loading

On Fri, Apr 08, 2016 at 03:18:09PM -0600, Jan Beulich wrote: > >>> On 08.04.16 at 23:10, wrote: > >> > +int arch_xsplice_perform_rela(struct xsplice_elf *elf, > >> > + const struct xsplice_elf_sec *base, > >> > +

Re: [Xen-devel] [PATCH v5 21/21] tools/libxc: Calculate xstate cpuid leaf from guest information

>>> On 08.04.16 at 23:45, wrote: > On 08/04/16 22:00, Jan Beulich wrote: > On 07.04.16 at 13:57, wrote: >>> v5: >>> * Reintroduce PKRU, (again, lost due to rebasing). >>> * Rewrite the commit message and comments to try and better

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On 08/04/16 23:06, Andy Lutomirski wrote: > On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini wrote: >> >> On 08/04/2016 18:00, Andy Lutomirski wrote: >>> But %ss can be loaded with 0 on 64-bit kernels. (I assume that >>> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but

Re: [Xen-devel] [PATCH v2 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server

>>> On 31.03.16 at 12:53, wrote: > +static int mem_write(const struct hvm_io_handler *handler, > + uint64_t addr, > + uint32_t size, > + uint64_t data) > +{ > +struct domain *currd = current->domain; > +

[Xen-devel] [xen-4.4-testing baseline-only test] 44286: regressions - FAIL

This run is configured for baseline tests only. flight 44286 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44286/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair 9

Re: [Xen-devel] [PATCH v6 08/24] xsplice: Add helper elf routines

On 08/04/16 22:26, Konrad Rzeszutek Wilk wrote: > On Fri, Apr 08, 2016 at 03:53:44PM +0100, Andrew Cooper wrote: >> On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: >>> +static int elf_resolve_sections(struct xsplice_elf *elf, const void *data) >>> +{ >>> +struct xsplice_elf_sec *sec; >>> +

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On Fri, Apr 8, 2016 at 10:12 AM, Paolo Bonzini wrote: > > > On 08/04/2016 18:00, Andy Lutomirski wrote: >> But %ss can be loaded with 0 on 64-bit kernels. (I assume that >> loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on >> this, since it only really

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Fri, Apr 08, 2016 at 03:16:14PM +0100, George Dunlap wrote: > On 07/04/16 19:51, Luis R. Rodriguez wrote: > > While Andrew's position is right in that perhaps only Xen tools have to deal > > with the HVMLite specific entry, it would also still mean diverging from > > ARM's > > own EFI entry

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 06, 2016 at 12:23:47PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Apr 06, 2016 at 12:05:16PM -0400, Konrad Rzeszutek Wilk wrote: > > On Wed, Apr 06, 2016 at 04:02:40PM +0100, Matt Fleming wrote: > > > On Wed, 06 Apr, at 12:07:36PM, George Dunlap wrote: > > > > > > > > So rather

Re: [Xen-devel] [PATCH v2 2/3] x86/ioreq server: Rename p2m_mmio_write_dm to p2m_ioreq_server

>>> On 31.03.16 at 12:53, wrote: > --- a/xen/include/public/hvm/hvm_op.h > +++ b/xen/include/public/hvm/hvm_op.h > @@ -83,7 +83,7 @@ typedef enum { > HVMMEM_ram_rw, /* Normal read/write guest RAM */ > HVMMEM_ram_ro, /* Read-only;

Re: [Xen-devel] [PATCH v5 21/21] tools/libxc: Calculate xstate cpuid leaf from guest information

On 08/04/16 22:00, Jan Beulich wrote: On 07.04.16 at 13:57, wrote: >> The existing logic is broken for heterogeneous migration. By always >> advertising the host maximum xstate, a migration to a less capable host >> always >> fails as Xen cannot accomodate the

Re: [Xen-devel] [PATCH v6 08/24] xsplice: Add helper elf routines

On Fri, Apr 08, 2016 at 03:53:44PM +0100, Andrew Cooper wrote: > On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: > > +static int elf_resolve_sections(struct xsplice_elf *elf, const void *data) > > +{ > > +struct xsplice_elf_sec *sec; > > +unsigned int i; > > +Elf_Off delta; > > +

Re: [Xen-devel] [PATCH v6 09/24] xsplice: Implement payload loading

>>> On 08.04.16 at 23:10, wrote: >> > +int arch_xsplice_perform_rela(struct xsplice_elf *elf, >> > + const struct xsplice_elf_sec *base, >> > + const struct xsplice_elf_sec *rela) >> > +{ >> > +const Elf_RelA

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

On Fri, Apr 08, 2016 at 03:11:17PM -0600, Jan Beulich wrote: > >>> On 08.04.16 at 22:50, wrote: > > On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote: > >> >>> On 08.04.16 at 21:23, wrote: > >> > @@ -57,10 +60,19 @@ SECTIONS > >> >

Re: [Xen-devel] [PATCH v6 09/24] xsplice: Implement payload loading

> > +int arch_xsplice_perform_rela(struct xsplice_elf *elf, > > + const struct xsplice_elf_sec *base, > > + const struct xsplice_elf_sec *rela) > > +{ > > +const Elf_RelA *r; > > +unsigned int symndx, i; > > +uint64_t val; > > +

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

>>> On 08.04.16 at 22:50, wrote: > On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote: >> >>> On 08.04.16 at 21:23, wrote: >> > @@ -57,10 +60,19 @@ SECTIONS >> > *(.lockprofile.data) >> > __lock_profile_end = .; >> >

Re: [Xen-devel] [PATCH v5 21/21] tools/libxc: Calculate xstate cpuid leaf from guest information

>>> On 07.04.16 at 13:57, wrote: > The existing logic is broken for heterogeneous migration. By always > advertising the host maximum xstate, a migration to a less capable host always > fails as Xen cannot accomodate the xcr0_accum in the migration stream. I don't

[Xen-devel] [PATCH v6 14/21] xen+tools: Export maximum host and guest cpu featuresets via SYSCTL

And provide stubs for toolstack use. Signed-off-by: Andrew Cooper Acked-by: Wei Liu Acked-by: David Scott Acked-by: Jan Beulich Acked-by: Daniel De Graaf Reviewed-by: Konrad Rzeszutek

[Xen-devel] [PATCH v6 17/21] tools/libxc: Expose the automatically generated cpu featuremask information

Signed-off-by: Andrew Cooper Acked-by: Wei Liu Reviewed-by: Konrad Rzeszutek Wilk --- CC: Ian Jackson New in v2 --- tools/libxc/Makefile | 9 ++ tools/libxc/include/xenctrl.h | 14

[Xen-devel] [PATCH v6 20/21] tools/libxc: Use featuresets rather than guesswork

It is conceptually wrong to base a VM's featureset on the features visible to the toolstack which happens to construct it. Instead, the featureset used is either an explicit one passed by the toolstack, or the default which Xen believes it can give to the guest. Collect all the feature

[Xen-devel] [PATCH v6 19/21] tools/libxc: Wire a featureset through to cpuid policy logic

Later changes (Patch titled "tools/libxc: Use featuresets rather than guesswork") will cause the cpuid generation logic to seed their information from a featureset. This patch adds the infrastructure to specify a featureset, and will obtain the appropriate defaults from Xen if omitted.

[Xen-devel] [PATCH v6 11/21] x86/cpu: Context switch cpuid masks and faulting state in context_switch()

A single ctxt_switch_levelling() function pointer is provided (defaulting to an empty nop), which is overridden in the appropriate $VENDOR_init_levelling(). set_cpuid_faulting() is made private and included within intel_ctxt_switch_levelling(). One (attempted) functional change is that the

[Xen-devel] [PATCH v6 15/21] tools/libxc: Modify bitmap operations to take void pointers

The type of the pointer to a bitmap is not interesting; it does not affect the representation of the block of bits being pointed to. Make the libxc functions consistent with those in Xen, so they can work just as well with 'unsigned int *' based bitmaps. As part of doing so, change the

[Xen-devel] [PATCH v6 21/21] tools/libxc: Calculate xstate cpuid leaf from guest information

The existing logic is broken for heterogeneous migration. By always advertising the host maximum xstate, a migration to a less capable host always fails as Xen cannot accomodate the xcr0_accum in the migration stream. By calculating xstate from the feature information (which a multi-host

[Xen-devel] [PATCH v6 12/21] x86/pv: Provide custom cpumasks for PV domains

And use them in preference to cpumask_defaults on context switch. HVM domains must not be masked (to avoid interfering with cpuid calls within the guest), so always lazily context switch to the host default. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v6 16/21] tools/libxc: Use public/featureset.h for cpuid policy generation

Rather than having a different local copy of some of the feature definitions. Modify the xc_cpuid_x86.c cpumask helpers to appropiately truncate the new values. As some of the feature have been renamed in the public API, similar renames are made here. Signed-off-by: Andrew Cooper

[Xen-devel] [PATCH v6 10/21] x86/cpu: Rework Intel masking/faulting setup

This patch is best reviewed as its end result rather than as a diff, as it rewrites almost all of the setup. On the BSP, cpuid information is used to evaluate the potential available set of masking MSRs, and they are unconditionally probed, filling in the availability information and hardware

[Xen-devel] [PATCH v6 13/21] x86/domctl: Update PV domain cpumasks when setting cpuid policy

This allows PV domains with different featuresets to observe different values from a native cpuid instruction, on supporting hardware. It is important to leak the host view of X2APIC, HTT and CMP_LEGACY through to guests, even though they could be hidden. These flags affect how to interpret

[Xen-devel] [PATCH v6 18/21] tools: Utility for dealing with featuresets

It is able to reports the current featuresets; both the static masks and dynamic featuresets from Xen, or to decode an arbitrary featureset into `/proc/cpuinfo` style strings. Signed-off-by: Andrew Cooper Acked-by: Wei Liu Reviewed-by: Konrad

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote: > >>> On 08.04.16 at 21:23, wrote: > > On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote: > >> >>> On 08.04.16 at 19:06, wrote: > >> > So that when xen.efi is linked with this

Re: [Xen-devel] [PATCH v6 06/24] x86: Alter nmi_callback_t typedef

On Thu, Apr 07, 2016 at 09:13:58PM +0100, Andrew Cooper wrote: > On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: > > Drop paranthesis and function pointer on nmi_callback_t typedef. > > > > Make it more inline with how x86 maintainers want function > > typedefs to be. > > > > Signed-off-by: Konrad

Re: [Xen-devel] HVMLite / PVHv2 - using x86 EFI boot entry

On Wed, Apr 06, 2016 at 10:40:08AM +0100, David Vrabel wrote: > On 06/04/16 03:40, Luis R. Rodriguez wrote: > > > > * You don't need full EFI emulation > > I think needing any EFI emulation inside Xen (which is where it would > need to be for dom0) is not suitable because of the increase in

[Xen-devel] [xen-unstable test] 89418: regressions - FAIL

flight 89418 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/89418/ 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. 86491 build-i386-libvirt

[Xen-devel] [PATCH v6 09/21] x86/cpu: Rework AMD masking MSR setup

This patch is best reviewed as its end result rather than as a diff, as it rewrites almost all of the setup. On the BSP, cpuid information is used to evaluate the potential available set of masking MSRs, and they are unconditionally probed, filling in the availability information and hardware

[Xen-devel] [PATCH v6 05/21] xen/x86: Improve disabling of features which have dependencies

APIC and XSAVE have dependent features, which also need disabling if Xen chooses to disable a feature. Use setup_clear_cpu_cap() rather than clear_bit(), as it takes care of dependent features as well. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich

[Xen-devel] [PATCH v6 01/21] xen/x86: Annotate VM applicability in featureset

Use attributes to specify whether a feature is applicable to be exposed to: 1) All guests 2) HVM guests 3) HVM HAP guests and, via absence of an attribute, to no guests. There is no current need for other categories (e.g. PV-only features), and such categories should not be introduced if

[Xen-devel] [PATCH v6 03/21] xen/x86: Generate deep dependencies of features

Some features depend on other features. Working out and maintaining the exact dependency tree is complicated, so it is expressed in the automatic generation script. At runtime, Xen needs to be disable all features which are dependent on a feature being disabled. Because of the flattening

[Xen-devel] [PATCH v6 08/21] x86/cpu: Sysctl and common infrastructure for levelling context switching

A toolstack needs to know how much control Xen has over the visible cpuid values in PV guests. Provide an explicit mechanism to query what Xen is capable of. This interface will currently report no capabilities. This change is scaffolding for future patches, which will introduce detection and

[Xen-devel] [PATCH v6 02/21] xen/x86: Calculate maximum host and guest featuresets

All of this information will be used by the toolstack to make informed levelling decisions for VMs, and by Xen to sanity check toolstack-provided information. The split between the shadow and hap HVM masks is necessary due to the lack of a "get cpuid policy" hypercall. Multi-host toolstacks

[Xen-devel] [PATCH v6 07/21] x86/cpu: Move set_cpumask() calls into c_early_init()

Before c/s 44e24f8567 "x86: don't call generic_identify() redundantly", the commandline-provided masks would take effect in Xen's view of the processor features. As the masks got applied after the query for features, the redundant call to generic_identify() would clobber the pre-masking feature

[Xen-devel] [PATCH v6 04/21] xen/x86: Clear dependent features when clearing a cpu cap

When clearing a cpu cap, clear all dependent features. This avoids having a featureset with intermediate features disabled, but leaf features enabled. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich Reviewed-by: Konrad Rzeszutek Wilk

[Xen-devel] [PATCH v6 00/21] x86: Improvements to cpuid handling for guests

This series is available in git form at: http://xenbits.xen.org/git-http/people/andrewcoop/xen.git levelling-v6 Very few changes from v5: * Change the PKU feature depdendency from PAE to LM * Bugfix for HVM CPUID.0xd[1].ebx when %xcr0 is empty * Tweak command line parsing in xen-cpuid to

[Xen-devel] [PATCH v6 06/21] xen/x86: Improvements to in-hypervisor cpuid sanity checks

Currently, {pv,hvm}_cpuid() has a large quantity of essentially-static logic for modifying the features visible to a guest. A lot of this can be subsumed by {pv,hvm}_featuremask, which identify the features available on this hardware which could be given to a PV or HVM guest. This is a step in

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

>>> On 08.04.16 at 21:23, wrote: > On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote: >> >>> On 08.04.16 at 19:06, wrote: >> > So that when xen.efi is linked with this build_id.o (in v5, now called >> > notes.o in v6) >> > it can

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

>>> On 08.04.16 at 20:47, wrote: > On Fri, Apr 08, 2016 at 04:49:00PM +0100, Ross Lagerwall wrote: >> On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote: >> >On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote: >> >On 24.03.16 at 21:00,

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

> diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile > index 5099430..a6dae4c 100644 > --- a/xen/arch/x86/efi/Makefile > +++ b/xen/arch/x86/efi/Makefile > @@ -6,7 +6,7 @@ create = test -e $(1) || touch -t 19990101 $(1) > > efi := y$(shell rm -f disabled) > efi := $(if

Re: [Xen-devel] [PATCH v6 17/24] build_id: Provide ld-embedded build-ids

On Fri, Apr 08, 2016 at 07:07:02PM +0100, Andrew Cooper wrote: > On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: > > > > +notes.o: $(TARGET)-syms > > + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin > > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \ > > +

[Xen-devel] [xen-4.5-testing baseline-only test] 44280: regressions - FAIL

This run is configured for baseline tests only. flight 44280 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44280/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 14

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote: > >>> On 08.04.16 at 19:06, wrote: > > "Since you put the notes into .rodata anyway, why name the section .note" > > > > Perhaps you mean - why name the section .note.gnu_build-id ? > > Sure - .note or .note.*.

[Xen-devel] [distros-debian-stretch test] 44282: tolerable trouble: blocked/broken

flight 44282 distros-debian-stretch real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44282/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 44260 build-armhf

[Xen-devel] [distros-debian-jessie test] 44281: trouble: blocked/broken/pass

flight 44281 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44281/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 3 host-install(3) broken

[Xen-devel] [distros-debian-sid test] 44283: tolerable trouble: blocked/broken

flight 44283 distros-debian-sid real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44283/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf-pvops 3 host-install(3) broken like 44268 build-armhf

[Xen-devel] [distros-debian-snapshot test] 44284: tolerable trouble: blocked/broken

flight 44284 distros-debian-snapshot real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44284/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-armhf 3 host-install(3) broken like 44272

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

> Lastly, we MUST call --binary-id=sha1 on all linker invocation so that > symbol offsets don't changes (which means we have multiple binary > ids - except that the last one is the final one). Without this change, > the symbol table embedded in Xen are incorrect - some of the

Re: [Xen-devel] [PATCH v5 19/28] build_id: Provide ld-embedded build-ids

On Fri, Apr 08, 2016 at 04:49:00PM +0100, Ross Lagerwall wrote: > On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote: > >On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote: > >On 24.03.16 at 21:00, wrote: > >>>The version of ld that first implemented

Re: [Xen-devel] [PATCH v4 04/14] x86/rtc: replace paravirt rtc check with platform legacy quirk

On Fri, Apr 08, 2016 at 08:37:44AM -0400, Boris Ostrovsky wrote: > On 04/08/2016 03:59 AM, Juergen Gross wrote: > >On 08/04/16 09:36, Luis R. Rodriguez wrote: > >>On Fri, Apr 8, 2016 at 12:13 AM, Juergen Gross wrote: > >>>On 08/04/16 08:56, Luis R. Rodriguez wrote: > On Thu,

Re: [Xen-devel] [PATCH v6 02/24] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

> +static int xsplice_list(xen_sysctl_xsplice_list_t *list) > +{ > +xen_xsplice_status_t status; > +struct payload *data; > +unsigned int idx = 0, i = 0; > +int rc = 0; > + > +if ( list->nr > 1024 ) > +return -E2BIG; > + > +if ( list->pad ) > +return

Re: [Xen-devel] [PATCH] docs: add misc/qemu-backends.txt

>>> +Xenstore the backend information is presented there. is built >> That looks to be missing an verb, no it has a verb, something is off with >> that. >> >> XenStore presents the backend information there? > No, qemu is presenting the information in Xenstore. "Xenstore" is not the start of

Re: [Xen-devel] [PATCH v6 24/24] MAINTAINERS/xsplice: Add myself and Ross as the maintainers.

On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote: > If you have a patch for xSplice send it our way! > > Signed-off-by: Ross Lagerwall > Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Andrew Cooper (FWIW)

  1   2   3   4   >