On Mon, 15 Oct 2018, Milan Boberic wrote:
> In attachment are device-tree files I found in my project:
>
> device-tree.bbappend - under
> /uz3eg_iocc_2018_2/project-spec/meta-user/recipes-bsp/device-tree/
>
> xen-overlay.dtsi , system-user.dtsi and zunqmp-qemu-arm.dts - under
> /uz3eg_iocc_2018_2
Hi Stefano,
> On 9 Oct 2018, at 12:52, Julien Grall wrote:
>
> Hi Stefano,
>
> On 05/10/2018 19:47, Stefano Stabellini wrote:
>> Add a new document to provide information on how to use dom0less related
>> features and their current limitations.
>> Signed-off-by: Stefano Stabellini
>> ---
>> Ch
This run is configured for baseline tests only.
flight 75428 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75428/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
xen_create_contiguous_region has now only an implementation if
CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
we do have an implementation of xen_create_contiguous_region which is
required for swiotlb-xen to work correctly (although it just sets
*dma_handle).
This fixes a
flight 128727 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128727/
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 128834 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128834/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 47f15da16053f031bcf7c50f6960bd0f6c83d2db
baseline version:
ovmf aa52648c1e6f26b6b8734
Hi,
On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
On Tue, 28 Aug 2018, Julien Grall wrote:
On 11/08/18 01:01, Stefano Stabellini wrote:
#include
#include
#include
@@ -23,6 +91,721 @@
#include
#include
+struct pm_access
+{
+paddr_t addr;
It seems that the addres
On 10/13/2018 05:01 PM, Milan Boberic wrote:
Hi,
Hi,
Don't interrupt _come_ from hardware and go/are routed to
hypervisor/os/app?
Yes they do, sorry, I reversed the order because I'm a newbie :) .
Would you mind to explain what is the triple timer counter?
On this link on page 342 is
Hi,
On 10/10/2018 11:49 PM, Stefano Stabellini wrote:
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
On 16/10/18 02:34, Stefano Stabellini wrote:
> On Mon, 15 Oct 2018, Julien Grall wrote:
>> Hi,
>>
>> Please use scripts/get_maintainers.pl to CC relevant maintainers.
>>
>> On 15/10/2018 10:56, Stefano Stabellini wrote:
>>> Introduce a macro, __symbol, which is a simple wrapper around RELOC_HIDE
>>
On 15/10/18 15:52, Alexandru Stefan ISAILA wrote:
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
>
> Signed-off-by: Alexandru Isaila
> ---
> xen/arch/x
Hi,
On 10/16/2018 09:38 AM, Stefano Stabellini wrote:
xen_create_contiguous_region has now only an implementation if
CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
we do have an implementation of xen_create_contiguous_region which is
required for swiotlb-xen to work cor
flight 128744 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128744/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
Tests which are f
flight 75430 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75430/
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
flight 128836 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128836/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6d665168b0b630924a8d535316d053723998d658
baseline version:
ovmf 47f15da16053f031bcf7c
On 10/16/18 6:56 AM, Julien Grall wrote:
> Hi,
>
> On 10/16/2018 09:38 AM, Stefano Stabellini wrote:
>> xen_create_contiguous_region has now only an implementation if
>> CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
>> we do have an implementation of xen_create_contiguous
On Tue, 16 Oct 2018, Andrew Cooper wrote:
> On 16/10/18 02:34, Stefano Stabellini wrote:
> > On Mon, 15 Oct 2018, Julien Grall wrote:
> >> Hi,
> >>
> >> Please use scripts/get_maintainers.pl to CC relevant maintainers.
> >>
> >> On 15/10/2018 10:56, Stefano Stabellini wrote:
> >>> Introduce a macro
On Tue, 16 Oct 2018, Boris Ostrovsky wrote:
> On 10/16/18 6:56 AM, Julien Grall wrote:
> > Hi,
> >
> > On 10/16/2018 09:38 AM, Stefano Stabellini wrote:
> >> xen_create_contiguous_region has now only an implementation if
> >> CONFIG_XEN_PV is defined. However, on ARM we never set CONFIG_XEN_PV but
Hi Stefano,
On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
On 15/10/2018 08:25, Julien Grall wrote:
Hi,
On 10/10/2018 11:35 PM, Stefano Stabellini wrote:
On Tue, 28 Aug 2018, Julien Grall wrote:
On 11/08/18 01:01, Stefano Stabellini wrote:
#include
#include
#include
@@ -23
On 15/10/18 11:40, Wei Liu wrote:
> On Fri, Oct 12, 2018 at 08:56:22AM -0600, Jan Beulich wrote:
> On 04.10.18 at 17:43, wrote:
>>> Instead of trying to split up entry.S and compat/entry.S, simply
>>> provide some stubs for them.
>> I'm not convinced; I'd much rather see the call sites recogni
Hi,
Sorry I forgot to answer to the rest of the e-mail.
On 10/16/2018 03:39 AM, Stefano Stabellini wrote:
On 15/10/2018 08:25, Julien Grall wrote:
+ bool hwdom_access; /* HW domain gets access regardless. */
+};
+
+/*
+ * This table maps a node into a memory address.
+ * If a guest has
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not
Hi,
On 10/16/2018 07:48 AM, Stefano Stabellini wrote:
On Mon, 15 Oct 2018, Julien Grall wrote:
(Resending the e-mail using a different smtp)
On 15/10/2018 08:32, Julien Grall wrote:
Hi,
On 10/10/2018 11:49 PM, Stefano Stabellini wrote:
On Tue, 28 Aug 2018, Julien Grall wrote:
Hi Stefano,
Anthony PERARD writes ("[PATCH v5 10/15] libxl_exec: Add
libxl__spawn_initiate_failure"):
> This function can be used by user of libxl__spawn_* when they setup a
> notification other than xenstore. The parent can already report success
> via libxl__spawn_initiate_detach(), this new function can be
Anthony PERARD writes ("[PATCH v5 12/15] libxl: QEMU startup sync based on
QMP"):
> This is only activated when dm_restrict=1, as explained in the previous
> patch "libxl_dm: Pre-open QMP socket for QEMU"
...
> +static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
> +
Anthony PERARD writes ("[PATCH v5 13/15] libxl_qmp: Store advertised QEMU
version in libxl__ev_qmp"):
> This will be used in a later patch.
...
> +/* read-only when Connected */
> +struct {
> +int major;
> +int minor;
> +int micro;
> +} qemu_version;
This shoul
Anthony PERARD writes ("[PATCH v5 11/15] libxl_dm: Pre-open QMP socket for
QEMU"):
> When starting QEMU with dm_restrict=1, pre-open the QMP socket before
> exec QEMU. That socket will be usefull to findout if QEMU is ready, and
> pre-opening it means that libxl can connect to it without waiting f
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not
The P2M common code currently restricts the MMIO mapping order of any
domain with IOMMU mappings, but that is not using shared tables, to 4k.
This has been shown to have a huge performance cost when passing through
a PCI device with a very large BAR (e.g. NVIDIA P40), increasing the guest
boot time
Anthony PERARD writes ("[PATCH v5 14/15] libxl: Change
libxl__domain_suspend_device_model() to be async."):
> This create an extra step for the two call sites of the function.
...
> -int libxl__domain_suspend_device_model(libxl__gc *gc,
> +int libxl__domain_suspend_device_model(libxl__egc *egc,
>
flight 128838 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128838/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 5870a695a03af605b5bde54934ad465cb030440f
baseline version:
xtf 089f9be25f4bb445f68241
On Mon, Oct 15, 2018 at 7:14 PM Stefano Stabellini
wrote:
>
> On Mon, 15 Oct 2018, Tamas K Lengyel wrote:
> > On Mon, Oct 15, 2018 at 3:57 AM Stefano Stabellini
> > wrote:
> > >
> > > Initialize variable *access before returning it back to the caller.
> > >
> > > Signed-off-by: Stefano Stabellini
Anthony PERARD writes ("[PATCH v5 15/15] libxl: Re-implement
domain_suspend_device_model using libxl__ev_qmp"):
> The re-implementation is done because we want to be able to send the
> file description that QEMU can use to save its state. When QEMU is
> restricted, it would not be able to write to
flight 128775 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-xsm-freebsd broken
build-amd64-xen-freebsd
On Tue, Oct 16, 2018 at 03:37:16PM +, osstest service owner wrote:
> flight 128775 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/128775/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-amd64
This run is configured for baseline tests only.
flight 75431 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75431/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On Fri, Oct 12, 2018 at 09:09:28AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > --- a/xen/common/domain.c
> > +++ b/xen/common/domain.c
> > @@ -322,17 +322,34 @@ struct domain *domain_create(domid_t domid,
> > }
> >
> > /* Sort out our idea of is_{pv,hvm}_domain().
On 10/16/2018 03:41 PM, Paul Durrant wrote:
> The P2M common code currently restricts the MMIO mapping order of any
> domain with IOMMU mappings, but that is not using shared tables, to 4k.
> This has been shown to have a huge performance cost when passing through
> a PCI device with a very large B
On 09/27/2018 08:58 AM, Razvan Cojocaru wrote:
> Currently there is a subop for setting the memaccess of a page, but not
> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
> functionality.
>
> Both altp2m get/set mem access functions use the struct
> xen_hvm_altp2m_mem_access whic
On Tue, Oct 16, 2018 at 03:41:55PM +0100, Paul Durrant wrote:
> The P2M common code currently restricts the MMIO mapping order of any
> domain with IOMMU mappings, but that is not using shared tables, to 4k.
> This has been shown to have a huge performance cost when passing through
> a PCI device w
Wei Liu writes ("[PATCH] libxl: extract and save affinity maps from
hypervisor"):
> This is required to retain affinity setting across save/restore and
> migration.
Does the hypervisor or libxl invent a default affinity map at some
point ? If so that default calculation needs to be re-done for t
On 10/16/2018 05:26 PM, George Dunlap wrote:
> On 09/27/2018 08:58 AM, Razvan Cojocaru wrote:
>> Currently there is a subop for setting the memaccess of a page, but not
>> for consulting it. The new HVMOP_altp2m_get_mem_access adds this
>> functionality.
>>
>> Both altp2m get/set mem access functi
On Fri, Oct 12, 2018 at 09:16:42AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -37,6 +37,14 @@ source "arch/Kconfig"
> >
> > config PV
> > def_bool y
> > + prompt "PV support"
> > + ---help---
> > +
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 02/17] libxl: Add
"stubdomain_version" to domain_build_info."):
> Actually, with patch 04/17 you can set explicit stubdomain path, so
> stubdomain_version is only another way (redundant to
> device_model_version) to signal what protocol to comm
On Fri, Oct 12, 2018 at 08:08:19AM -0600, Jan Beulich wrote:
> >>> On 04.10.18 at 17:43, wrote:
> > The trap handlers in hypervisor need to forward events to PV guests if
> > necessary. If there is no PV guest relevant code should be excluded.
> >
> > Put code under CONFIG_PV and add ASSERT_UNREA
Marek Marczykowski-Górecki writes ("[RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> [stuff]
Thanks for this. I'm very keen on this approach and keen on getting
it upstream. Sorry for the delay reviewing it! I have been away a
lot.
> General idea is to
Marek Marczykowski-Górecki writes ("[RFC PATCH v2 01/17] libxl: fix qemu-trad
cmdline for no sdl/vnc case"):
> When qemu is running in stubdomain, any attempt to initialize vnc/sdl
> there will crash it (on failed attempt to load a keymap from a file). If
> vfb is present, all those cases are skip
Marek Marczykowski-Górecki writes ("[RFC PATCH v2 03/17] libxl: Handle Linux
stubdomain specific QEMU options."):
> From: Eric Shelton
>
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
...
> -static const char *libxl_tapif_script(libx
On Tue, Oct 16, 2018 at 05:53:02PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("[RFC PATCH v2 00/17] Add support for
> qemu-xen runnning in a Linux-based stubdomain."):
> > [stuff]
>
> Thanks for this. I'm very keen on this approach and keen on getting
> it upstream. Sorry fo
On Tue, Oct 16, 2018 at 05:43:34PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 02/17] libxl: Add
> "stubdomain_version" to domain_build_info."):
> > Actually, with patch 04/17 you can set explicit stubdomain path, so
> > stubdomain_version is only another way
On Tue, 2018-10-16 at 17:27 +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: extract and save affinity maps from
> hypervisor"):
> > This is required to retain affinity setting across save/restore and
> > migration.
>
> Does the hypervisor or libxl invent a default affinity map at some
Dario Faggioli writes ("Re: [PATCH] libxl: extract and save affinity maps from
hypervisor"):
> If on the other hand, a domain was actually explicitly specified, then
> I guess it makes sense to at least try to set it when resuming.
>
> So the point is, are we, at that time (i.e., during resume),
Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
qemu-xen runnning in a Linux-based stubdomain."):
> On Tue, Oct 16, 2018 at 05:53:02PM +0100, Ian Jackson wrote:
> > I think you may need a quoting
> > scheme, or to use nul.
>
> The main reason for this over alternative
On Tue, Oct 16, 2018 at 06:16:41PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("[RFC PATCH v2 03/17] libxl: Handle Linux
> stubdomain specific QEMU options."):
> > From: Eric Shelton
> >
> > This patch creates an appropriate command line for the QEMU instance
> > running in a
On Tue, 2018-10-16 at 18:44 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [PATCH] libxl: extract and save affinity
> maps from hypervisor"):
> > If on the other hand, a domain was actually explicitly specified,
> > then
> > I guess it makes sense to at least try to set it when resuming.
>
Hello,
I realise this is an old CPU, but I've I've encountered a weird failure
on it.
Specifically:
(XEN) CPU Vendor: Intel, Family 6 (0x6), Model 23 (0x17), Stepping 6
(raw 00010676)
[root@harpertown ~]# head /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model
flight 128840 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128840/
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 128792 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128792/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail like 127713
test-amd64-i386-xl-qemuu-debianhv
On Tue, Oct 16, 2018 at 06:52:36PM +0100, Ian Jackson wrote:
> Marek Marczykowski-Górecki writes ("Re: [RFC PATCH v2 00/17] Add support for
> qemu-xen runnning in a Linux-based stubdomain."):
> > On Tue, Oct 16, 2018 at 05:53:02PM +0100, Ian Jackson wrote:
> > > I think you may need a quoting
> >
This run is configured for baseline tests only.
flight 75433 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75433/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128807 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128807/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail REGR. vs.
128258
test-armhf-arm
xen_swiotlb_{alloc,free}_coherent() allocate/free memory by order,
but passed required size to range_straddles_page_boundary(),
when first pages are physical continuous,
range_straddles_page_boundary() returned true, then did not
exchanged memory with Xen, later on free memory, it tried to
exchange
flight 128804 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail REGR. vs.
128156
Tests which
This run is configured for baseline tests only.
flight 75435 xen-4.8-testing real [real]
http://osstest.xensource.com/osstest/logs/75435/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
We are the XCP-ng project (https://xcp-ng.org) and want to distribute
our own PV-Tools (maybe also per windows updates) so we need an extra range.
We also registered a PCI-Device:
"XCP-ng Project PCI Device for Windows Update" ->
https://pci-ids.ucw.cz/read/PC/5853/c200
Signed-off-by: Alexan
flight 128845 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128845/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 25d310d9b6187ca2e770b0b959831416441ce271
baseline version:
ovmf 6d665168b0b630924a8d5
66 matches
Mail list logo
