[Xen-devel] [PATCH 2/7] xen/arm32: Add missing MIDR values for Cortex-A17 and A12

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

[Xen-devel] [qemu-mainline test] 118216: tolerable FAIL - PUSHED

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

[Xen-devel] [linux-linus test] 118215: regressions - FAIL

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

[Xen-devel] [linux-4.9 test] 118204: tolerable FAIL - PUSHED

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

[Xen-devel] [xen-unstable-smoke test] 118235: tolerable all pass - PUSHED

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

Re: [Xen-devel] XPTI patches for 4.10 don't apply

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

[Xen-devel] [libvirt test] 118200: tolerable all pass - PUSHED

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

[Xen-devel] [PATCH 2/2] xen: Drop DOMCTL_getmemlist and xc_get_pfn_list()

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

[Xen-devel] [PATCH 1/2] tools/ocaml: Drop coredump infrastructure

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

Re: [Xen-devel] [PATCH 1/6] x86: move invocations of hvm_flush_guest_tlbs()

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

Re: [Xen-devel] [PATCH v2 4/7] x86/shim: use credit scheduler

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:

Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: don't use the new nic naming scheme

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.

Re: [Xen-devel] [PATCH 2/6] x86: make CPU state flush requests explicit

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 > + /*

Re: [Xen-devel] [PATCH 4/6] replace vCPU's dirty CPU mask by numeric ID

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

Re: [Xen-devel] [PATCH 5/6] x86: avoid explicit TLB flush when saving exec 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

[Xen-devel] [PATCH 0/7] xen/arm32: Branch predictor hardening (XSA-254 variant 2)

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

Re: [Xen-devel] [PATCH 6/6] drop "domain_" prefix from struct domain's dirty CPU mask

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 > @@

Re: [Xen-devel] [PATCH 6/6] drop "domain_" prefix from struct domain's dirty CPU mask

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

Re: [Xen-devel] [PATCH v7 for-next 09/12] vpci/bars: add handlers to map the BARs

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

Re: [Xen-devel] [PATCH 5/6] x86: avoid explicit TLB flush when saving exec state

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

Re: [Xen-devel] [PATCH 3/6] add check to cpumask_of()

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

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: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

Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: don't use the new nic naming scheme

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

[Xen-devel] [xen-unstable-smoke test] 118231: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH 4/6] replace vCPU's dirty CPU mask by numeric ID

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

Re: [Xen-devel] [PATCH 1/6] x86: move invocations of hvm_flush_guest_tlbs()

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() >

Re: [Xen-devel] XSA-254 SP2 for ARM (was Re: [PATCH 1/5] xen/arm: Introduce enable callback to enable a capabilities on each online CPU)

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

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

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

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: > 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

Re: [Xen-devel] [PATCH v2 2/2] x86/p2m: force return value checking of p2m_set_entry()

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

Re: [Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: don't use the new nic naming scheme

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

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

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

Re: [Xen-devel] [PATCH 3/6] add check to cpumask_of()

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] [PATCH] x86/shutdown: Use ACPI reboot method for Dell PowerEdge R740

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:

Re: [Xen-devel] [PATCHv2] xen: Add EFI_LOAD_OPTION support

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

[Xen-devel] [PATCH 1/6] x86: move invocations of hvm_flush_guest_tlbs()

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),

Re: [Xen-devel] [PATCHv2] xen: Add EFI_LOAD_OPTION support

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

Re: [Xen-devel] [PATCH v2 5/7] x86: relocate pvh_info

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 > > +++

Re: [Xen-devel] [PATCH v9 08/11] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

>>> 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 @@

[Xen-devel] [PULL v2 10/19] xen: Add only xen-sysdev to dynamic sysbus device list

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

[Xen-devel] [PULL v2 06/19] machine: Replace has_dynamic_sysbus with list of allowed devices

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

Re: [Xen-devel] [PATCH v2 1/2] x86/PoD: correctly handle non-order-0 decrease-reservation requests

>>> 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()

Re: [Xen-devel] [PATCH v2 5/7] x86: relocate pvh_info

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

Re: [Xen-devel] [PATCHv2] xen: Add EFI_LOAD_OPTION support

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

Re: [Xen-devel] [PATCH 6/6] drop "domain_" prefix from struct domain's dirty CPU mask

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

[Xen-devel] [linux-3.18 test] 118186: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH v7 for-next 09/12] vpci/bars: add handlers to map the BARs

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

Re: [Xen-devel] [PATCH v2 1/2] x86/PoD: correctly handle non-order-0 decrease-reservation requests

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()

[Xen-devel] [PATCH 6/6] drop "domain_" prefix from struct domain's dirty CPU mask

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 -

[Xen-devel] [PATCH 5/6] x86: avoid explicit TLB flush when saving exec state

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

[Xen-devel] [PATCH 3/6] add check to cpumask_of()

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

[Xen-devel] [PATCH 2/6] x86: make CPU state flush requests explicit

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

[Xen-devel] [xen-unstable-smoke test] 118229: regressions - FAIL

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

[Xen-devel] [PATCH 0/6] misc flush and dirty-mask related adjustments

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

Re: [Xen-devel] [PATCH v2 3/7] x86/guest: clean up guest/xen.h

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.

Re: [Xen-devel] [PATCH v7 for-next 09/12] vpci/bars: add handlers to map the BARs

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

Re: [Xen-devel] further post-Meltdown-bad-aid performance thoughts

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

[Xen-devel] [PATCH v2 7/7] libxl: lower shim related message to level DEBUG

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

[Xen-devel] [PATCH v2 5/7] x86: relocate pvh_info

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-devel] [PATCH v2 6/7] Revert "x86/boot: Map more than the first 16MB"

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(+),

[Xen-devel] [PATCH v2 4/7] x86/shim: use credit scheduler

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:

[Xen-devel] [PATCH v2 1/7] Update shim.config

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

[Xen-devel] [PATCH v2 2/7] libxl: remove whitespaces introduced in 62982da926

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

[Xen-devel] [PATCH v2 3/7] x86/guest: clean up guest/xen.h

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 |

[Xen-devel] [PATCH v2 0/7] Fixes and improvements to pvshim

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

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

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

Re: [Xen-devel] [PATCH v3 2/2] x86/setup: remap Xen image up to PFN_DOWN(__pa(_end))

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

Re: [Xen-devel] [PATCH 8/9] xen/consoled: discard NUL from guest

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. > > > >

Re: [Xen-devel] [PATCH 9/9] x86/shim: pass through vcpu runstate to L0 Xen

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

Re: [Xen-devel] [PATCH v3 1/2] x86/setup: do not relocate Xen over current Xen image placement

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

Re: [Xen-devel] [PATCH v9 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

>>> 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,

Re: [Xen-devel] [PATCH v9 08/11] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

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

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

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,

Re: [Xen-devel] [PATCH v9 09/11] x86/ctxt: Issue a speculation barrier between vcpu contexts

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) >> } >> >>

[Xen-devel] further post-Meltdown-bad-aid performance thoughts

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

Re: [Xen-devel] [PATCH v9 08/11] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

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

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: > > > 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

[Xen-devel] [xen-unstable test] 118174: tolerable FAIL - PUSHED

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

Re: [Xen-devel] [PATCH] tools/misc/xen-hvmctx: fix the build

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

[Xen-devel] [PATCH] tools/misc/xen-hvmctx: fix the build

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

Re: [Xen-devel] [PATCH v9 07/11] x86/boot: Calculate the most appropriate BTI mitigation to use

>>> 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 ==

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

>>> 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,

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

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

Re: [Xen-devel] [xen-unstable-smoke test] 118226: regressions - FAIL

> -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]

Re: [Xen-devel] [PATCH v9 07/11] x86/boot: Calculate the most appropriate BTI mitigation to use

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; >> +/*

Re: [Xen-devel] [xen-unstable-smoke test] 118226: regressions - FAIL

>>> 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: >

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

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.

[Xen-devel] [xen-unstable-smoke test] 118226: regressions - FAIL

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

[Xen-devel] [seabios test] 118175: regressions - FAIL

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

Re: [Xen-devel] [PATCH v9 08/11] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

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

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

>>> 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,

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

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,

Re: [Xen-devel] [PATCH 3/9] x86/guest: clean up guest/xen.h

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

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

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

Re: [Xen-devel] [PATCH 3/9] x86/guest: clean up guest/xen.h

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

Re: [Xen-devel] [PATCH 3/9] x86/guest: clean up guest/xen.h

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

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

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

Re: [Xen-devel] [PATCH v9 07/11] x86/boot: Calculate the most appropriate BTI mitigation to use

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

Re: [Xen-devel] [PATCH v9 02/11] x86/cpuid: Handling of IBRS/IBPB, STIBP and IBRS for guests

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,

Re: [Xen-devel] [PATCH v9 06/11] x86/entry: Organise the use of MSR_SPEC_CTRL at each entry/exit point

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

  1   2   >