[Xen-devel] [linux-next test] 122408: regressions - FAIL

flight 122408 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/122408/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 122395

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

flight 122457 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122457/ 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

[Xen-devel] [xen-unstable-smoke test] 122453: trouble: blocked/broken/pass

flight 122453 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122453/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf

Re: [Xen-devel] [PATCH] xen/kbdif: Add frontend's virtual device options

Hi Oleksandr, On Tue, Apr 24, 2018 at 10:31:38AM +0300, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > It is now not possible to control if and which virtual devices > are created by the frontend, e.g. keyboard and pointer devices > are

Re: [Xen-devel] [PATCH] Input: xen-kbdfront - allow better run-time configuration

On 04/26/2018 10:16 PM, Dmitry Torokhov wrote: On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote: On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: On 04/19/2018 02:25 PM, Juergen Gross wrote: On

Re: [Xen-devel] [PATCH] Input: xen-kbdfront - allow better run-time configuration

On Tue, Apr 24, 2018 at 08:55:19AM +0300, Oleksandr Andrushchenko wrote: > On 04/23/2018 09:53 PM, Dmitry Torokhov wrote: > > On Thu, Apr 19, 2018 at 02:44:19PM +0300, Oleksandr Andrushchenko wrote: > > > On 04/19/2018 02:25 PM, Juergen Gross wrote: > > > > On 18/04/18 17:04, Oleksandr

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

flight 122404 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/122404/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 122344 test-armhf-armhf-libvirt 14

Re: [Xen-devel] [PATCH] tools: prepend to PKG_CONFIG_PATH when configuring qemu

> From: Ian Jackson > Sent: Thursday, April 26, 2018 1:44 PM > Subject: Re: [PATCH] tools: prepend to PKG_CONFIG_PATH when > configuring qemu > > Stewart Hildebrand writes ("[PATCH] tools: prepend to PKG_CONFIG_PATH > when configuring qemu"): > > A user may choose to set his/her own

[Xen-devel] [RESEND PULL v9 00/16] xen: xen-domid-restrict improvements

The following changes since commit b8846a4d6352b2a1d2012f8b3b9115640524aeda: vl.c: new function serial_max_hds() (2018-04-26 13:58:29 +0100) are available in the git repository at: https://xenbits.xen.org/git-http/people/iwj/qemu.git tags/for-upstream.depriv-2 for you to fetch changes up

Re: [Xen-devel] [PULL v9 00/16] xen: xen-domid-restrict improvements

Peter Maydell writes ("Re: [PULL v9 00/16] xen: xen-domid-restrict improvements"): > On 26 April 2018 at 18:36, Ian Jackson wrote: > > I can do that. Alternatively you could manually verify the signature > > on my email and observe that it mentions the correct commit

Re: [Xen-devel] [PATCH] tools: prepend to PKG_CONFIG_PATH when configuring qemu

Stewart Hildebrand writes ("[PATCH] tools: prepend to PKG_CONFIG_PATH when configuring qemu"): > A user may choose to set his/her own PKG_CONFIG_PATH, which is useful in the > case of cross-compiling. We don't want to completely override the > PKG_CONFIG_PATH, just add to it. Acked-by: Ian

Re: [Xen-devel] [PULL v9 00/16] xen: xen-domid-restrict improvements

On 26 April 2018 at 18:36, Ian Jackson wrote: > Peter Maydell writes ("Re: [PULL v9 00/16] xen: xen-domid-restrict > improvements"): >> Hi -- my apply-pullreq script thinks this isn't a signed tag: >> >> error: remotes/iwj/for-upstream.depriv-2: cannot verify a non-tag

[Xen-devel] [PATCH] tools: prepend to PKG_CONFIG_PATH when configuring qemu

A user may choose to set his/her own PKG_CONFIG_PATH, which is useful in the case of cross-compiling. We don't want to completely override the PKG_CONFIG_PATH, just add to it. Signed-off-by: Stewart Hildebrand --- tools/Makefile | 2 +- 1 file changed, 1

Re: [Xen-devel] [PULL v9 00/16] xen: xen-domid-restrict improvements

Peter Maydell writes ("Re: [PULL v9 00/16] xen: xen-domid-restrict improvements"): > Hi -- my apply-pullreq script thinks this isn't a signed tag: > > error: remotes/iwj/for-upstream.depriv-2: cannot verify a non-tag object of > type commit. Does not appear to be a signed tag It isn't. It's

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 04/26/2018 11:55 AM, Jan Beulich wrote: On 26.04.18 at 17:20, wrote: >> On 04/26/2018 09:33 AM, Jan Beulich wrote: > -static void svm_sync_vmcb(struct vcpu *v) > +static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) > { >

Re: [Xen-devel] [PULL v9 00/16] xen: xen-domid-restrict improvements

On 26 April 2018 at 16:56, Ian Jackson wrote: > From: Ian Jackson > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The following changes since commit b8846a4d6352b2a1d2012f8b3b9115640524aeda: > > vl.c: new function serial_max_hds()

Re: [Xen-devel] [PATCH 5/7] doc: correct livepatch.markdown syntax

On 26/04/18 17:12, Konrad Rzeszutek Wilk wrote: > On Tue, Apr 24, 2018 at 08:44:57AM +0200, Juergen Gross wrote: >> "make -C docs all" fails due to incorrect markdown syntax in >> livepatch.markdown. Correct it. >> >> Signed-off-by: Juergen Gross >> --- >>

Re: [Xen-devel] [PATCH 2/7] doc: add architecture qualifier to boot parameter entries

On 26/04/18 17:00, Jan Beulich wrote: On 24.04.18 at 08:44, wrote: >> Many of the architecture specific boot parameters are not qualified >> as such. Correct that. > > I think we want to distinguish between ones really only be meaningful for > some architecture vs ones

[Xen-devel] [PULL 08/16] xen: destroy_hvm_domain: Try xendevicemodel_shutdown

xc_interface_open etc. is not going to work if we have dropped privilege, but xendevicemodel_shutdown will if everything is new enough. xendevicemodel_shutdown is only availabe in Xen 4.10 and later, so provide a stub for earlier versions. Signed-off-by: Ian Jackson

[Xen-devel] [PULL 04/16] xen: restrict: use xentoolcore_restrict_all

And insist that it works. Drop individual use of xendevicemodel_restrict and xenforeignmemory_restrict. These are not actually effective in this version of qemu, because qemu has a large number of fds open onto various Xen control devices. The restriction arrangements are still not right,

[Xen-devel] [PULL 14/16] os-posix: cleanup: Replace fprintf with error_report in remaining call sites

Signed-off-by: Ian Jackson CC: Paolo Bonzini CC: Markus Armbruster CC: Daniel P. Berrange CC: Michael Tokarev Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Thomas Huth

[Xen-devel] [PULL 02/16] AccelClass: Introduce accel_setup_post

This is called just before os_setup_post. Currently none of the accelerators provide this hook, but the Xen one is going to provide one in a moment. Signed-off-by: Ian Jackson Reviewed-by: Eduardo Habkost --- accel/accel.c | 9 +

[Xen-devel] [PULL 11/16] xen: Use newly added dmops for mapping VGA memory

From: Ross Lagerwall Xen unstable (to be in 4.11) has two new dmops, relocate_memory and pin_memory_cacheattr. Use these to set up the VGA memory, replacing the previous calls to libxc. This allows the VGA console to work properly when QEMU is running restricted

[Xen-devel] [PULL 07/16] xen: move xc_interface compatibility fallback further up the file

We are going to want to use the dummy xendevicemodel_handle type in new stub functions in the CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000 section. So we need to provide that definition, or (as applicable) include the appropriate header, earlier in the file. (Ideally the newer compatibility layers

[Xen-devel] [PULL 10/16] os-posix: Provide new -runas : facility

This allows the caller to specify a uid and gid to use, even if there is no corresponding password entry. This will be useful in certain Xen configurations. We don't support just -runas because: (i) deprivileging without calling setgroups would be ineffective (ii) given only a uid we don't know

[Xen-devel] [PULL 16/16] configure: do_compiler: Dump some extra info under bash

This makes it much easier to find a particular thing in config.log. We have to use the ${BASH_LINENO[*]} syntax which is a syntax error in other shells, so test what shell we are running and use eval. The extra output is only printed if configure is run with bash. On systems where /bin/sh is

[Xen-devel] [PULL 05/16] xen: defer call to xen_restrict until just before os_setup_post

We need to restrict *all* the control fds that qemu opens. Looking in /proc/PID/fd shows there are many; their allocation seems scattered throughout Xen support code in qemu. We must postpone the restrict call until roughly the same time as qemu changes its uid, chroots (if applicable), and so

[Xen-devel] [PULL 01/16] checkpatch: Add xendevicemodel_handle to the list of types

This avoids checkpatch misparsing (as statements) long function definitions or declarations, which sometimes start with constructs like this: static inline int xendevicemodel_relocate_memory( xendevicemodel_handle *dmod, domid_t domid, ... The type xendevicemodel_handle does not conform

[Xen-devel] [PULL v9 00/16] xen: xen-domid-restrict improvements

From: Ian Jackson -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The following changes since commit b8846a4d6352b2a1d2012f8b3b9115640524aeda: vl.c: new function serial_max_hds() (2018-04-26 13:58:29 +0100) are available in the git repository at:

[Xen-devel] [PULL 09/16] os-posix: cleanup: Replace fprintfs with error_report in change_process_uid

I'm going to be editing this function and it makes sense to clean up this style problem in advance. Signed-off-by: Ian Jackson CC: Paolo Bonzini CC: Markus Armbruster CC: Daniel P. Berrange CC: Michael

[Xen-devel] [PULL 12/16] xen: Remove now-obsolete xen_xc_domain_add_to_physmap

The last user was just removed; remove this function, accordingly. Signed-off-by: Ian Jackson Acked-by: Anthony PERARD --- include/hw/xen/xen_common.h | 22 -- 1 file changed, 22 deletions(-) diff --git

[Xen-devel] [PULL 06/16] xen: destroy_hvm_domain: Move reason into a variable

We are going to want to reuse this. No functional change. Signed-off-by: Ian Jackson Reviewed-by: Anthony PERARD Acked-by: Stefano Stabellini --- hw/i386/xen/xen-hvm.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[Xen-devel] [PULL 13/16] xen: Expect xenstore write to fail when restricted

From: Ross Lagerwall Saving the current state to xenstore may fail when running restricted (in particular, after a migration). Therefore, don't report the error or exit when running restricted. Toolstacks that want to allow running QEMU restricted should instead make

[Xen-devel] [PULL 03/16] xen: link against xentoolcore

From: Anthony PERARD Xen libraries in 4.10 include a new xentoolcore library. This contains the xentoolcore_restrict_all function which we are about to want to use. Signed-off-by: Ian Jackson Acked-by: Stefano Stabellini

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

>>> On 26.04.18 at 17:20, wrote: > On 04/26/2018 09:33 AM, Jan Beulich wrote: -static void svm_sync_vmcb(struct vcpu *v) +static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) { struct arch_svm_struct *arch_svm =

Re: [Xen-devel] [PATCH 2/8] x86/HVM/SVM: Add AVIC initialization code

On 26/04/18 16:32, Natarajan, Janakarajan wrote: > On 4/16/2018 10:55 AM, Jan Beulich wrote: > On 04.04.18 at 01:01, wrote: >>> >>> +int svm_avic_dom_init(struct domain *d) >>> +{ >>> +    int ret = 0; >>> +    struct page_info *pg; >>> + >>> +    if ( !svm_avic

Re: [Xen-devel] [PATCH 2/8] x86/HVM/SVM: Add AVIC initialization code

On 4/16/2018 10:55 AM, Jan Beulich wrote: On 04.04.18 at 01:01, wrote: From: Suravee Suthikulpanit Introduce AVIC base initialization code. This includes: * Setting up per-VM data structures. * Setting up per-vCPU data

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 04/26/2018 09:33 AM, Jan Beulich wrote: >>> -static void svm_sync_vmcb(struct vcpu *v) >>> +static void svm_sync_vmcb(struct vcpu *v, enum vmcb_sync_state new_state) >>> { >>> struct arch_svm_struct *arch_svm = >arch.hvm_svm; >>> >>> -if ( arch_svm->vmcb_in_sync ) >>> -

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

flight 122399 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122399/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-examine11 examine-serial/bootloader fail REGR. vs. 122343

Re: [Xen-devel] [PATCH 5/7] doc: correct livepatch.markdown syntax

On Tue, Apr 24, 2018 at 08:44:57AM +0200, Juergen Gross wrote: > "make -C docs all" fails due to incorrect markdown syntax in > livepatch.markdown. Correct it. > > Signed-off-by: Juergen Gross > --- > docs/misc/livepatch.markdown | 589 >

Re: [Xen-devel] [PATCH 4/7] doc: escape underscores in xen-command-line.markdown

>>> On 24.04.18 at 08:44, wrote: > Some underscores are not escaped in xen-command-line.markdown. > Correct that. > > Signed-off-by: Juergen Gross Acked-by: Jan Beulich ___ Xen-devel mailing

Re: [Xen-devel] [PATCH 2/7] doc: add architecture qualifier to boot parameter entries

>>> On 24.04.18 at 08:44, wrote: > Many of the architecture specific boot parameters are not qualified > as such. Correct that. I think we want to distinguish between ones really only be meaningful for some architecture vs ones which are currently only implemented for just one.

Re: [Xen-devel] [PATCH 1/7] doc: sort entries of boot parameters correctly

>>> On 24.04.18 at 08:44, wrote: > Some of the boot parameters in docs/misc/xen-command-line.markdown are > not in the correct alphabetically order. Correct that. > > Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich

[Xen-devel] [PATCH] x86/cpuidle: don't init stats lock more than once

Osstest flight 122363, having hit an NMI watchdog timeout, shows CPU1 at Xen call trace: [] _spin_lock+0x30/0x57 [] update_last_cx_stat+0x29/0x42 [] cpu_idle.c#acpi_processor_idle+0x2ff/0x596 [] domain.c#idle_loop+0xa8/0xc3 and CPU0 at Xen call trace: []

[Xen-devel] patchbot mails about staging-* branches

These have been broken since the xen-staging list was withdrawn. I have now made them work again by redirecting them to the xen-changelog list. They can be distinguished from mails about stable branches by the subject line tags. Thanks for your attention. Ian.

Re: [Xen-devel] [PATCH 01/16] checkpatch: Add xendevicemodel_handle to the list of types

> If no one has commented on what seems pretty trivial (especially since > checkpatch.pl has no official maintainer, but is more of a > "whoever-touched-it-last" file at the moment), then including the patch > in your pull request is perfectly acceptable. As a maintainer, it is > also perfectly

[Xen-devel] xenbits DSA ssh keys to be disabled

DSA keys ("dss") are 1024-bit and not really considered good practice any more. By default in Debian's openssh-server, they are now disabled. We are going to disable these soon. Can you please make sure that the ssh keys you use to access xenbits are not DSA keys ? DSA keys start with

Re: [Xen-devel] [PATCH 01/16] checkpatch: Add xendevicemodel_handle to the list of types

On 04/26/2018 06:06 AM, Ian Jackson wrote: > (expanding the CC to include everyone that get_maintainer suggests) > > Ian Jackson writes ("[PATCH 01/16] checkpatch: Add xendevicemodel_handle to > the list of types"): >> This avoids checkpatch misparsing (as statements) long function >>

Re: [Xen-devel] [PATCH v9 1/9] x86/xpti: avoid copying L4 page table contents when possible

Hi, At 13:33 +0200 on 26 Apr (1524749590), Juergen Gross wrote: > For mitigation of Meltdown the current L4 page table is copied to the > cpu local root page table each time a 64 bit pv guest is entered. > > Copying can be avoided in cases where the guest L4 page table hasn't > been modified

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

flight 122446 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122446/ 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] [PATCH] SVM: re-work VMCB sync-ing

>>> On 26.04.18 at 14:43, wrote: > FWIW, In my not-yet-complete patch for the issue, I'd gone with > > @@ -90,7 +91,14 @@ UNLIKELY_END(svm_trace) > pop %r13 > pop %r12 > pop %rbp > + > mov VCPU_svm_vmcb_pa(%rbx),%rax > +

Re: [Xen-devel] [PATCH RESEND v1 6/7] x86: Implement Intel Processor Trace MSRs read/write

>>> On 15.01.18 at 19:12, wrote: > --- a/xen/arch/x86/cpu/intel_pt.c > +++ b/xen/arch/x86/cpu/intel_pt.c > @@ -28,6 +28,107 @@ > bool_t __read_mostly opt_intel_pt = 1; > boolean_param("intel_pt", opt_intel_pt); > > + > +static void intel_pt_disable_intercept_for_msr(u32

Re: [Xen-devel] [PATCH RESEND v1 5/7] x86: Implement Intel Processor Trace context switch

>>> On 15.01.18 at 19:12, wrote: > --- a/xen/arch/x86/cpu/intel_pt.c > +++ b/xen/arch/x86/cpu/intel_pt.c > @@ -21,7 +21,76 @@ > #include > #include > #include > +#include > +#include > > /* intel_pt: Flag to enable Intel Processor Trace (default on). */ > bool_t

[Xen-devel] [xen-4.10-testing test] 122439: trouble: preparing/queued

flight 122439 xen-4.10-testing running [real] http://logs.test-lab.xenproject.org/osstest/logs/122439/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pair queued

Re: [Xen-devel] [PATCH RESEND v1 4/7] x86: add intel processor trace context

>>> On 15.01.18 at 19:12, wrote: > --- a/xen/include/asm-x86/hvm/vmx/vmcs.h > +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h > @@ -20,6 +20,7 @@ > > #include > #include > +#include > > extern void vmcs_dump_vcpu(struct vcpu *v); > extern void setup_vmcs_dump(void); > @@

Re: [Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

On 26/04/18 13:01, Jan Beulich wrote: > While the main problem to be addressed here is the issue of what so far > was named "vmcb_in_sync" starting out with the wrong value (should have > been true instead of false, to prevent performing a VMSAVE without ever > having VMLOADed the vCPU's state),

Re: [Xen-devel] [PATCH] x86: correct vCPU dirty CPU handling

On Thu, Apr 26, 2018 at 03:41:20AM -0600, Jan Beulich wrote: > Commit df8234fd2c ("replace vCPU's dirty CPU mask by numeric ID") was > too lax in two respects: First of all it didn't consider the case of a > vCPU not having a valid dirty CPU in the descriptor table TLB flush > case. This is the

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

>>> On 15.01.18 at 19:12, wrote: > --- a/docs/misc/xen-command-line.markdown > +++ b/docs/misc/xen-command-line.markdown > @@ -1009,6 +1009,13 @@ debug hypervisor only). > ### idle\_latency\_factor > > `= ` > > +### intel\_pt > +> `= ` > + > +> Default: `true` > + >

Re: [Xen-devel] [PATCH RESEND v1 5/7] x86: Implement Intel Processor Trace context switch

On Tue, Jan 16, 2018 at 02:12:31AM +0800, Luwei Kang wrote: > Load/Store Intel processor trace register in context switch. > MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS. > When Intel PT is supported in guest, we need load/restore > PT MSRs only when PT is enabled in guest. > >

Re: [Xen-devel] [PATCH RESEND v1 4/7] x86: add intel processor trace context

On Tue, Jan 16, 2018 at 02:12:30AM +0800, Luwei Kang wrote: > > +#include > + > +struct pt_ctx { > +u64 ctl; > +u64 status; > +u64 output_base; > +u64 output_mask; > +u64 cr3_match; > +u64 addr[NUM_MSR_IA32_RTIT_ADDR]; uint64_t please. > +}; > + > +struct pt_desc { > +

Re: [Xen-devel] [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling

On Tue, Jan 16, 2018 at 02:12:26AM +0800, Luwei Kang wrote: > Hi All, > > Here is a patch-series which adding Processor Trace enabling in XEN guest. > You can get It's software developer manuals from: >

Re: [Xen-devel] [PATCH RESEND v1 1/7] x86: add a flag to enable Intel processor trace

On Tue, Jan 16, 2018 at 02:12:27AM +0800, Luwei Kang wrote: > This patch add a flag to enable Intel PT (Intel processor trace). > Default value is 1 (enabled). > > Signed-off-by: Luwei Kang > --- > docs/misc/xen-command-line.markdown | 7 +++ >

[Xen-devel] [PATCH] SVM: re-work VMCB sync-ing

While the main problem to be addressed here is the issue of what so far was named "vmcb_in_sync" starting out with the wrong value (should have been true instead of false, to prevent performing a VMSAVE without ever having VMLOADed the vCPU's state), go a step further and make the sync-ed state a

[Xen-devel] [PATCH v9 4/9] xen/x86: use invpcid for flushing the TLB

If possible use the INVPCID instruction for flushing the TLB instead of toggling cr4.pge for that purpose. While at it remove the dependency on cr4.pge being required for mtrr loading, as this will be required later anyway. Add a command line option "invpcid" for controlling the use of INVPCID

[Xen-devel] [PATCH v9 2/9] xen/x86: add a function for modifying cr3

Instead of having multiple places with more or less identical asm statements just have one function doing a write to cr3. As this function should be named write_cr3() rename the current write_cr3() function to switch_cr3(). Suggested-by: Andrew Copper Signed-off-by:

[Xen-devel] [PATCH v9 9/9] xen/x86: use PCID feature

Avoid flushing the complete TLB when switching %cr3 for mitigation of Meltdown by using the PCID feature if available. We are using 4 PCID values for a 64 bit pv domain subject to XPTI and 2 values for the non-XPTI case: - guest active and in kernel mode - guest active and in user mode -

[Xen-devel] [PATCH v9 7/9] xen/x86: convert pv_guest_cr4_to_real_cr4() to a function

pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert it from a macro to an ordinary function. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V6: - new patch, split off from (old) patch 7 (Andrew Cooper) --- xen/arch/x86/mm.c

[Xen-devel] [PATCH v9 5/9] xen/x86: disable global pages for domains with XPTI active

Instead of flushing the TLB from global pages when switching address spaces with XPTI being active just disable global pages via %cr4 completely when a domain subject to XPTI is active. This avoids the need for extra TLB flushes as loading %cr3 will remove all TLB entries. In order to avoid

[Xen-devel] [PATCH v9 6/9] xen/x86: use flag byte for decision whether xen_cr3 is valid

Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to be switched on entry to Xen, or negative for keeping the value while indicating not to restore %cr3, or positive in case %cr3 is to be restored. Switch to use a flag byte instead of a negative xen_cr3 value in order to allow

[Xen-devel] [PATCH v9 8/9] xen/x86: add some cr3 helpers

Add some helper macros to access the address and pcid parts of cr3. Use those helpers where appropriate. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich --- V6: - new patch (Andrew Cooper) --- xen/arch/x86/debug.c| 2 +-

[Xen-devel] [PATCH v9 3/9] xen/x86: support per-domain flag for xpti

Instead of switching XPTI globally on or off add a per-domain flag for that purpose. This allows to modify the xpti boot parameter to support running dom0 without Meltdown mitigations. Using "xpti=no-dom0" as boot parameter will achieve that. Move the xpti boot parameter handling to

Re: [Xen-devel] [PATCH for-4.10 v2] SUPPORT.md: Add missing support lifetime information

>>> On 26.04.18 at 12:59, wrote: > Dates are from Wei: > > Supported-Until: > > $ date --date '2017-12-13 + 18 months' +%F > 2019-06-13 > > Security-Support-Until: > > $ date --date '2019-06-13 + 18 months' +%F > 2020-12-13 > > CC: Lars Kurth

Re: [Xen-devel] [PATCH 2/2] docs/process/release-checklist.txt

On 26/04/18 12:52, Ian Jackson wrote: > Clarify what is expected of the release technician for SUPPORT.md: fix > the version number field. The support dates will be set by the > release manageer. > > Signed-off-by: Ian Jackson > CC: Juergen Gross

Re: [Xen-devel] [PATCH 1/2] docs/process/release-technician-checklist.txt: Rename

On 26/04/18 12:52, Ian Jackson wrote: > This contains instructions and shell runes for the Release Technician, > who is the person doing the technical admin to construct the release, > fork branches, make tags and tarballs, etc. > > Rename it to make this clearer. > > Signed-off-by: Ian Jackson

Re: [Xen-devel] [PATCH] x86: correct vCPU dirty CPU handling

>>> On 26.04.18 at 11:51, wrote: > On 26/04/18 10:41, Jan Beulich wrote: >> --- a/xen/arch/x86/mm.c >> +++ b/xen/arch/x86/mm.c >> @@ -1202,11 +1202,23 @@ void put_page_from_l1e(l1_pgentry_t l1e, >> unlikely(((page->u.inuse.type_info & PGT_count_mask) !=

[Xen-devel] [PATCH 1/2] docs/process/release-technician-checklist.txt: Rename

This contains instructions and shell runes for the Release Technician, who is the person doing the technical admin to construct the release, fork branches, make tags and tarballs, etc. Rename it to make this clearer. Signed-off-by: Ian Jackson CC: Juergen Gross

[Xen-devel] [PATCH 2/2] docs/process/release-checklist.txt

Clarify what is expected of the release technician for SUPPORT.md: fix the version number field. The support dates will be set by the release manageer. Signed-off-by: Ian Jackson CC: Juergen Gross --- docs/process/release-technician-checklist.txt |

Re: [Xen-devel] [PATCH] docs: adjust release management doc

On Thu, Apr 26, 2018 at 12:48:44PM +0200, Juergen Gross wrote: > Signed-off-by: Juergen Gross Acked-by: Wei Liu ___ Xen-devel mailing list Xen-devel@lists.xenproject.org

[Xen-devel] [PATCH] docs: adjust release management doc

Signed-off-by: Juergen Gross --- docs/process/xen-release-management.pandoc | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/process/xen-release-management.pandoc b/docs/process/xen-release-management.pandoc index 2ff0665b99..ac324981fd

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

flight 122398 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122398/ 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 122289 test-amd64-amd64-xl-qemut-win7-amd64

Re: [Xen-devel] [PATCH for-4.10] SUPPORT.md: Add missing support lifetime information

>>> On 26.04.18 at 12:05, wrote: > Dates are from Lars. > > CC: Lars Kurth > CC: Juergen Gross > CC: Jan Beulich > CC: George Dunlap > CC: Wei Liu >

Re: [Xen-devel] [PATCH for-4.10] SUPPORT.md: Add missing support lifetime information

On Thu, Apr 26, 2018 at 11:05:33AM +0100, Ian Jackson wrote: > Dates are from Lars. > > CC: Lars Kurth > CC: Juergen Gross > CC: Jan Beulich > CC: George Dunlap > CC: Wei Liu >

Re: [Xen-devel] [PATCH v2 10/10] xen/arm: Call check_local_cpu_errata for secondary CPU only on boot

On 25/04/18 16:13, Mirela Simonovic wrote: Hi Julien, Hi Mirela, On Mon, Apr 23, 2018 at 1:46 PM, Julien Grall wrote: Hi, On 20/04/18 13:25, Mirela Simonovic wrote: Checking CPU errata should be done only when a CPU is initially booted. It is assumed that the CPU

Re: [Xen-devel] [PATCH for-4.10] SUPPORT.md: Add missing support lifetime information

On 04/26/2018 11:05 AM, Ian Jackson wrote: > Dates are from Lars. > > CC: Lars Kurth > CC: Juergen Gross > CC: Jan Beulich > CC: George Dunlap > CC: Wei Liu > Signed-off-by: Ian Jackson

Re: [Xen-devel] [PATCH v2 07/10] xen/arm: Release maintenance interrupt when CPU is hot-unplugged

(+ Andre and Tim) On 25/04/18 15:28, Mirela Simonovic wrote: Hi Julien, Hi, On Wed, Apr 25, 2018 at 3:23 PM, Julien Grall wrote: On 25/04/18 14:09, Mirela Simonovic wrote: On Mon, Apr 23, 2018 at 1:33 PM, Julien Grall wrote: On 20/04/18

[Xen-devel] [PATCH for-4.10] SUPPORT.md: Add missing support lifetime information

Dates are from Lars. CC: Lars Kurth CC: Juergen Gross CC: Jan Beulich CC: George Dunlap CC: Wei Liu Signed-off-by: Ian Jackson --- SUPPORT.md | 4 ++-- 1

Re: [Xen-devel] [PATCH] x86: correct vCPU dirty CPU handling

On 26/04/18 10:41, Jan Beulich wrote: > --- a/xen/arch/x86/mm.c > +++ b/xen/arch/x86/mm.c > @@ -1202,11 +1202,23 @@ void put_page_from_l1e(l1_pgentry_t l1e, > unlikely(((page->u.inuse.type_info & PGT_count_mask) != 0)) && > (l1e_owner == pg_owner) ) > { > +

[Xen-devel] [PATCH] x86: correct vCPU dirty CPU handling

Commit df8234fd2c ("replace vCPU's dirty CPU mask by numeric ID") was too lax in two respects: First of all it didn't consider the case of a vCPU not having a valid dirty CPU in the descriptor table TLB flush case. This is the issue Manual has run into with NetBSD. Additionally reads of

Re: [Xen-devel] [PATCH] x86emul: adjust handling of AVX2 gathers

On 20/04/18 10:25, Jan Beulich wrote: > HVM's MMIO cache only has a capacity of three entries. Once running out > of entries, hvmemul_linear_mmio_access() will return > X86EMUL_UNHANDLEABLE. Since gathers are an iterative process anyway, > simply commit the portion of work done in this and

Re: [Xen-devel] Should PV frontend drivers trust the backends?

On 04/26/2018 11:16 AM, Paul Durrant wrote: -Original Message- From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com] Sent: 26 April 2018 07:00 To: Paul Durrant ; 'Juergen Gross' ; xen-devel Subject: Re:

Re: [Xen-devel] Should PV frontend drivers trust the backends?

On Wed, 25 Apr 2018 13:47:09 + Paul Durrant wrote: > > -Original Message- > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On > > Behalf Of Juergen Gross > > Sent: 25 April 2018 13:43 > > To: xen-devel > >

[Xen-devel] [distros-debian-wheezy test] 74643: all pass

flight 74643 distros-debian-wheezy real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74643/ Perfect :-) All tests in this flight passed as required baseline version: flight 74633 jobs: build-amd64 pass

Re: [Xen-devel] Should PV frontend drivers trust the backends?

> -Original Message- > From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com] > Sent: 26 April 2018 07:00 > To: Paul Durrant ; 'Juergen Gross' > ; xen-devel > Subject: Re: [Xen-devel] Should PV frontend drivers

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

flight 122395 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/122395/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 12 guest-start fail REGR. vs. 118324 Tests which are

[Xen-devel] [ovmf baseline-only test] 74642: regressions - FAIL

This run is configured for baseline tests only. flight 74642 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74642/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 13

Re: [Xen-devel] [PATCH] x86emul: adjust handling of AVX2 gathers

On 20/04/18 11:25, Jan Beulich wrote: > HVM's MMIO cache only has a capacity of three entries. Once running out > of entries, hvmemul_linear_mmio_access() will return > X86EMUL_UNHANDLEABLE. Since gathers are an iterative process anyway, > simply commit the portion of work done in this and

Re: [Xen-devel] [RFC PATCH 1/3] xen: Introduce vcpu_sleep_nosync_locked()

On 11/04/18 14:25, George Dunlap wrote: > There are a lot of places which release a lock before calling > vcpu_sleep_nosync(), which then just grabs the lock again. This is > not only a waste of time, but leads to more code duplication (since > you have to copy-and-paste recipes rather than

Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration

On 11/04/18 14:25, George Dunlap wrote: > The current sequence to initiate vcpu migration is inefficent and error-prone: > > - The initiator sets VPF_migraging with the lock held, then drops the > lock and calls vcpu_sleep_nosync(), which immediately grabs the lock > again > > - A number of

Re: [Xen-devel] Should PV frontend drivers trust the backends?

On 04/25/2018 04:47 PM, Paul Durrant wrote: -Original Message- From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of Juergen Gross Sent: 25 April 2018 13:43 To: xen-devel Subject: [Xen-devel] Should PV frontend drivers trust the