This run is configured for baseline tests only.
flight 74668 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74668/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 22 leak-check/ch
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 host-ins
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
> > > > 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 C
> > 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
> > table
发件人: 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
>
> Zhaoxin is a x86 IC designer. Its SOC products
> >>> 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 I
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
test-amd64-i386-libvir
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-installfail
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
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
test-amd64-amd64
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
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 th
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 Beulich wrote:
>> While the main problem to be addresse
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 1
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
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
test-a
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 (Braile)
> curl
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:
>> >> On Thu, 3 May 2018 10:56:40 +0100
>> >> R
>>> 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 vendor ID.
>
> Signed-off-by: DavidWang
> ---
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 limited need to fix issues or
>>> 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 the host, so in order to
! 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: I
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, 5 insertions(+), 4 deletion
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
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
+++ b/README.dev
@@ -145,7 +145,7 @@ Bl
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 changed, 3 insertions(+), 3 deletio
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 RA
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
Cc: Juergen Gross
Cc: xen-devel@lists.xenproject.org
---
arch/x86/xen/enl
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
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 Monné
---
Cc: Boris Ostrovsky
>>> 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 addressed here is the issue of what so far
> was name
>>> 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,
> unsigned long nr_pages)
>
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 RA
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 1
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:
> >>
> >> >When running as PVH Dom0 the nati
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 git repository
> http
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
http://www.xenproject.org/downloads/xen-archives/xen
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
http://www.xenproject.org/downloads/xen-archives/xen
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 so necessitates mapping BDF
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 always going to be smal
> -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
> ; Michael S. Tsirkin ; Marcel
> Apfelbaum ; Anthony Perard
> ; Paolo Bonzini ;
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 necessitates mapping BDFs to PCIDev
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
test-armhf-armhf-xl-
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 v
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
test-amd64-a
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 order to
>> >craft a tailored memory map for Dom0
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
test-armhf-armhf-li
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 ma
>>> 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 the host, so in order to
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 whic
>>> 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
> address of this PT buffer
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 maintaining a simple
QLIST in xen_device_realize/un
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 order to
> >craft a tailored memory map for Dom0 taking into account it's memory
> >limit.
> >
> >Dom0 memory is al
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 memory present on the h
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
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 build-check
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 3ff82ee5fc52c8e8764b4
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
>>> ure-instruction-set-extensions-programming-refer
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 RA
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-
> > de...@nongnu.org; Stefa
> > 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 PROCES
> >>> 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 don't q
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
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
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
te
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
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
build-armh
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
> > > ure-instruction-s
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, Luwei wrote:
> >> >> > > Load/Store Intel p
>>> 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 05/02/2018 04:16 AM, Jan Beulich wrote:
> On 30.04.18 at 18:23, wrote:
>>> --
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 easy to use incorrectly
> >>> (i.e
>>> 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 don't quite understand
>>> 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:
>>> Load/Store Intel processor trace register in context s
>>> 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 context switch.
>> >> > > MSR IA32_RTIT_CTL
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 v
76 matches
Mail list logo
