* Juergen Gross wrote:
> You can just dive into the discussion we had back in February:
That was half a year and a thousand commits ago! ;-)
> https://lore.kernel.org/lkml/20180213163244.j2zuxyhs4kbfh...@gmail.com/
>
> The scheme I have used in V5 of the series is the one you agreed to use
>
On 10/10/2018 09:19, Ingo Molnar wrote:
>
> * Juergen Gross wrote:
>
>> You can just dive into the discussion we had back in February:
>
> That was half a year and a thousand commits ago! ;-)
Yes. :-)
>
>> https://lore.kernel.org/lkml/20180213163244.j2zuxyhs4kbfh...@gmail.com/
>>
>> The sche
flight 128528 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128528/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 78af0984b45a780e45d57c22c85a1f594b969212
baseline version:
ovmf a7ab1c315c3cf5e804897
On 07/10/2018 22:05, Boris Ostrovsky wrote:
> Xend-based toolstacks don't have static-max entry in xenstore. The
> equivalent node for those toolstacks is memory_static_max.
>
> Fixes: 5266b8e4445c (xen: fix booting ballooned down hvm guest)
> Signed-off-by: Boris Ostrovsky
> Cc: # 4.13
Committ
On 09/10/2018 12:32, Roger Pau Monne wrote:
> While booting on an AMD EPYC box the stack canary would detect stack
> overflows when using the current PVH early stack size (256). Switch to
> using the value defined by BOOT_STACK_SIZE, which prevents the stack
> overflow.
>
> Signed-off-by: Roger Pa
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> i
> If the Xen community wishes to provide feedback on this NISTIR draft, I
> suggest compiling a single document, including:
I hope so: we may as well use the relevant section in
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edi
to collate the feedback
But I can
flight 128568 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128568/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
build-armhf
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Wei Liu
> Sent: 09 October 2018 19:58
> To: xen-devel@lists.xenproject.org
> Cc: Wei Liu ; Jan Beulich ; Roger
> Pau Monne
> Subject: [Xen-devel] [PATCH] iommu: fix arm build after e9be34b
On Tue, Oct 09, 2018 at 11:42:35AM +0200, Roger Pau Monne wrote:
> BAR map/unmap is a long running operation that needs to be preempted
> in order to avoid overrunning the assigned vCPU time (or even
> triggering the watchdog).
>
> Current logic for this preemption is wrong, and won't work at all
On Wed, Oct 10, 2018 at 09:59:21AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Wei Liu
> > Sent: 09 October 2018 19:58
> > To: xen-devel@lists.xenproject.org
> > Cc: Wei Liu ; Jan Beulich ; Roger
> >
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 October 2018 10:10
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Julien Grall ;
> Konrad Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org)
> S
> -Original Message-
> From: Roger Pau Monne
> Sent: 10 October 2018 10:13
> To: Paul Durrant
> Cc: Wei Liu ; xen-devel@lists.xenproject.org; Jan
> Beulich
> Subject: Re: [Xen-devel] [PATCH] iommu: fix arm build after e9be34be5
>
> On Wed, Oct 10, 2018 at 09:59:21AM +0100, Paul Durrant w
On 09/10/18 20:34, Spencer Michaels wrote:
> Hello,
>
> I'm developing an application that runs in Dom0 and needs to read
> memory from a guest given a guest address (for instance, reading RIP
> from the guest CPU context and then reading the current instruction).
> I'm using xenforeignmemory_map()
flight 128581 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128581/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 85b00385827e4e061b2ff38b549c03d0f1e66b6a
baseline version:
xen 91d4
This run is configured for baseline tests only.
flight 75383 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75383/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
>>> On 09.10.18 at 20:58, wrote:
> The function iommu_share_p2m_table is used by both ARM and x86 but
> hap_enabled macro is x86 only. Put the ASSERT under CONFIG_X86.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen
On 2018-10-10 13:37, Oscar Salvador wrote:
On Fri, Oct 05, 2018 at 01:40:05PM +0530, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from
flight 128579 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
build-armhf
On Wed, Oct 10, 2018 at 04:21:16PM +0530, Arun KS wrote:
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index e379e85..2416136 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -690,9 +690,13 @@ static int online_pages_range(unsigned long start_pfn,
> unsigned long nr_
Hi,
sorry, my explanation wasn't precise and I missed the point.
vCPU pinning with sched=null I put "just in case", because it doesn't hurt.
Yes, PetaLinux domain is dom0.
Tested with Credit scheduler before (it was just the LED blink
application but anyway), it results with bigger jitter then nu
Attachments.
name = "test"
kernel = "timer.bin"
memory = 8
vcpus = 1
cpus = [1]
irqs = [ 48, 54, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79 ]
iomem = [ "0xff010,1", "0xff110,1", "0xff120,1", "0xff130,1", "0xff140,1",
"0xff0a0,1" ][0.00] Booting Linux on physical CPU 0x0
[0.00]
On 10/09/2018 04:21 PM, Wei Liu wrote:
> On Tue, Oct 09, 2018 at 04:16:48PM +0100, George Dunlap wrote:
>> On 10/09/2018 04:12 PM, Wei Liu wrote:
>>> On Tue, Oct 02, 2018 at 04:49:26PM +0100, George Dunlap wrote:
Commit 3b4adba ("tools/libxl: include scheduler parameters in the
output of
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: d8
On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> - /* If irq pending already clear it and return. */
> + /* Guard against reentry. */
> + local_irq_save(flags);
> +
> + /* If irq pending already clear it. */
> if (xen_test_irq_pending(irq)) {
>
On Wed, 10 Oct 2018, David Woodhouse wrote:
> On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> > - /* If irq pending already clear it and return. */
> > + /* Guard against reentry. */
> > + local_irq_save(flags);
> > +
> > + /* If irq pending already clear it. */
>
On Wed, 2018-10-10 at 14:30 +0200, Thomas Gleixner wrote:
> On Wed, 10 Oct 2018, David Woodhouse wrote:
>
> > On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> > > - /* If irq pending already clear it and return. */
> > > + /* Guard against reentry. */
> > > + local_irq_s
On Wed, 10 Oct 2018, David Woodhouse wrote:
> On Wed, 2018-10-10 at 14:30 +0200, Thomas Gleixner wrote:
> > On Wed, 10 Oct 2018, David Woodhouse wrote:
> >
> > > On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> > > > - /* If irq pending already clear it and return. */
> > > > +
flight 128587 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128587/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
128513
Tests
On 10/10/2018 14:47, Thomas Gleixner wrote:
> On Wed, 10 Oct 2018, David Woodhouse wrote:
>> On Wed, 2018-10-10 at 14:30 +0200, Thomas Gleixner wrote:
>>> On Wed, 10 Oct 2018, David Woodhouse wrote:
>>>
On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> - /* If irq pending alr
flight 75385 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75385/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
> The Xen HV is doing it right. It is blocking the vcpu in do_poll() and
> any interrupt will unblock it.
Great. Thanks for the confirmation.
--
dwmw2
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/lis
Instead of just doing it for the BSP. This requires storing the
maximum number of possible vCPUs in xc_dom_image.
This has been a latent bug so far because PVH doesn't yet support
pci-passthrough, so the effective memory cache attribute is forced to
WB by the hypervisor. Note also that even withou
I have, but libvmi doesn't fit my use case — it only works with Windows and
Linux HVM guests. I will need my application to work with PV and HVM guests
that are neither Windows nor Linux.
libvmi's implementation of this, `xen_get_memory()` in
`libvmi/driver/xen/xen.c`, seems to assume that MFN = (
Wei Liu writes ("Re: [PATCH] tools/libxenstat: Fix SONAME following c/s
57077cc42"):
> On Tue, Oct 09, 2018 at 03:06:32PM +0100, Andrew Cooper wrote:
> > The unstable ABI version is 4.12, not 4.11
> >
> > Signed-off-by: Andrew Cooper
>
> Acked-by: Wei Liu
Thanks for fixing this. I have/had a
Paraschiv, Andra-Irina writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional]
xen/pt: allow QEMU to request MSI unmasking at bind time"):
> One of the use cases where this fix is needed is: guest OS is Windows and the
> host has the latest stable version of xen and qemu-xen-traditional. Using
> t
On 10/09/2018 05:09 PM, Juergen Gross wrote:
> xenbus_va_dev_error() will try to write error messages to Xenstore
> under the error//error node (with something like
> "device/vbd/51872"). This will fail normally and another message
> about this failure is added to dmesg.
>
> I believe this is a r
Anthony PERARD writes ("[PATCH v5 01/15] libxl: Design of an async API to issue
QMP commands to QEMU"):
> All the functions will be implemented in later patches.
This patch looks good to me. Although it's a bit odd to mix some
typedef name shuffling in the same patch, I think it's OK here given
On Wed, Oct 10, 2018 at 8:47 AM Spencer Michaels
wrote:
>
> I have, but libvmi doesn't fit my use case — it only works with Windows and
> Linux HVM guests. I will need my application to work with PV and HVM guests
> that are neither Windows nor Linux.
LibVMI works with PV guests and you can ini
Anthony PERARD writes ("[PATCH v5 02/15] libxl_qmp: Connect to QMP socket"):
> This is a first patch to implement libxl__ev_qmp, it only connects to
> the QMP socket of QEMU and registers a fd callback that does nothing.
...
> +typedef enum {
> +/* initial state */
> +qmp_state_disconnected
On 10/5/18 10:10 AM, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add
Anthony PERARD writes ("[PATCH v5 03/15] libxl_qmp: Implement fd callback and
read data"):
> First step into taking care of the input from QEMU's QMP socket. For
> now, we read data and store them in a buffer.
...
> +if (!ev->rx_buf) {
> +ev->rx_buf = libxl__malloc(NOGC, QMP_RECEIVE_BU
On 10/10/2018 17:09, Joao Martins wrote:
> On 10/09/2018 05:09 PM, Juergen Gross wrote:
>> xenbus_va_dev_error() will try to write error messages to Xenstore
>> under the error//error node (with something like
>> "device/vbd/51872"). This will fail normally and another message
>> about this failur
On 09/10/2018 13:02, Juergen Gross wrote:
> This patch series adds support for booting Linux as PVH guest.
>
> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> platform grub is booted as a standalone image directly by Xen.
>
> For booting Linux kernel it is using the standard li
flight 128520 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
test-amd
flight 128593 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128593/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
128513
Tests
On 10/5/18 10:10 AM, Arun KS wrote:
> They not only increase the code footprint, they actually make things
> slower rather than faster. Remove them as contemporary hardware doesn't
> need any hint.
>
> Suggested-by: Dan Williams
> Signed-off-by: Arun KS
Yeah, a tight loop with fixed stride is a
[Just add some thoughts on this.]
On Wed, Oct 10, 2018 at 4:22 AM Milan Boberic wrote:
>
> Hi,
> sorry, my explanation wasn't precise and I missed the point.
> vCPU pinning with sched=null I put "just in case", because it doesn't hurt.
>
> Yes, PetaLinux domain is dom0.
The jitter may come from
On 2018-10-10 21:00, Vlastimil Babka wrote:
On 10/5/18 10:10 AM, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less th
On 10/10/18 11:53 AM, Juergen Gross wrote:
> On 10/10/2018 17:09, Joao Martins wrote:
>> On 10/09/2018 05:09 PM, Juergen Gross wrote:
>>> xenbus_va_dev_error() will try to write error messages to Xenstore
>>> under the error//error node (with something like
>>> "device/vbd/51872"). This will fail
flight 128521 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128521/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 128441
test-armhf-armhf-libvirt-raw 13 saveresto
On Wed 10-10-18 22:26:41, Arun KS wrote:
> On 2018-10-10 21:00, Vlastimil Babka wrote:
> > On 10/5/18 10:10 AM, Arun KS wrote:
> > > When free pages are done with higher order, time spend on
> > > coalescing pages by buddy allocator can be reduced. With
> > > section size of 256MB, hot add latency
This run is configured for baseline tests only.
flight 75386 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75386/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128524 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128108
build-arm64
When a MSI interrupt is bound to a guest using
xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt is
left masked by default.
This causes problems with guests that first configure interrupts and
clean the per-entry MSIX table mask bit and afterwards enable MSIX
globally. In such scenar
Ian Jackson writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional] xen/pt: allow
QEMU to request MSI unmasking at bind time"):
>
> Paraschiv, Andra-Irina writes ("Re: [Xen-devel] [PATCH qemu-xen-traditional]
> xen/pt: allow QEMU to request MSI unmasking at bind time"):
> > One of the use cases whe
flight 128602 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128602/
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
flight 128582 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 7 xen-build-freebsdfail REGR. vs. 128497
version targeted
branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-arm64
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug introduced: d86c9a
Hi all,
thank you to those joining the call. The minutes are attached and at
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit
Feel free to make corrections. Also, I created
https://wiki.xenproject.org/wiki/Characterizing_Vulnerabilities_in_Platform_Security
On Fri, 24 Aug 2018, Julien Grall wrote:
> > > > +
> > > > +bool zynqmp_eemi(struct cpu_user_regs *regs)
> > > > +{
> > > > +return false;
> > > > +}
> > > > +
> > > > +/*
> > > > + * Local variables:
> > > > + * mode: C
> > > > + * c-file-style: "BSD"
> > > > + * c-basic-offset: 4
> > > > + *
Interesting … sorry, I had read the docs a while ago and my interpretation
at the time was that it didn't. I can try to get libvmi working, but
nonetheless I do want to figure out how to this with the Xen API itself if
at all possible, so I'd appreciate any help in doing so.
I've looked through li
On Tue, 28 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/08/18 01:01, Stefano Stabellini wrote:
> > From: "Edgar E. Iglesias"
> >
> > From: Edgar E. Iglesias
> >
> > Introduce data structs to implement basic access controls.
> > Introduce the following three functions:
> >
> > domain_
On Tue, 28 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 11/08/18 01:01, Stefano Stabellini wrote:
> > 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 re
On 10/10/18 23:08, Spencer Michaels wrote:
> Interesting … sorry, I had read the docs a while ago and my
> interpretation at the time was that it didn't. I can try to get libvmi
> working, but nonetheless I do want to figure out how to this with the
> Xen API itself if at all possible, so I'd appre
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 in v4:
- fix typo
- add hea
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
Signed-off-by: Stefano Sta
Hi all,
This patch is an update over this old patch series:
https://marc.info/?l=xen-devel&m=148579695530482
I inherited the seriest from Edgar, I made significant changes over the
old version, including addressing (almost) all comments. The main
changes are:
- split the largest patch into mult
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 v4:
- add #include as needed
- improve comment
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/documentation/user_guides/ug1137-zynq-ul
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
---
xen/arch/arm/platforms/xi
From: Edgar E. Iglesias
Introduce data structs to implement basic access controls.
Introduce the following three functions:
domain_has_node_access: check access to the node
domain_has_reset_access: check access to the reset line
domain_has_mmio_access: check access to the register
Signed-off-by
On Fri, Sep 07, 2018 at 04:10:50PM +0100, Anthony PERARD wrote:
> All the functions will be implemented in later patches.
>
> This patch includes the API that libxl can use to send QMP commands to
> QEMU.
>
> Signed-off-by: Anthony PERARD
> ---
>
> Notes:
> v5:
> some changes in the
flight 128573 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128573/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2730470f9d3bbaed51a04a11bfc1bf21670fa49e
baseline version:
ovmf 78af0984b45a780e45d57
flight 128523 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128523/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128498
test-amd64-i386-xl-qemuu-win7-amd64
On 2018-10-10 23:03, Michal Hocko wrote:
On Wed 10-10-18 22:26:41, Arun KS wrote:
On 2018-10-10 21:00, Vlastimil Babka wrote:
> On 10/5/18 10:10 AM, Arun KS wrote:
> > When free pages are done with higher order, time spend on
> > coalescing pages by buddy allocator can be reduced. With
> > secti
flight 128526 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128526/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
test-armhf-armh
On 10/10/2018 18:57, Boris Ostrovsky wrote:
> On 10/10/18 11:53 AM, Juergen Gross wrote:
>> On 10/10/2018 17:09, Joao Martins wrote:
>>> On 10/09/2018 05:09 PM, Juergen Gross wrote:
xenbus_va_dev_error() will try to write error messages to Xenstore
under the error//error node (with somet
This run is configured for baseline tests only.
flight 75389 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75389/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
>>> On 02.10.18 at 12:51, wrote:
> On 02/10/18 11:36, Jan Beulich wrote:
> On 25.09.18 at 16:14, wrote:
>>> Emulation requiring device model assistance uses a form of instruction
>>> re-execution, assuming that the second (and any further) pass takes
>>> exactly the same path. This is a valid
flight 128535 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 127900
build-armhf
81 matches
Mail list logo
