[Xen-devel] [qemu-mainline test] 122575: regressions - trouble: blocked/broken/fail/pass

flight 122575 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122575/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-armhf 4

Re: [Xen-devel] [PATCH 3/3] xen: share start flags between PV and PVH

Hi Roger, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v4.17-rc3 next-20180503] [cannot apply to xen-tip/linux-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url

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

> > > > Here is a patch-series which adding Processor Trace enabling in XEN > > > > guest. You can get It's software developer manuals from: > > > > https://software.intel.com/sites/default/files/managed/c5/15/archi > > > > tect ure-instruction-set-extensions-programming-reference.pdf > > > > In

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

> > Thanks for your clarification. Please correct me if I have > > something wrong. Guest may execute an instruction and this instruction > > may produce an PT packet save in PT output buffer. An EPT violation > > will be generated if the address of this PT buffer don't have EPT page > >

[Xen-devel] 答复: [PATCH v3] x86/cpu: Add supports for zhaoxin x86 platform

发件人: Jan Beulich 发送时间: 2018年5月3日 23:09 收件人: David Wang 抄送: xen-devel; Fiona Li(BJ-RD) 主题: Re: [PATCH v3] x86/cpu: Add supports for zhaoxin x86 platform >>> On 03.05.18 at 06:43, wrote: > From: DavidWang

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

> >>> Here is a patch-series which adding Processor Trace enabling in XEN > >>> guest. You can get It's software developer manuals from: > >>> https://software.intel.com/sites/default/files/managed/c5/15/archite > >>> ct ure-instruction-set-extensions-programming-reference.pdf > >>> In Chapter 5

[Xen-devel] [linux-4.14 test] 122572: trouble: broken/fail/pass

flight 122572 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122572/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-libvirt-xsm broken

[Xen-devel] [linux-3.18 baseline-only test] 74667: tolerable FAIL

This run is configured for baseline tests only. flight 74667 linux-3.18 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74667/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install

[Xen-devel] [examine test] 122584: all pass

flight 122584 examine real [real] http://logs.test-lab.xenproject.org/osstest/logs/122584/ Perfect :-) All tests in this flight passed as required baseline version: flight 122372 jobs: build-amd64 pass build-arm64

[Xen-devel] [xen-4.10-testing test] 122570: trouble: broken/fail/pass

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

[Xen-devel] [examine test] 74669: tolerable FAIL

flight 74669 examine real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74669/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: examine-army 2 host-install broken never pass examine-army

Re: [Xen-devel] [PATCH v9 0/9] xen/x86: various XPTI speedups

On 03/05/18 19:41, Andrew Cooper wrote: > On 02/05/18 11:38, Juergen Gross wrote: >> On 01/05/18 11:28, Andrew Cooper wrote: >>> On 26/04/18 12:33, Juergen Gross wrote: This patch series aims at reducing the overhead of the XPTI Meltdown mitigation. >>> With just the first 3 patches of

Re: [Xen-devel] [PATCH v2 1/2] SVM: re-work VMCB sync-ing

On 05/03/2018 10:43 AM, Jan Beulich wrote: On 02.05.18 at 16:45, wrote: >> On 05/02/2018 03:11 AM, Jan Beulich wrote: >> On 30.04.18 at 19:50, wrote: On 04/30/2018 01:07 PM, Andrew Cooper wrote: > On 30/04/18 12:37, Jan

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

flight 122587 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122587/ 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 v9 0/9] xen/x86: various XPTI speedups

On 02/05/18 11:38, Juergen Gross wrote: > On 01/05/18 11:28, Andrew Cooper wrote: >> On 26/04/18 12:33, Juergen Gross wrote: >>> This patch series aims at reducing the overhead of the XPTI Meltdown >>> mitigation. >> With just the first 3 patches of this series (in a bisection attempt), >> on a

[Xen-devel] [xen-4.7-testing test] 122569: trouble: broken/fail/pass

flight 122569 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122569/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken

Re: [Xen-devel] configure --help lacks explanation of xen-pci-passthrough

Ping? Markus Armbruster writes: > $ ./configure --help | grep -C 3 xen-pci-passthrough > virtfs VirtFS > mpath Multipath persistent reservation passthrough > xen xen backend driver support > xen-pci-passthrough > brlapi BrlAPI

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, 3 May 2018 15:02:36 +0100 Roger Pau Monné wrote: >On Thu, May 03, 2018 at 10:02:47PM +1000, Alexey G wrote: >> On Thu, 3 May 2018 12:15:18 +0100 >> Roger Pau Monné wrote: >> >> >On Thu, May 03, 2018 at 08:55:14PM +1000, Alexey G wrote: >>

Re: [Xen-devel] [PATCH v3] x86/cpu: Add supports for zhaoxin x86 platform

>>> On 03.05.18 at 06:43, wrote: > From: DavidWang > > Zhaoxin is a x86 IC designer. Its SOC products support both CPU > virtualization and I/O virtualization, which are compatible with Intel > VMX and VT-d respectively. Zhaoxin has 'Shanghai' CPU

Re: [Xen-devel] Graduation Review: Windows PV Driver

George Dunlap writes ("Re: [Xen-devel] Graduation Review: Windows PV Driver"): > On Mon, Apr 23, 2018 at 6:14 PM, Lars Kurth wrote: > > ## Summary/Recommendation > > > > Assessment by Lars Kurth, Community Manager: > > > > _Given the maturity of the drivers and thus

Re: [Xen-devel] [PATCH v3] x86/dom0: add extra RAM regions as UNUSABLE for PVH memory map

>>> On 03.05.18 at 16:50, wrote: > When running as PVH Dom0 the native memory map is used in order to > craft a tailored memory map for Dom0 taking into account it's memory > limit. > > Dom0 memory is always going to be smaller than the total amount > of memory present on

[Xen-devel] [OSSTEST PATCH 1/4] mg-allocate: Use ^ for deallocation, not !

! is annoying because some shells enable !-history expantion by default even though few users have any idea about it. In general users are confused by the error message and do not know what to do next. We still honour ! for the benefit of old wrapper scripts, finger macros, etc. Signed-off-by:

[Xen-devel] [OSSTEST PATCH 3/4] mg-adjust-flight-makexrefs: Use ^ for excluding jobs, not !

The ! here doesn't cause shell rune trouble in practice very much, but we want to move to using ^ everywhere for consistency. We still honour !. Signed-off-by: Ian Jackson --- cr-daily-branch| 2 +- mg-adjust-flight-makexrefs | 7 --- 2 files changed,

[Xen-devel] [OSSTEST PATCH 0/4] Use ^ for negation, not !

People keep having trouble with the ! syntax for negation, because of the !-history feature in some shells (notably, enabled by default in bash in all distros). The result is that attempts to deallocate hosts, or do some other things, produces an incomprensible "event not found" message. I don't

[Xen-devel] [OSSTEST PATCH 2/4] mg-hosts: Use ^ for flag negation, not !

We still honour (and document) ! Signed-off-by: Ian Jackson --- README.dev | 2 +- mg-hosts | 19 ++- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/README.dev b/README.dev index 5787bd8..ddfac30 100644 --- a/README.dev +++

[Xen-devel] [OSSTEST PATCH 4/4] Standalone HostFlags: Use ^ for negation, not !

The ! here doesn't cause any shell rune trouble in, but we want to move to using ^ everywhere for consistency. We still honour ! to support old configs. Signed-off-by: Ian Jackson --- Osstest/HostDB/Static.pm | 2 +- README | 4 ++-- 2 files

[Xen-devel] [PATCH v3] x86/dom0: add extra RAM regions as UNUSABLE for PVH memory map

When running as PVH Dom0 the native memory map is used in order to craft a tailored memory map for Dom0 taking into account it's memory limit. Dom0 memory is always going to be smaller than the total amount of memory present on the host, so in order to prevent Dom0 from relocating PCI BARs over

[Xen-devel] [PATCH 3/3] xen: share start flags between PV and PVH

Use a global variable to store the start flags for both PV and PVH. This allows the xen_initial_domain macro to work properly on PVH. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau Monné --- Cc: Boris Ostrovsky

[Xen-devel] [PATCH 1/3] xen/pvh: enable and set default MTRR type

On PVH MTRR is not initialized by the firmware (because there's no firmware), so the kernel is started with MTRR disabled which means all memory accesses are UC. So far there have been no issues (ie: slowdowns) caused by this because PVH only supported DomU mode without passed-through devices, so

[Xen-devel] [PATCH 2/3] xen/store: do not store local values in xen_start_info

There's no need to store the xenstore page or event channel in xen_start_info if they are locally initialized. This also fixes PVH local xenstore initialization due to the lack of xen_start_info in that case. Signed-off-by: Boris Ostrovsky Signed-off-by: Roger Pau

Re: [Xen-devel] [PATCH v2 1/2] SVM: re-work VMCB sync-ing

>>> On 02.05.18 at 16:45, wrote: > On 05/02/2018 03:11 AM, Jan Beulich wrote: > On 30.04.18 at 19:50, wrote: >>> On 04/30/2018 01:07 PM, Andrew Cooper wrote: On 30/04/18 12:37, Jan Beulich wrote: > While the main problem to be

Re: [Xen-devel] [PATCH v2] x86/dom0: add extra RAM regions as UNUSABLE for PVH memory map

>>> On 03.05.18 at 16:13, wrote: > Changes since v1: > - Report the ranges as UNUSABLE instead of RESERVED. Ehem: > --- a/xen/arch/x86/hvm/dom0_build.c > +++ b/xen/arch/x86/hvm/dom0_build.c > @@ -314,8 +314,10 @@ static __init void pvh_setup_e820(struct domain *d, >

[Xen-devel] [PATCH v2] x86/dom0: add extra RAM regions as UNUSABLE for PVH memory map

When running as PVH Dom0 the native memory map is used in order to craft a tailored memory map for Dom0 taking into account it's memory limit. Dom0 memory is always going to be smaller than the total amount of memory present on the host, so in order to prevent Dom0 from relocating PCI BARs over

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

flight 122579 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/122579/ 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 for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, May 03, 2018 at 10:02:47PM +1000, Alexey G wrote: > On Thu, 3 May 2018 12:15:18 +0100 > Roger Pau Monné wrote: > > >On Thu, May 03, 2018 at 08:55:14PM +1000, Alexey G wrote: > >> On Thu, 3 May 2018 10:56:40 +0100 > >> Roger Pau Monne wrote: >

Re: [Xen-devel] Xen 4.9.1 released

And the subject here was of course wrong - please see the correct (4.10.1) announcement sent a minute later. I'm sorry for the spam, Jan >>> On 03.05.18 at 15:47, wrote: > All, > > I am pleased to announce the release of Xen 4.10.1. This is > available immediately from its

[Xen-devel] Xen 4.10.1 released

All, I am pleased to announce the release of Xen 4.10.1. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.1) or from the XenProject download page

[Xen-devel] Xen 4.9.1 released

All, I am pleased to announce the release of Xen 4.10.1. This is available immediately from its git repository http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.1) or from the XenProject download page

Re: [Xen-devel] [Qemu-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

On Thu, 3 May 2018 12:49:59 + Paul Durrant wrote: >> >This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG >> >reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces >> >it with direct calls to pci_host_config_read/write_common(). >> >Doing

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, May 03, 2018 at 05:46:27AM -0600, Jan Beulich wrote: > >>> On 03.05.18 at 11:56, wrote: > > When running as PVH Dom0 the native memory map is used in order to > > craft a tailored memory map for Dom0 taking into account it's memory > > limit. > > > > Dom0 memory is

Re: [Xen-devel] [Qemu-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

> -Original Message- > From: Alexey G [mailto:x19...@gmail.com] > Sent: 03 May 2018 13:41 > To: Paul Durrant > Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Stefano > Stabellini ; Eduardo Habkost > ;

Re: [Xen-devel] [Qemu-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

On Thu, 3 May 2018 12:18:40 +0100 Paul Durrant wrote: >This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG >reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it >with direct calls to pci_host_config_read/write_common(). >Doing so

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

flight 122531 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/122531/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-credit2 18 guest-localmigrate/x10 fail REGR. vs. 122486

[Xen-devel] [ovmf baseline-only test] 74665: all pass

This run is configured for baseline tests only. flight 74665 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74665/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ebafede928b6402b90a1ac2bc5175e50f1a60884 baseline

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

flight 122529 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/122529/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in 122493 pass in 122529

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, 3 May 2018 12:15:18 +0100 Roger Pau Monné wrote: >On Thu, May 03, 2018 at 08:55:14PM +1000, Alexey G wrote: >> On Thu, 3 May 2018 10:56:40 +0100 >> Roger Pau Monne wrote: >> >> >When running as PVH Dom0 the native memory map is used in

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

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

Re: [Xen-devel] [PATCH] xen-hvm: stop faking I/O to access PCI config space

On 03/05/2018 13:18, Paul Durrant wrote: > This patch removes the current hackery where IOREQ_TYPE_PCI_CONFIG > reqyests are handled by faking PIO to 0xcf8 and 0xcfc and replaces it > with direct calls to pci_host_config_read/write_common(). > Doing so necessitates mapping BDFs to PCIDevices but

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

>>> On 03.05.18 at 11:56, wrote: > When running as PVH Dom0 the native memory map is used in order to > craft a tailored memory map for Dom0 taking into account it's memory > limit. > > Dom0 memory is always going to be smaller than the total amount > of memory present on

[Xen-devel] [qemu-mainline test] 122548: regressions - FAIL

flight 122548 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/122548/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 122357 Tests

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

>>> On 03.05.18 at 11:40, wrote: > Thanks for your clarification. Please correct me if I have something > wrong. Guest may execute an instruction and this instruction may produce an > PT packet save in PT output buffer. An EPT violation will be generated if the >

Re: [Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

On Thu, 3 May 2018 10:56:40 +0100 Roger Pau Monne wrote: >When running as PVH Dom0 the native memory map is used in order to >craft a tailored memory map for Dom0 taking into account it's memory >limit. > >Dom0 memory is always going to be smaller than the total amount >of

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

flight 122564 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122564/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122519 test-amd64-i386-xl-qemut-win7-amd64 17

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

flight 122565 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122565/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-arm64-arm64-examine 1

[Xen-devel] [ovmf test] 122568: all pass - PUSHED

flight 122568 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/122568/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ebafede928b6402b90a1ac2bc5175e50f1a60884 baseline version: ovmf

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

On 03/05/18 10:49, Kang, Luwei wrote: >>> Here is a patch-series which adding Processor Trace enabling in XEN guest. >>> You can get It's software developer manuals from: >>> https://software.intel.com/sites/default/files/managed/c5/15/architect >>>

[Xen-devel] [PATCH for-4.11] x86/dom0: add extra RAM regions as RESERVED for PVH memory map

When running as PVH Dom0 the native memory map is used in order to craft a tailored memory map for Dom0 taking into account it's memory limit. Dom0 memory is always going to be smaller than the total amount of memory present on the host, so in order to prevent Dom0 from relocating PCI BARs over

Re: [Xen-devel] [PATCH 0/4] block/xen_disk: legacy code removal and cleanup

On Wed, May 02, 2018 at 05:03:09PM +0100, Paul Durrant wrote: > > -Original Message- > > From: Anthony PERARD [mailto:anthony.per...@citrix.com] > > Sent: 02 May 2018 16:58 > > To: Paul Durrant > > Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu- >

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

> > Here is a patch-series which adding Processor Trace enabling in XEN guest. > > You can get It's software developer manuals from: > > https://software.intel.com/sites/default/files/managed/c5/15/architect > > ure-instruction-set-extensions-programming-reference.pdf > > In Chapter 5 INTEL

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

> >>> On 03.05.18 at 07:22, wrote: > >> And there is one more thing I've not found throughout the series: EPT > > violations and a few other VM exits have gained a new > >> qualification bit, indicating that it's not the current instruction > >> which > > has caused the

[Xen-devel] [linux-4.14 test] 122533: regressions - FAIL

flight 122533 linux-4.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/122533/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-boot fail REGR. vs. 122368 build-armhf

[Xen-devel] [libvirt test] 122567: trouble: broken/pass

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

[Xen-devel] [xen-4.10-testing test] 122560: regressions - FAIL

flight 122560 xen-4.10-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122560/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. vs. 122490

[Xen-devel] [xen-4.7-testing test] 122541: FAIL

flight 122541 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/122541/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd broken in 122500 Tests

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

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

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

On Thu, May 03, 2018 at 04:06:57AM +, Kang, Luwei wrote: > > > Here is a patch-series which adding Processor Trace enabling in XEN > > > guest. You can get It's software developer manuals from: > > > https://software.intel.com/sites/default/files/managed/c5/15/architect > > >

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

On Thu, May 03, 2018 at 01:26:17AM -0600, Jan Beulich wrote: > >>> On 02.05.18 at 18:15, wrote: > > On Wed, May 02, 2018 at 09:43:33AM -0600, Jan Beulich wrote: > >> >>> On 02.05.18 at 17:19, wrote: > >> > On Fri, Apr 27, 2018 at 08:53:30AM +, Kang,

Re: [Xen-devel] [PATCH 3/4] xen/PVH: Set up GS segment for stack canary

>>> On 02.05.18 at 19:29, wrote: > On 05/02/2018 11:41 AM, Jan Beulich wrote: > On 02.05.18 at 17:22, wrote: >>> On 05/02/2018 11:01 AM, Jan Beulich wrote: >>> On 02.05.18 at 17:00, wrote: > On

Re: [Xen-devel] [PATCH] xen: Add RING_COPY_RESPONSE()

On Thu, May 03, 2018 at 06:40:30AM +0200, Juergen Gross wrote: > On 03/05/18 01:45, Marek Marczykowski wrote: > > On Wed, May 02, 2018 at 01:20:09AM -0600, Jan Beulich wrote: > > On 30.04.18 at 23:54, wrote: > >>> Using RING_GET_RESPONSE() on a shared ring is

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

>>> On 03.05.18 at 07:22, wrote: >> And there is one more thing I've not found throughout the series: EPT > violations and a few other VM exits have gained a new >> qualification bit, indicating that it's not the current instruction which > has caused the exit. > > I

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

>>> On 02.05.18 at 18:51, wrote: > On 02/05/18 17:15, Wei Liu wrote: >> On Wed, May 02, 2018 at 09:43:33AM -0600, Jan Beulich wrote: >> On 02.05.18 at 17:19, wrote: On Fri, Apr 27, 2018 at 08:53:30AM +, Kang, Luwei wrote: >>>

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

>>> On 02.05.18 at 18:15, wrote: > On Wed, May 02, 2018 at 09:43:33AM -0600, Jan Beulich wrote: >> >>> On 02.05.18 at 17:19, wrote: >> > On Fri, Apr 27, 2018 at 08:53:30AM +, Kang, Luwei wrote: >> >> > > Load/Store Intel processor trace register in

[Xen-devel] [ovmf baseline-only test] 74663: all pass

This run is configured for baseline tests only. flight 74663 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74663/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 3ff82ee5fc52c8e8764b407ec45cafab8452e2b9 baseline