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.
S
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
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 set
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)
> > build
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 *vmalloc_type(size_t size, enu
> 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
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 xsplice_elf *elf,
> >> >> > +
...@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
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(+), 3 deletions(-)
diff --git a/arch/x
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(+)
diff --git a/arch/x86/kernel/platform-
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
> * Bugf
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
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 -
arch/x86/kernel/kvm.c
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
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
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.
Th
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
---
tools/lguest/lguest.c | 6 ++
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(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/
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 i386_start_kernel(
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
--- a/tools/lguest/lgu
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 l
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 -
arch/x86/kernel/kvm.c
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(+)
diff --git a/arch/x86/xen/enlighten.c b/arch/
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 arch/x86/kernel/{head.c => ebda.c} (100%
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 attribut
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
av
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.
Th
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
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
---
tools/lguest/lguest.c | 6 ++
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 regress
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 t
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 i386_start_kernel(
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 a
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
>>> 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 +4,14 @@ menuconfig DEBUG
---he
>>> 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 you want to debug Xen
>>> 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 I'll
> add all the other debugging option
>>> 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 of a change for 32-bit guest
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
test-amd64-i386-fre
>>> 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 xsplice_elf_sec *base,
>> >> > +
>>> 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 / symtab_sec->sec->sh_entsize;
>>> Has anything checked
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,
> >> > + const struct xsplice_elf_se
>>> 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 explain why I
>>> am
>>>deliberatly removing host-speci
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 I'm vague on
>>> this
>>> 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;
> +unsigned long gmfn = paddr_
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 xen-boot/src
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;
>>> +u
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 matters to hypervisor co
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 onl
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 than
>>> 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; writes are discarded */
> HVM
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 xcr0_accum in the migration st
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;
> > +int
>>> 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 *r;
>> > +unsigned int
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
> >> > *(.lockprofile.data)
> >> > __lock_prof
> > +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;
> > +
>>> 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 = .;
>> > #endif
>> > -
>> > -_erodata = .; /*
>>> 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 understand this - xcr0_accum is
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
tools/libxc/xc_cpuid_x86.c| 75 +++
3 files c
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 Wilk
---
v2:
* Rebased to use libxencall
* Improve hypercall documentation
v3:
* Provide libxc implementa
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.
Signed-off
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 faulti
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 implementa
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
toolstac
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
Reviewed-by: Konrad Rzeszutek Wil
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 manipulati
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
Acked-by: Wei
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 defa
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 Rzeszutek Wilk
---
CC: Ian Jackson
v2: No linking
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
other
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 build_id.o (in v5, now called
> >> > notes.o in v
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
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
>
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
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
Reviewed-by: Konrad Rzeszutek Wilk
---
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 defa
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 possib
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 perform
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 sw
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 (i.e.
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 in
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
---
v3:
* Style fixes. Use __test_and_set_bit()
---
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 avoi
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 th
>>> 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 encapsulate __note_gnu_build_id_start and __note_gnu_bui
>>> 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, wrote:
>> >>>The version of ld that first imple
> 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 $(efi)
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 \
> > +
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 guest-savere
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.*.
>
> > So that when xen.
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
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 REG
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
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
build-armhf-pv
> 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 value
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 --build-id is v2.18.
> >>>Hence w
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, Apr 7, 2016 at 11:
> +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 -EINVAL;
>>> +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 the
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)
___
Xen-devel mailing list
Xen-devel@lists.
1 - 100 of 326 matches
Mail list logo