Cortex-A17 and A12 MIDR will be used in a follow-up patch for hardening
the branch predictor.
This is part of XSA-254.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/processor.h | 4
1 file changed, 4 insertions(+)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/pr
flight 118216 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118216/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 118159
Tests which did not succee
flight 118215 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118215/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 6 xen-buildfail REGR. vs. 118112
Tests which did not
flight 118204 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118204/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 117765
test-amd64-amd64-xl-qemut-win7-amd64 17
flight 118235 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118235/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Jan,
On Fri, Jan 19, 2018 at 02:52:50AM -0700, Jan Beulich wrote:
> >>> 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
flight 118200 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118200/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 118137
test-armhf-armhf-libvirt 14 saveresto
c/s 4ddf474e2 "tools/xen-mceinj: Pass in GPA when injecting through
MSR_MCI_ADDR" removed the remaining user of hypercall.
It has been listed as broken, deprecated and wont-fix since XSA-74, so take
this opportunity to remove it completely.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: I
It is unused, and uses an obsolete hypercall which has never ever functioned
for HVM guests.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Christian Lindig
---
tools/ocaml/libs/xc/xenctrl.ml | 86 -
tools/ocaml/libs/xc/xenctrl.mli
On Fri, Jan 19, 2018 at 4:02 PM, Jan Beulich wrote:
> 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().
So now pre_flush() actually does the flush?
I don't object to
On Fri, Jan 19, 2018 at 03:34:55PM +, Wei Liu wrote:
> 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
Reviewed-by: Roger Pau Monné
> ---
>
Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install:
don't use the new nic naming scheme"):
> It is rather different. It is a hack put in by IanC to deal with
> unreliable USB nic. IIRC the rule invokes ip to set the mac address.
Yikes.
Ian.
___
On 19/01/18 16:03, Jan Beulich wrote:
> --- a/xen/include/asm-x86/flushtlb.h
> +++ b/xen/include/asm-x86/flushtlb.h
> @@ -101,6 +101,8 @@ void write_cr3(unsigned long cr3);
> #define FLUSH_CACHE 0x400
> /* VA for the flush has a valid mapping */
> #define FLUSH_VA_VALID 0x800
> + /* Flus
On 19/01/18 16:06, Jan Beulich wrote:
> 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
On 19/01/18 16:06, Jan Beulich wrote:
> 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
Hi all,
This series provides a skeleton for mitigating branch predictor hardening for
arm32 on exception entry.
It also implements mitigation for Cortex-A12, A15 and A17. SoC vendors with
affected CPUs are strongly encouraged to update.
For more information about the impact of this issue and the
On 19/01/18 16:07, Jan Beulich wrote:
> It being a field of struct domain is sufficient to recognize its
> purpose.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although...
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3327,7 +3327,7 @@ long do_mmuext_op(
>
On 01/19/2018 04:07 PM, Jan Beulich wrote:
> It being a field of struct domain is sufficient to recognize its
> purpose.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists
On Fri, Jan 19, 2018 at 09:16:54AM -0700, Jan Beulich wrote:
> >>> 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)
> >> >
On Fri, Jan 19, 2018 at 4:06 PM, Jan Beulich wrote:
> 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 pass
On 19/01/18 16:04, Jan Beulich wrote:
> 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
On Fri, Jan 19, 2018 at 05:56:15PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install:
> don't use the new nic naming scheme"):
> > On Fri, Jan 19, 2018 at 05:08:09PM +, Ian Jackson wrote:
> > > 1. persistent-net.rules contains information say
Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install:
don't use the new nic naming scheme"):
> On Fri, Jan 19, 2018 at 05:08:09PM +, Ian Jackson wrote:
> > 1. persistent-net.rules contains information saying "if nic with
> > address aa:bb:cc:dd:ee:ff shows up, call it eth2
flight 118231 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/118231/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 01/19/2018 04:06 PM, Jan Beulich wrote:
> 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 s
On 19/01/18 16:02, Jan Beulich wrote:
> 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()
> (a
On Fri, 19 Jan 2018, Jan Beulich wrote:
> >>> 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
> >
>>> On 19.01.18 at 16:43, wrote:
> 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
On Fri, Jan 19, 2018 at 05:08:09PM +, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install:
> don't use the new nic naming scheme"):
> > On Fri, Dec 15, 2017 at 03:45:06PM +, Julien Grall wrote:
> > > I dug a bit more, so 'force interface' will cre
On 12/20/2017 09:35 AM, Jan Beulich wrote:
> As XSAs 246 and 247 have shown, not doing so is rather dangerous.
>
> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
> Reviewed-by: Kevin Tian
>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1550,9 +1550,11 @@ void p2m_mem_
Wei Liu writes ("Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install:
don't use the new nic naming scheme"):
> On Fri, Dec 15, 2017 at 03:45:06PM +, Julien Grall wrote:
> > I dug a bit more, so 'force interface' will create the
> > /etc/udev/rules.d/70-persistent-net.rules for the install
On 01/19/2018 04:36 PM, Jan Beulich wrote:
On 19.01.18 at 16:43, wrote:
>> 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
On Fri, Jan 19, 2018 at 09:04:33AM -0700, Jan Beulich wrote:
> Just like any other function's CPU inputs, the one here shouldn't go
> unchecked.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject
On 19/01/18 16:19, Jan Beulich wrote:
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
When EFI booting the Dell PowerEdge R740, it consistently wanders into the
weeds and gets an invalid opcode in the EFI ResetSystem call.
Quirk this hardware to use the ACPI reboot method instead.
Example stack trace:
[ Xen-4.11-unstable x86_64 debug=n Not tainted ]
CPU:0
RIP:e
On Fri, Jan 19, 2018 at 9:41 AM, Jan Beulich wrote:
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
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
>>> 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
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: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
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..
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
>>> 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
>
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
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 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,
>>
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 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
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 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
>>> 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 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
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->
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
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
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
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
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-
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
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 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
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.
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
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
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
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 |
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
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
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
>>> 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
>>> 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 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 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 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 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 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 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);
>> +
>> +
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 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
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
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, 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
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 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
>>> 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 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
> -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 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
>>> 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 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 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
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
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
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
>>> 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 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 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 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 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
1 - 100 of 136 matches
Mail list logo
