flight 131310 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131310/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 229ef35384e939333ec5f0c56f2b88cb13a66165
baseline version:
freebsd 25cda747b02
flight 131303 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131303/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt16 guest-start/debian.repeat fail REGR. vs. 131172
Tests which did n
On 12/10/18 2:05 PM, Maran Wilson wrote:
> For certain applications it is desirable to rapidly boot a KVM virtual
> machine. In cases where legacy hardware and software support within the
> guest is not needed, Qemu should be able to boot directly into the
> uncompressed Linux kernel binary without
On Fri, 14 Dec 2018, Julien Grall wrote:
> The helper pte_xen_addr computes the MFN based on the virtual
> address and generates the PTE. This can be r
>
> At the same time, make va a vaddr_t to make clear it holds virtual address.
>
> Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
On Fri, 14 Dec 2018, Julien Grall wrote:
> At the moment, the implementation of Set/Way operations will go through
> all the entries of the guest P2M and flush them. However, this is very
> expensive and may render unusable a guest OS using them.
>
> For instance, Linux 32-bit will use Set/Way ope
On 14/12/2018 03:58, Julien Grall wrote:
> Set/Way operations are used to perform maintenance on a given cache.
> At the moment, Set/Way operations are not trapped and therefore a guest
> OS will directly act on the local cache. However, a vCPU may migrate to
> another pCPU in the middle of the pro
On Fri, 14 Dec 2018, Julien Grall wrote:
> p2m_cache_flush_range does not yet support preemption, this may be an
> issue as cleaning the cache can take a long time. While the current
> caller (XEN_DOMCTL_cacheflush) does not stricly require preemption, this
> will be necessary for new caller in a f
On Fri, 14 Dec 2018, Julien Grall wrote:
> Set/Way operations are used to perform maintenance on a given cache.
> At the moment, Set/Way operations are not trapped and therefore a guest
> OS will directly act on the local cache. However, a vCPU may migrate to
> another pCPU in the middle of the pro
On Fri, 14 Dec 2018, Julien Grall wrote:
> A follow-up patch will require to emulate some accesses to system
> registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes to the
> virtual memory control registers will be trapped to the hypervisor.
>
> This patch adds the infrastructure to passth
flight 131292 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131292/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd broken
test-amd64-i386-q
On 12/13/18 4:37 PM, Paolo Bonzini wrote:
Most files that have TABs only contain a handful of them. Change
them to spaces so that we don't confuse people.
disas, standard-headers, linux-headers and libdecnumber are imported
from other projects and probably should be exempted from the check.
Out
flight 131294 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131294/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 129475
build-i386-xsm
flight 131315 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131315/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce platform_smc as a way to handle firmware calls that Xen does
not know about in a platform specific way. This is particularly useful
for implementing the SiP (SoC implementation specific) service calls.
Signed-off-by: Edgar E. Iglesias
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp specific defines for the firmware calls.
See EEMI:
https://www.xilinx.com/support/documentation/user_guides/ug1200-eemi-api.pdf
The error codes are described, under XIlPM Error Codes:
https://www.xilinx.com/support/documentatio
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Introduce zynqmp_eemi: a function responsible for implementing access
controls over the firmware calls. Only calls that are allowed are
forwarded to the firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
zynqmp_eemi uses the defined functions and structs to decide whether to
make a call to the firmware, or to simply return a predefined value.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
---
Changes in v6:
- mmio_access r
Hi all,
Main changes in this version:
- Removed anything related to domU permissions, only dom0 is allowed to
make EEMI calls for now. It drastically reduces the amount of harcoded
values required.
- Append a patch at the end to handle ZynqMP IPI Mailbox SMC calls as
implemented in ATF
Chee
From: "Edgar E. Iglesias"
From: Edgar E. Iglesias
Stop blacklisting ZynqMP's power management node. It is now possible
since we allow the hardware domain to issue HVC/SMC calls to firmware.
Signed-off-by: Edgar E. Iglesias
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
--
ZynqMP IPI mailbox calls are a small set of EEMI sister calls, often
used in conjunction with EEMI related functionalities.
Unfortunately they are not part of the EEMI spec, or any other public
spec, but the implementation is upstream in ATF:
https://github.com/ARM-software/arm-trusted-firmware/b
flight 131290 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail REGR. vs. 131238
test-armhf-armhf-xl-
Hi,
On 14/12/2018 17:46, Andrii Anisov wrote:
How were you switching between the page-tables? A proper solution would require
to switch between page-tables using an identify mappings. This is far more
complicate than what is worth here.
Sorry for my ignorance, what "identify mappings" stands f
Hi,
On 14/12/2018 17:24, Andrii Anisov wrote:
On 14.12.18 18:26, Julien Grall wrote:
I don't understand how you came up with the conclusion that 128MB will be
removed from Dom0. We only have the requirement that the first bank is at least
128MB. So can you expand it?
IIRC Linux kernel requir
On 14.12.18 18:26, Julien Grall wrote:
Are you using arm64 or arm32?
I'm using arm64.
But also speak about arm32.
I don't understand what you mean. Looking at your log, Xen is relocated at the
end of the last bank. This is the expected behavior in unstable.
Yes, I miscounted zeroes, and r
On 14.12.18 18:26, Julien Grall wrote:
I don't understand how you came up with the conclusion that 128MB will be
removed from Dom0. We only have the requirement that the first bank is at least
128MB. So can you expand it?
IIRC Linux kernel requires that the machine RAM start must be 128MB alig
Allow altp2m users to disable #VE/VMFUNC alone. Currently it is
only possible to disable this functionality when we disable altp2m
completely; #VE/VMFUNC can only be enabled once per altp2m session.
In addition to making things complete, disabling #VE is also a
workaround for CFW116 ("When Virtual
On Fri, 14 Dec 2018, Peter Maydell wrote:
> On Mon, 26 Nov 2018 at 15:03, Anthony PERARD
> wrote:
> >
> > On Mon, Nov 19, 2018 at 04:26:58PM +, Peter Maydell wrote:
> > > Coverity (CID 796599) points out that xen_pt_setup_vga() trusts
> > > the rom->size field in the BIOS ROM from a PCI passt
flight 131291 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131291/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 131168
test-
On 12/14/18 3:52 PM, Andrii Anisov wrote:
> Hello Julien,
Hi,
>
> Let me speculate a bit about the topic.
>
> On 14.12.18 13:44, Julien Grall wrote:
>> At the moment, Xen is relocated towards the end of the memory.
> This statement is not really true. Some time ago, XEN was relocated
> toward t
On 14.12.18 13:44, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely t
On 14.12.18 17:52, Andrii Anisov wrote:
Hello Julien,
Let me speculate a bit about the topic.
On 14.12.18 13:44, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory.
This statement is not really true. Some time ago, XEN was relocated toward the
end of
the low
Hello Julien,
Let me speculate a bit about the topic.
On 14.12.18 13:44, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory.
This statement is not really true. Some time ago, XEN was relocated toward the
end of
the low memory (under 4 GB). Currently, on my board
Hi Matt,
On 11/15/18 5:34 PM, Matt Weber wrote:
From: Christopher Clark
[modified for Xen 4.11 to add required: #include ]
This patch has already been merged in unstable in August. So is it a
backport request for Xen 4.11 (and earlier)?
Cheers,
--
Julien Grall
__
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 14 December 2018 14:50
> To: 'Kevin Wolf'
> Cc: xen-devel@lists.xenproject.org; Stefano Stabellini
> ; qemu-de...@nongnu.org; qemu-bl...@nongnu.org;
> Max Reitz
> Sub
Hello Julien,
On 14.12.18 17:28, Julien Grall wrote:
This could be done automatically if you use git-format-patch to generate the
cover letter at the same time as the patches.
It was done automatically by git-format-patch. But was overwritten by cover
letter content copy-paste from the first
Am Thu, 13 Dec 2018 07:46:36 -0700
schrieb "Jan Beulich" :
> >>> On 13.12.18 at 14:25, wrote:
> > The question is, how much drift can be tolerated even without my patch.
> This depends on what a system is used for. A few seconds off may
> be fine for one purpose, but a significant problem for
Hi Juergen,
On 12/10/18 11:44 AM, Juergen Gross wrote:
With being able to specify a dom0_mem value depending on host memory
size on x86 make it easy for distros to specify a default dom0 size by
adding a CONFIG_DOM0_MEM item which presets the dom0_mem boot parameter
value.
It will be used only
Hi,
I have committed the 2 patches.
In the future, please add the version of the series in the title of the
cover letter. This makes easier for us to know which series is the latest.
This could be done automatically if you use git-format-patch to generate
the cover letter at the same time as
Paolo Bonzini writes:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be exempted from the check.
> Outside tho
Hi Andrii,
On 12/12/18 6:20 PM, Andrii Anisov wrote:
From: Andrii Anisov
Under desc->lock taken:
An IRQ with _IRQ_GUEST flag set always has an action.
An IRQ with _IRQ_DISABLED flag cleared always has an action.
Those flags checks cover all accesses to desc->action in do_IRQ,
so we can skip de
On Thu, Dec 13, 2018 at 11:37:37PM +0100, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be
Hi Paul,
On 12/6/18 3:34 PM, Paul Durrant wrote:
This patch removes any implicit flushing that occurs in the implementation
of map and unmap operations and adds new iommu_map/unmap() wrapper
functions. To maintain sematics of the iommu_legacy_map/unmap() wrapper
NIT: s/sematics/semantics/
fu
On Thu, Dec 13, 2018 at 11:37:37PM +0100, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be
> -Original Message-
[snip]
> > +
> > +blockdev->auto_iothread = iothread;
> > +
> > +object_property_set_bool(OBJECT(dev), true, "realized",
> &local_err);
> > +if (local_err) {
> > +error_propagate_prepend(errp, local_err,
> > +"initiali
flight 131289 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131289/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 129313
test-amd64-
Hi,
I wonder what happened to intel_pstate patch series[1] back in 2015?
I've seen there was some review feedback[2][3][4][5][6][7] on v6,
patches 4/6 and 6/6 were acked. Were the review comments ever addressed
(can't find it)? Or maybe there is some other mechanism in place for proper
power mana
On 12/14/18 7:55 AM, Ross Lagerwall wrote:
> If pcistub_init_device fails, the release function will be called with
> dev_data set to NULL. Check it before using it to avoid a NULL pointer
> dereference.
>
> Signed-off-by: Ross Lagerwall
Reviewed-by: Boris Ostrovsky
_
On Thu, 13 Dec 2018 at 22:38, Paolo Bonzini wrote:
>
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be exempted
The Executable test class runs on host (dom0). The class spawns a
process and searches the program output(stdio) for a specific pattern.
Signed-off-by: Petre Pircalabu
---
xtf/__init__.py| 2 +-
xtf/executable_test.py | 83 ++
xtf/suite.py
This class starts alongside the domain a monitor application which opens
an event channel corresponding to that domain and handles the received
requests.
Use the "monitor_args" key to pass test specific arguments to the
monitor application.
The arguments will be added in the test's Makefile using t
Add a new test to verify if XEN can correctly handle the
X86EMUL_UNIMPLEMENTED event.
The XTF DomU test image just executes a instruction not implemented by
the XEN X86 emulator (fstenv) and checks if the execution was
successfull. This instruction will be the first one in a custom .text
section.
Extend the framework to support (simple) monitor related tests.
Petre Pircalabu (4):
xtf-runner: split into logical components
xtf: Add executable test class
xtf: Add monitor test class
xtf: Add emul-unimpl test
Makefile | 6 +-
build/common.mk| 2
Split the xtf-runner script file into multiple modules in order to
support multiple test types.
Features:
- 2 abstract types (TestInfo and TestInstance) to represent the
test information (info.json) and, respectively to implement the test
execution.
TestInfo has to implement the "all_ins
If pcistub_init_device fails, the release function will be called with
dev_data set to NULL. Check it before using it to avoid a NULL pointer
dereference.
Signed-off-by: Ross Lagerwall
---
drivers/xen/xen-pciback/pci_stub.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/d
Hi Oleksandr,
This is looking a lot better than v2. I do have a few remaining comments about
some things that are a bit unclear to me.
On 12/12/18 10:49 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> This is the ABI for the two halves of a para-virtualized
> camera drive
Set/Way operations are used to perform maintenance on a given cache.
At the moment, Set/Way operations are not trapped and therefore a guest
OS will directly act on the local cache. However, a vCPU may migrate to
another pCPU in the middle of the processor. This will result to have
cache with stall
A follow-up patch will require to emulate some accesses to system
registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes to the
virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to the host
registers.
Note that
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.
For instance, Linux 32-bit will use Set/Way operations during secondary
CPU bring-up. As the imple
p2m_cache_flush_range does not yet support preemption, this may be an
issue as cleaning the cache can take a long time. While the current
caller (XEN_DOMCTL_cacheflush) does not stricly require preemption, this
will be necessary for new caller in a follow-up patch.
The preemption implemented is qu
A follow-up patch will require to emulate some accesses to some
co-processors registers trapped by HCR_EL2.TVM. When set, all NS EL1 writes
to the virtual memory control registers will be trapped to the hypervisor.
This patch adds the infrastructure to passthrough the access to host
registers. For
Hi all,
This is version 3 of the series to implement set/way. For more details see
patch #4.
A branch with the code is available at:
https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
branch cacheflush/v3
Cheers,
Julien Grall (5):
xen/arm: vcpreg: Add wrappers to handle co-proc
>>> On 14.12.18 at 12:45, wrote:
> On Fri, Dec 14, 2018 at 03:45:21AM -0700, Jan Beulich wrote:
>> >>> On 14.12.18 at 11:03, wrote:
>> > I expect the interdomain locking as a result of using a paging caller
>> > domain is going to be restricted to the p2m lock of the caller domain,
>> > as a resu
On Mon, 26 Nov 2018 at 15:03, Anthony PERARD wrote:
>
> On Mon, Nov 19, 2018 at 04:26:58PM +, Peter Maydell wrote:
> > Coverity (CID 796599) points out that xen_pt_setup_vga() trusts
> > the rom->size field in the BIOS ROM from a PCI passthrough VGA
> > device, and uses it as an index into the
Block interrupts (in vmx_intr_assist()) for the duration of
processing a sync vm_event (similarly to the strategy
currently used for single-stepping). Otherwise, attempting
to emulate an instruction when requested by a vm_event
reply may legitimately need to call e.g.
hvm_inject_page_fault(), which
On Fri, Dec 14, 2018 at 03:45:21AM -0700, Jan Beulich wrote:
> >>> On 14.12.18 at 11:03, wrote:
> > I expect the interdomain locking as a result of using a paging caller
> > domain is going to be restricted to the p2m lock of the caller domain,
> > as a result of the usage of copy to/from helpers.
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires to switch
between two sets of page-table. This is not entirely trivial to fix as
it would require us to g
The helper pte_xen_addr computes the MFN based on the virtual
address and generates the PTE. This can be r
At the same time, make va a vaddr_t to make clear it holds virtual address.
Signed-off-by: Julien Grall
---
Changes in v2:
- New patch
---
xen/arch/arm/mm.c | 5 ++---
1 file
Hi all,
This patch series aims to boot Xen again on the Hikey Board.
Cheers,
Julien Grall (2):
xen/arm: mm: Use pte_xen_addr when creating xen entries
xen/arm: Stop relocating Xen
xen/arch/arm/arm32/head.S | 54 +++
xen/arch/arm/arm64/head.S | 50 +--
On 14/12/18 11:22, Daniel P. Berrangé wrote:
>> crypto/aes.c
>> crypto/desrfb.c
>
> I'd rather like this to be cleaned to finish the job for
> crypto/.
Ok, will do.
Paolo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
On Thu, 13 Dec 2018 23:37:37 +0100
Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be exem
>>> On 14.12.18 at 11:03, wrote:
> I expect the interdomain locking as a result of using a paging caller
> domain is going to be restricted to the p2m lock of the caller domain,
> as a result of the usage of copy to/from helpers.
>
> Maybe the less intrusive change would be to just allow locking
Hi Stefano,
On 12/12/2018 23:53, Stefano Stabellini wrote:
On Thu, 29 Nov 2018, Julien Grall wrote:
At the moment, Xen is relocated towards the end of the memory. While
this has the advantage to free space in low memory, the code is not
compliant with the break-before-make because it requires t
Hello Juergen,
On 13.12.18 18:37, Juergen Gross wrote:
You should use linux kernel commit 3596924a233e45aa918.
That is exactly what is needed.
Thank you!
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://
On Thu, Dec 13, 2018 at 11:37:37PM +0100, Paolo Bonzini wrote:
> Most files that have TABs only contain a handful of them. Change
> them to spaces so that we don't confuse people.
>
> disas, standard-headers, linux-headers and libdecnumber are imported
> from other projects and probably should be
On Thu, Dec 13, 2018 at 08:22:52PM +, Andrew Cooper wrote:
> For both VT-x and SVM, the RDTSCP intercept will trigger if the pipeline
> supports the instruction, but the guest may have not have rdtscp in its
^ extra have
> featureset. Bring the vme
>>> On 14.12.18 at 01:52, wrote:
> PVRDTSCP is believed-unused, and its implementation has adverse consequences
> on unrelated functionality in the hypervisor. As a result, support has been
> removed.
>
> Modify libxl to provide a slightly more helpful error message if it
> encounters
> PVRDTSC
>>> On 13.12.18 at 21:22, wrote:
> --- a/xen/arch/x86/hvm/svm/emulate.c
> +++ b/xen/arch/x86/hvm/svm/emulate.c
> @@ -143,8 +143,17 @@ int svm_get_insn_len(struct vcpu *v, enum
> instruction_index insn)
> }
>
> gdprintk(XENLOG_WARNING,
> - "%s: Mismatch between expected and
>>> On 13.12.18 at 21:22, wrote:
> @@ -98,13 +97,10 @@ int __get_instruction_length_from_list(struct vcpu *v,
> * hardware.
> */
> #ifdef NDEBUG
> -if ( (inst_len = svm_nextrip_insn_length(v)) > MAX_INST_LEN )
> -gprintk(XENLOG_WARNING, "NRip reported inst_len %lu\n", inst
On Thu, Dec 13, 2018 at 08:53:22AM -0700, Jan Beulich wrote:
> >>> On 13.12.18 at 16:34, wrote:
> > On Thu, Dec 13, 2018 at 07:52:16AM -0700, Jan Beulich wrote:
> >> >>> On 13.12.18 at 15:14, wrote:
> >> > On Thu, Dec 13, 2018 at 05:51:51AM -0700, Jan Beulich wrote:
> >> >> >>> On 13.12.18 at 12:
flight 131287 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131287/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 131219
test-amd64-amd64-libvir
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 13 December 2018 20:23
> To: Xen-devel
> Cc: Andrew Cooper ; Jan Beulich
> ; Wei Liu ; Roger Pau Monne
> ; Paul Durrant ; Boris
> Ostrovsky ; Suravee Suthikulpanit
> ; Brian Woods
> Subject: [PATCH v2 2/
flight 131282 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131282/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 130985
test-armhf-armhf-libvirt 14 save
Now that we require use of the {evex} pseudo-prefix, we can also use
the q-suffixed encoding of VPCMPESTRI, which is available as of 2.29
just like {evex} is.
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -3322
Commit fd35f32b4b ("tools/x86emul: Use struct cpuid_policy in the
userspace test harnesses") didn't account for the dependencies of
cpuid-autogen.h to potentially change between incremental builds.
Putting the make invocation to produce the header together with the
directory tree creation therefore
On Fri, Dec 14, 2018 at 09:09:45AM +0200, Oleksandr Andrushchenko wrote:
> On 12/13/18 5:48 PM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
> > > Daniel, could you please comment?
> > Cross-revieweing someone else's stuff would scale better,
> f
flight 131279 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131279/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-xl-q
flight 131276 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131276/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 125898
test-amd64-amd64-py
87 matches
Mail list logo
