>>> On 04.01.18 at 21:33, wrote:
> @@ -375,12 +385,52 @@ static void __init PrintErrMesg(const CHAR16 *mesg,
> EFI_STATUS ErrCode)
>
> static unsigned int __init get_argv(unsigned int argc, CHAR16 **argv,
> CHAR16 *cmdline, UINTN cmdsize,
> -
flight 118170 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118170/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail like 118036
test-xtf-amd64-amd64-2 49 xt
>>> On 18.01.18 at 19:55, wrote:
> On 02/01/18 09:28, manish.ja...@linaro.org wrote:
>> From: Manish Jaggi
>>
>> Add kalloc kfree functions from linux kernel.
>
> This does not description all the functions you added. But I am really
> not convinced this is the right place to do that.
>
> Thi
>>> On 18.01.18 at 18:04, wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -75,6 +75,8 @@ ALL_OBJS := $(ALL_OBJS-y)
> CFLAGS-y += -MMD -MF $(@D)/.$(@F).d
>
> CFLAGS += $(CFLAGS-y)
> +# allow extra CFLAGS externally via EXTRA_CFLAGS
> +CFLAGS += $(EXTRA_CFLAGS)
This is too unspecific a na
>>> On 19.01.18 at 08:21, wrote:
> Maybe this is a silly question but which tag are the 4.10 XPTI
> commits from https://xenbits.xen.org/xsa/xsa254/README.pti against?
> They don't apply to RELEASE-4.10.0.
As always with security fixes, they are against the tip of the
respective staging tree at t
On Fri, Jan 19, 2018 at 06:11:00AM +, HW42 wrote:
> Roger Pau Monne:
> > Previously when trying to boot a PV capable but not PVH capable kernel
> > inside of a PVH container xc_dom_guest_type would succeed and return a
> > PV guest type, which would lead to failures later on in the build
> > pr
>>> On 18.01.18 at 19:16, wrote:
> Modify early boot code to relocate pvh info as well, so that we can be
> sure __va in __start_xen works.
>
> Signed-off-by: Wei Liu
Reviewed-by: Jan Beulich
with one cosmetic request:
> @@ -29,6 +29,10 @@ asm (
> #include "../../../include/xen/multiboot.h"
>>> On 18.01.18 at 19:16, wrote:
> This reverts commit 7d6f958d9d18c54017f5ef6e299a08037f035747.
>
> Now we have PVH info relocation support, this change is no longer
> needed.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailin
>>> On 18.01.18 at 21:28, wrote:
> Thank you, Julien. Ideally, I would like to do the backports after
> OSSTest passes its tests on those changes. In practice, for the sake of
> mitigating SP2 as soon as possible, tomorrow (Friday) I might do the
> backports anyway, if OSSTest is still behind on o
On 18/01/18 18:16, Wei Liu wrote:
> Modify early boot code to relocate pvh info as well, so that we can be
> sure __va in __start_xen works.
>
> Signed-off-by: Wei Liu
:(
It was a fear of code like this which caused me to go with the gross
hack in the short term.
Let me see if I can clean it up
On Thu, Jan 18, 2018 at 06:30:05PM +, Andrew Cooper wrote:
> On 18/01/18 18:28, Wei Liu wrote:
> > On Thu, Jan 18, 2018 at 06:26:02PM +, Andrew Cooper wrote:
> >> On 18/01/18 18:16, Wei Liu wrote:
> >>> To avoid having it changed every time the shim is built.
> >>>
> >>> Signed-off-by: Wei
On Thu, Jan 18, 2018 at 06:16:45PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
I would add to the commit message: "No functional change.", but I guess
it's already clear from the subject.
Roger.
___
Xen-devel mailing
>>> On 19.01.18 at 11:10, wrote:
> On 18/01/18 18:16, Wei Liu wrote:
>> Modify early boot code to relocate pvh info as well, so that we can be
>> sure __va in __start_xen works.
>>
>> Signed-off-by: Wei Liu
>
> :(
>
> It was a fear of code like this which caused me to go with the gross
> hack i
On Thu, Jan 18, 2018 at 06:16:46PM +, Wei Liu wrote:
> Remove extraneous semicolon. Add blank lines.
>
> Signed-off-by: Wei Liu
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/include/asm-x86/guest/xen.h | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff
On Thu, Jan 18, 2018 at 06:16:47PM +, Wei Liu wrote:
> We use the default scheduler (credit1 as of writing). The NULL
> scheduler still has bugs to fix.
>
> Signed-off-by: Wei Liu
This is AFAICT missing the change to shim.config, because the shim in
staging is still being built with:
CONFIG
Hi Roger/Vikram/Stefano,
On 07/08/2017 01:04 PM, Roger Pau Monné wrote:
On Fri, Jul 07, 2017 at 02:50:01PM -0700, Stefano Stabellini wrote:
On Fri, 7 Jul 2017, Roger Pau Monné wrote:
On Thu, Jul 06, 2017 at 03:55:28PM -0500, Vikram Sethi wrote:
AER: Will PCIe non-fatal and fatal errors (seco
>>> On 18.01.18 at 16:46, wrote:
> For guest safety, we treat STIBP as special, always override the toolstack
> choice, and always advertise STIBP if IBRS is available. This removes the
> corner case where STIBP is not advertised, but the guest is running on
> HT-capable hardware where it does ma
On 18/01/18 15:46, Andrew Cooper wrote:
> We need to be able to either set or clear IBRS in Xen context, as well as
> restore appropriate guest values in guest context. See the documentation in
> asm-x86/spec_ctrl_asm.h for details.
>
> Writes to %cr3 are slower when SPEC_CTRL.IBRS is set, so the
>>> On 18.01.18 at 16:46, wrote:
> @@ -153,14 +168,44 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t
> val)
> {
> const struct vcpu *curr = current;
> struct domain *d = v->domain;
> +const struct cpuid_policy *cp = d->arch.cpuid;
> struct msr_domain_policy *dp = d-
>>> On 18.01.18 at 16:46, wrote:
> @@ -292,6 +301,16 @@ static int update_domain_cpuid_info(struct domain *d,
> d->arch.pv_domain.cpuidmasks->e1cd = mask;
> }
> break;
> +
> +case 0x8008:
> +/*
> + * If the IBRB policy has changed, we need to
On 19/01/18 10:40, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> For guest safety, we treat STIBP as special, always override the toolstack
>> choice, and always advertise STIBP if IBRS is available. This removes the
>> corner case where STIBP is not advertised, but the guest is running
On 19/01/18 10:52, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> @@ -292,6 +301,16 @@ static int update_domain_cpuid_info(struct domain *d,
>> d->arch.pv_domain.cpuidmasks->e1cd = mask;
>> }
>> break;
>> +
>> +case 0x8008:
>> +/*
>> +
On Thu, Jan 18, 2018 at 06:16:48PM +, Wei Liu wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 0f652cea11..2f94c286d5 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -414,6 +414,7 @@ __pvh_start:
>
> /* Set trampoline_phy
On Thu, Jan 18, 2018 at 06:16:50PM +, Wei Liu wrote:
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
I would even make them DEBUG in fact. Feel free to keep the RB if you
turn them into DEBUG.
Thanks, Roger.
___
Xen-devel mailing list
Xen-
On Thu, Jan 18, 2018 at 06:16:51PM +, Wei Liu wrote:
> According to [0], some program sends NUL for padding purpose. We can
> discard them.
>
> https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap.html#SEC7
>
> Reported-by: Sarah Newman
> Signed-off-by: Wei Liu
Revie
On 19/01/18 10:45, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> @@ -153,14 +168,44 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t
>> val)
>> {
>> const struct vcpu *curr = current;
>> struct domain *d = v->domain;
>> +const struct cpuid_policy *cp = d->arch.cp
On Thu, Jan 18, 2018 at 06:16:52PM +, Wei Liu wrote:
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 558318e852..189ffac9b1 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -45,6 +45,7 @@
>
> #ifdef CONFIG_X86
> #include
> +#include
> #endif
>
> /*
On Fri, Jan 19, 2018 at 10:28:04AM +, Roger Pau Monné wrote:
> On Thu, Jan 18, 2018 at 06:16:47PM +, Wei Liu wrote:
> > We use the default scheduler (credit1 as of writing). The NULL
> > scheduler still has bugs to fix.
> >
> > Signed-off-by: Wei Liu
>
> This is AFAICT missing the change
>>> On 18.01.18 at 16:46, wrote:
> We need to be able to either set or clear IBRS in Xen context, as well as
> restore appropriate guest values in guest context. See the documentation in
> asm-x86/spec_ctrl_asm.h for details.
>
> Writes to %cr3 are slower when SPEC_CTRL.IBRS is set, so the
> SPE
>>> On 19.01.18 at 11:53, wrote:
> On Thu, Jan 18, 2018 at 06:16:48PM +, Wei Liu wrote:
>> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
>> index 0f652cea11..2f94c286d5 100644
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -414,6 +414,7 @@ __pvh_st
On 19/01/18 11:46, Jan Beulich wrote:
On 19.01.18 at 11:53, wrote:
>> On 19/01/18 10:40, Jan Beulich wrote:
>> On 18.01.18 at 16:46, wrote:
For guest safety, we treat STIBP as special, always override the toolstack
choice, and always advertise STIBP if IBRS is available. This
On 19/01/18 06:05, Manish Jaggi wrote:
On 01/17/2018 12:01 AM, Julien Grall wrote:
Hi Manish,
Hi Julien,
Thanks for reviewing the patch.
I sent the previous e-mail too soon.
On 02/01/18 09:27, manish.ja...@linaro.org wrote:
From: Manish Jaggi
Public API to populate and query map bet
>>> On 18.01.18 at 16:46, wrote:
> @@ -124,7 +186,21 @@ void __init init_speculation_mitigations(void)
> */
> if ( cpu_has_lfence_dispatch )
> thunk = THUNK_LFENCE;
> +/*
> + * On Intel hardware, we'd like to use retpoline in pref
>>> On 19.01.18 at 13:01, wrote:
> On 19/01/18 11:46, Jan Beulich wrote:
> On 19.01.18 at 11:53, wrote:
>>> On 19/01/18 10:40, Jan Beulich wrote:
>>> On 18.01.18 at 16:46, wrote:
> For guest safety, we treat STIBP as special, always override the toolstack
> choice, and always adv
On Fri, Jan 19, 2018 at 10:21:46AM +, Roger Pau Monné wrote:
> On Thu, Jan 18, 2018 at 06:16:46PM +, Wei Liu wrote:
> > Remove extraneous semicolon. Add blank lines.
> >
> > Signed-off-by: Wei Liu
> > ---
> > Cc: Jan Beulich
> > Cc: Andrew Cooper
> > ---
> > xen/include/asm-x86/guest/x
On Fri, Jan 19, 2018 at 12:22:48PM +, Wei Liu wrote:
> On Fri, Jan 19, 2018 at 10:21:46AM +, Roger Pau Monné wrote:
> > On Thu, Jan 18, 2018 at 06:16:46PM +, Wei Liu wrote:
> > > Remove extraneous semicolon. Add blank lines.
> > >
> > > Signed-off-by: Wei Liu
> > > ---
> > > Cc: Jan B
>>> On 19.01.18 at 11:53, wrote:
> On 19/01/18 10:40, Jan Beulich wrote:
> On 18.01.18 at 16:46, wrote:
>>> For guest safety, we treat STIBP as special, always override the toolstack
>>> choice, and always advertise STIBP if IBRS is available. This removes the
>>> corner case where STIBP is
On Fri, Jan 19, 2018 at 12:29:17PM +, Roger Pau Monné wrote:
> On Fri, Jan 19, 2018 at 12:22:48PM +, Wei Liu wrote:
> > On Fri, Jan 19, 2018 at 10:21:46AM +, Roger Pau Monné wrote:
> > > On Thu, Jan 18, 2018 at 06:16:46PM +, Wei Liu wrote:
> > > > Remove extraneous semicolon. Add bl
On 19/01/18 12:11, Jan Beulich wrote:
On 19.01.18 at 13:01, wrote:
>> On 19/01/18 11:46, Jan Beulich wrote:
>> On 19.01.18 at 11:53, wrote:
On 19/01/18 10:40, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> For guest safety, we treat STIBP as special, always overrid
>>> On 19.01.18 at 13:36, wrote:
> On 19/01/18 12:11, Jan Beulich wrote:
> On 19.01.18 at 13:01, wrote:
>>> On 19/01/18 11:46, Jan Beulich wrote:
>>> On 19.01.18 at 11:53, wrote:
> On 19/01/18 10:40, Jan Beulich wrote:
> On 18.01.18 at 16:46, wrote:
>>> For guest safety,
>>> On 18.01.18 at 16:46, wrote:
> @@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can be
> used to force or
> prevent Xen using the feature itself. If Xen is not using IBRS itself,
> functionality is still set up so IBRS can be virtualised for guests.
>
> +The `rsb_vmex
On 19/01/18 12:52, Jan Beulich wrote:
On 19.01.18 at 13:36, wrote:
>> On 19/01/18 12:11, Jan Beulich wrote:
>> On 19.01.18 at 13:01, wrote:
On 19/01/18 11:46, Jan Beulich wrote:
On 19.01.18 at 11:53, wrote:
>> On 19/01/18 10:40, Jan Beulich wrote:
>> On 18.01.1
flight 118175 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118175/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 118226 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118226/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 118219
Tests which
On 19/01/18 11:43, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> We need to be able to either set or clear IBRS in Xen context, as well as
>> restore appropriate guest values in guest context. See the documentation in
>> asm-x86/spec_ctrl_asm.h for details.
>>
>> Writes to %cr3 are slow
>>> On 19.01.18 at 14:35, wrote:
> flight 118226 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/118226/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64 6 xen-build
>>> On 18.01.18 at 16:46, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1743,6 +1743,29 @@ void context_switch(struct vcpu *prev, struct vcpu
> *next)
> }
>
> ctxt_switch_levelling(next);
> +
> +if ( opt_ibpb )
> +{
> +sta
On 19/01/18 12:06, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> @@ -124,7 +186,21 @@ void __init init_speculation_mitigations(void)
>> */
>> if ( cpu_has_lfence_dispatch )
>> thunk = THUNK_LFENCE;
>> +/*
>> + * On Intel
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 January 2018 13:44
> To: Paul Durrant
> Cc: xen-devel ; osstest service owner
>
> Subject: Re: [Xen-devel] [xen-unstable-smoke test] 118226: regressions -
> FAIL
>
> >>> On 19.01.18 at 14:35, wrote:
> > fligh
>>> On 19.01.18 at 14:36, wrote:
> On 19/01/18 11:43, Jan Beulich wrote:
> On 18.01.18 at 16:46, wrote:
>>> @@ -729,6 +760,9 @@ ENTRY(nmi)
>>> handle_ist_exception:
>>> SAVE_ALL CLAC
>>>
>>> +SPEC_CTRL_ENTRY_FROM_INTR /* Req: %rsp=regs, Clob: acd */
>>> +/* WARNING
>>> On 19.01.18 at 14:06, wrote:
> On 19/01/18 12:52, Jan Beulich wrote:
> On 19.01.18 at 13:36, wrote:
>>> On 19/01/18 12:11, Jan Beulich wrote:
>>> On 19.01.18 at 13:01, wrote:
> On 19/01/18 11:46, Jan Beulich wrote:
> On 19.01.18 at 11:53, wrote:
>>> On 19/01/18 10:40
>>> On 18.01.18 at 16:46, wrote:
> +/* Calculate whether Retpoline is known-safe on this CPU. */
> +static bool __init retpoline_safe(void)
> +{
> +unsigned int ucode_rev = this_cpu(ucode_cpu_info).cpu_sig.rev;
> +
> +if ( boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
> +return true
The recent commit 66bf4ef0 "x86/hvm: re-work viridian APIC assist code"
modified one of the field names in struct hvm_viridian_vcpu_context but
did not accordingly modify xen-hvmctx, leading to a failure to build tools.
This patch makes the necessary change to fix the build.
Signed-off-by: Paul D
On Fri, Jan 19, 2018 at 09:08:14AM -0500, Paul Durrant wrote:
> The recent commit 66bf4ef0 "x86/hvm: re-work viridian APIC assist code"
> modified one of the field names in struct hvm_viridian_vcpu_context but
> did not accordingly modify xen-hvmctx, leading to a failure to build tools.
>
> This p
flight 118174 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118174/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118096
test-armhf-armhf-libvirt 14 save
On Fri, Dec 15, 2017 at 03:45:06PM +, Julien Grall wrote:
>
>
> On 12/12/17 15:15, Julien Grall wrote:
> > Hi Wei/Ian,
>
> Hi,
>
> > I have tried this series on Arm64 hardware. I am able to boot and
> > install Debian on AMD Seattle (laxton{0,1}). But I don't get network
> > when using Cavi
On 19/01/18 12:47, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> @@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can be
>> used to force or
>> prevent Xen using the feature itself. If Xen is not using IBRS itself,
>> functionality is still set up so IBRS can be v
All,
along the lines of the relatively easy first step submitted yesterday,
I've had some further thoughts in that direction. A fundamental
thing for this is of course to first of all establish what kind of
information we consider safe to expose (in the long run) to guests.
The current state of t
On 19/01/18 13:25, Jan Beulich wrote:
On 18.01.18 at 16:46, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -1743,6 +1743,29 @@ void context_switch(struct vcpu *prev, struct vcpu
>> *next)
>> }
>>
>> ctxt_switch_levelling(next);
>> +
>> +
>>> On 19.01.18 at 15:24, wrote:
> On 19/01/18 12:47, Jan Beulich wrote:
> On 18.01.18 at 16:46, wrote:
>>> @@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can be
>>> used to force or
>>> prevent Xen using the feature itself. If Xen is not using IBRS itself,
>>> funct
On 19/01/18 13:33, Jan Beulich wrote:
On 19.01.18 at 14:06, wrote:
>> On 19/01/18 12:52, Jan Beulich wrote:
>> On 19.01.18 at 13:36, wrote:
On 19/01/18 12:11, Jan Beulich wrote:
On 19.01.18 at 13:01, wrote:
>> On 19/01/18 11:46, Jan Beulich wrote:
>> On 19.01.1
>>> On 19.01.18 at 15:48, wrote:
> On 19/01/18 13:25, Jan Beulich wrote:
> On 18.01.18 at 16:46, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -1743,6 +1743,29 @@ void context_switch(struct vcpu *prev, struct vcpu
>>> *next)
>>> }
>>>
>>> c
>>> On 10.01.18 at 14:05, wrote:
> Otherwise, due to Xen code/data changes under CPU feet, Xen may crash
> silently at boot.
>
> We were hit by the issue in OVS Xen 4.4 with my earlier version of
> EFI/Multiboot2 patches. Initially its implementation allowed relocation
> of Xen even if it was rel
On Fri, Jan 19, 2018 at 11:18:38AM +, Roger Pau Monné wrote:
> On Thu, Jan 18, 2018 at 06:16:52PM +, Wei Liu wrote:
> > diff --git a/xen/common/domain.c b/xen/common/domain.c
> > index 558318e852..189ffac9b1 100644
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -45,6 +45
On Fri, Jan 19, 2018 at 11:03:02AM +, Roger Pau Monné wrote:
> On Thu, Jan 18, 2018 at 06:16:51PM +, Wei Liu wrote:
> > According to [0], some program sends NUL for padding purpose. We can
> > discard them.
> >
> > https://www.gnu.org/software/termutils/manual/termcap-1.3/html_mono/termcap
>>> On 10.01.18 at 14:05, wrote:
> Current limit, PFN_DOWN(xen_phys_start), introduced by commit b280442
> (x86: make Xen early boot code relocatable) is not reliable. Potentially
> its value may fall below PFN_DOWN(__pa(_end)) and then part of Xen image
> may not be mapped after relocation. This
>>> On 19.01.18 at 16:00, wrote:
> I'm afraid that despite all of this, I don't see an valid argument
> against the logic as implemented in the patch, and I don't see any
> viable option to working around the edge case you are concerned about,
> which is very definitely a microcode bug.
Well, oka
Wei Liu (7):
Update shim.config
libxl: remove whitespaces introduced in 62982da926
x86/guest: clean up guest/xen.h
x86/shim: use credit scheduler
x86: relocate pvh_info
Revert "x86/boot: Map more than the first 16MB"
libxl: lower shim related message to level DEBUG
docs/man/xl.cfg.p
Remove extraneous semicolon. Add blank lines. Remove unused static
inline functions.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Roger Pau Monné
---
xen/include/asm-x86/guest/xen.h | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/xen/in
No functional change.
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
---
tools/libxl/libxl_dom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index b03386409f..e1a3e747fc 100644
--- a/tools/libxl/libxl_dom.c
+++ b
Kconfig has
bool "VGA support" if !PV_SHIM_EXCLUSIVE
so for the shim build VGA option doesn't exist.
This avoids having shim.config changed every time the shim is built.
Signed-off-by: Wei Liu
Reviewed-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
---
tools/firmware/xen-dir/shim.config |
Remove sched=null from shim cmdline and doc
We use the default scheduler (credit1 as of writing). The NULL
scheduler still has bugs to fix.
Update shim.config.
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Andrew Cooper
---
docs/man/xl.cfg.pod.5.in | 2 +-
tools/f
This reverts commit 7d6f958d9d18c54017f5ef6e299a08037f035747.
Now we have PVH info relocation support, this change is no longer
needed.
Signed-off-by: Wei Liu
Acked-by: Jan Beulich
---
xen/arch/x86/boot/x86_64.S | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86
Modify early boot code to relocate pvh info as well, so that we can be
sure __va in __start_xen works.
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Roger Pau Monné
v2: use XEN_HVM_START_MAGIC_VALUE and switch statement in reloc.
Move header inclusion.
---
xen/arch/x86/boo
Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
---
tools/libxl/libxl_dom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index e1a3e747fc..29fd2f5d6a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.
On 01/19/2018 02:37 PM, Jan Beulich wrote:
> All,
>
> along the lines of the relatively easy first step submitted yesterday,
> I've had some further thoughts in that direction. A fundamental
> thing for this is of course to first of all establish what kind of
> information we consider safe to expo
Thanks for the review, and sorry for the very late reply.
On Fri, Dec 15, 2017 at 04:43:11AM -0700, Jan Beulich wrote:
> >>> On 18.10.17 at 13:40, wrote:
> > +static void modify_decoding(const struct pci_dev *pdev, bool map, bool rom)
> > +{
> > +struct vpci_header *header = &pdev->vpci->head
On Fri, Jan 19, 2018 at 03:34:54PM +, Wei Liu wrote:
> Remove extraneous semicolon. Add blank lines. Remove unused static
> inline functions.
>
> Signed-off-by: Wei Liu
Reviewed-by: Roger Pau Monné
Thanks, Roger.
___
Xen-devel mailing list
Xen-d
1: x86: move invocations of hvm_flush_guest_tlbs()
2: x86: make CPU state flush requests explicit
3: add check to cpumask_of()
4: replace vCPU's dirty CPU mask by numeric ID
5: x86: avoid explicit TLB flush when saving exec state
6: drop "domain_" prefix from struct domain's dirty CPU mask
Signed-
flight 118229 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118229/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 118219
Tests which
Having this be an implied side effect of a TLB flush is not very nice:
It could (at least in theory) lead to unintended state flushes (see e.g.
https://lists.xenproject.org/archives/html/xen-devel/2017-11/msg00187.html
for context). Introduce a flag to be used in the two places actually
wanting th
Just like any other function's CPU inputs, the one here shouldn't go
unchecked.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/cpumask.h
+++ b/xen/include/xen/cpumask.h
@@ -304,7 +304,9 @@ extern const unsigned long
static inline const cpumask_t *cpumask_of(unsigned int cpu)
{
- cons
Now that it's obvious that only a single dirty CPU can exist for a vCPU,
it becomes clear that flush_mask() doesn't need to be invoked when
sync_local_execstate() was already run. And with the IPI handler
clearing FLUSH_TLB from the passed flags anyway if
__sync_local_execstate() returns true, it a
It being a field of struct domain is sufficient to recognize its
purpose.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -470,7 +470,7 @@ void startup_cpu_idle_loop(void)
ASSERT(is_idle_vcpu(v));
/* TODO
- cpumask_set_cpu(v->processor, v->
On 12/20/2017 09:34 AM, Jan Beulich wrote:
> p2m_pod_decrease_reservation() at the moment only returns a boolean
> value: true for "nothing more to do", false for "something more to do".
> If it returns false, decrease_reservation() will loop over the entire
> range, calling guest_remove_page() for
>>> On 19.01.18 at 16:47, wrote:
> On Fri, Dec 15, 2017 at 04:43:11AM -0700, Jan Beulich wrote:
>> >>> On 18.10.17 at 13:40, wrote:
>> > +static void modify_decoding(const struct pci_dev *pdev, bool map, bool
>> > rom)
>> > +{
>> > +struct vpci_header *header = &pdev->vpci->header;
>> > +
>>> On 19.01.18 at 16:34, wrote:
> Remove extraneous semicolon. Add blank lines. Remove unused static
> inline functions.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenp
flight 118186 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118186/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-examine 6 xen-install fail in 118149 pass in 118186
test-armhf-armhf-libvirt-xsm 6 xe
On 19/01/18 15:02, Jan Beulich wrote:
On 19.01.18 at 15:24, wrote:
>> On 19/01/18 12:47, Jan Beulich wrote:
>> On 18.01.18 at 16:46, wrote:
@@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can
be
used to force or
prevent Xen using the feature it
On Fri, Jan 19, 2018 at 09:07:21AM -0700, Jan Beulich wrote:
> It being a field of struct domain is sufficient to recognize its
> purpose.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
h
On Fri, Jan 19, 2018 at 2:12 AM, Jan Beulich wrote:
On 04.01.18 at 21:33, wrote:
>> @@ -375,12 +385,52 @@ static void __init PrintErrMesg(const CHAR16 *mesg,
>> EFI_STATUS ErrCode)
>>
>> static unsigned int __init get_argv(unsigned int argc, CHAR16 **argv,
>>
At most one bit can be set in the masks, so especially on larger systems
it's quite a bit of unnecessary memory and processing overhead to track
the information as a mask. Store the numeric ID of the respective CPU
instead, or NR_CPUS if no dirty state exists.
Signed-off-by: Jan Beulich
---
ARM a
On Fri, Jan 19, 2018 at 03:34:56PM +, Wei Liu wrote:
> diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
> index 48c7407c00..028ac19b96 100644
> --- a/xen/arch/x86/boot/build32.mk
> +++ b/xen/arch/x86/boot/build32.mk
> @@ -36,5 +36,8 @@ CFLAGS := $(filter-out -flto,$(CFLA
>>> On 19.01.18 at 17:04, wrote:
> On 12/20/2017 09:34 AM, Jan Beulich wrote:
>> p2m_pod_decrease_reservation() at the moment only returns a boolean
>> value: true for "nothing more to do", false for "something more to do".
>> If it returns false, decrease_reservation() will loop over the entire
>
The existing has_dynamic_sysbus flag makes the machine accept
every user-creatable sysbus device type on the command-line.
Replace it with a list of allowed device types, so machines can
easily accept some sysbus devices while rejecting others.
To keep exactly the same behavior as before, the exis
There's no need to make the machine allow every possible sysbus
device. We can now just add xen-sysdev to the allowed list.
Cc: Stefano Stabellini
Cc: Anthony Perard
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross
Signed-off-by: Eduardo Habkost
Message-Id: <20171125151610.20547-6-ehabk..
>>> On 19.01.18 at 17:10, wrote:
> On 19/01/18 15:02, Jan Beulich wrote:
> On 19.01.18 at 15:24, wrote:
>>> On 19/01/18 12:47, Jan Beulich wrote:
>>> On 18.01.18 at 16:46, wrote:
> @@ -265,6 +265,10 @@ On hardware supporting IBRS, the `ibrs=` option can
> be
> used to force
On Fri, Jan 19, 2018 at 04:29:31PM +, Roger Pau Monné wrote:
> On Fri, Jan 19, 2018 at 03:34:56PM +, Wei Liu wrote:
> > diff --git a/xen/arch/x86/boot/build32.mk b/xen/arch/x86/boot/build32.mk
> > index 48c7407c00..028ac19b96 100644
> > --- a/xen/arch/x86/boot/build32.mk
> > +++ b/xen/arch/
>>> On 19.01.18 at 17:25, wrote:
> On Fri, Jan 19, 2018 at 2:12 AM, Jan Beulich wrote:
>> And then - how about a different heuristic altogether: Current
>> code scans the pointed to memory for a nul character, being
>> happy if it is found before having exhausted cmdsize.
>
> I'm not sure what y
Their need is not tied to the actual flushing of TLBs, but the ticking
of the TLB clock. Make this more obvious by folding the two invocations
into a single one in pre_flush().
Also defer the latching of CR4 in write_cr3() until after pre_flush()
(and hence implicitly until after IRQs are off), ma
1 - 100 of 136 matches
Mail list logo
