flight 138579 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138579/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138492 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138492/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51f7a3e6c5192d3f9a0fa63b0b5617c151180ad7
baseline version:
ovmf
On Wed, Jun 26, 2019 at 06:36:15PM +0100, Andrew Cooper wrote:
> Clang observes:
>
> tools/kconfig/conf.c:77:10:
> warning: format string is not a string literal (potentially insecure)
> [-Wformat-security]
> printf(_("aborted!\n\n"));
>
flight 138540 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138540/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 14e63f898b16382f4577cfea211a7fb5ad7983e9
baseline version:
freebsd
flight 138576 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138576/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138468 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 138148
Tests which
flight 138575 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138574 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138574/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138570 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138454 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are
flight 138461 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138461/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 138327
test-armhf-armhf-libvirt-raw 13
flight 138568 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138568/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 6/26/19 8:29 PM, Stefano Stabellini wrote:
> > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > At the moment BSS is zeroed before the MMU and D-Cache is turned on.
> > > In other words, the cache will be bypassed when zeroing the BSS
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-armhf
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:
flight 138566 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138566/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
On 26/06/2019 21:39, Julien Grall wrote:
> On 6/26/19 9:25 PM, Stefano Stabellini wrote:
>> On Mon, 10 Jun 2019, Julien Grall wrote:
>>> The ID map may clash with other parts of the Xen virtual memory layout.
>>> At the moment, Xen is handling the clash by only creating a mapping to
>>> the
Hi Stefano,
On 6/26/19 9:25 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
The ID map may clash with other parts of the Xen virtual memory layout.
At the moment, Xen is handling the clash by only creating a mapping to
the runtime virtual address before enabling the MMU.
On Mon, 10 Jun 2019, Julien Grall wrote:
> The ID map may clash with other parts of the Xen virtual memory layout.
> At the moment, Xen is handling the clash by only creating a mapping to
> the runtime virtual address before enabling the MMU.
>
> The rest of the mappings (such as the fixmap) will
Hi Stefano,
On 6/26/19 8:12 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
Boot CPU and secondary CPUs will use different entry point to C code. At
the moment, the decision on which entry to use is taken within launch().
In order to avoid a branch for the decision and
Hi Stefano,
On 6/26/19 8:29 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
At the moment BSS is zeroed before the MMU and D-Cache is turned on.
In other words, the cache will be bypassed when zeroing the BSS section.
Per the Image protocol [1], the state of the cache
flight 138563 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138563/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
Hi Stefano,
On 6/26/19 8:01 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
At the moment, the fixmap table is only hooked when earlyprintk is used.
This is fine today because in C land, the fixmap is not used by anyone
until the the boot CPU is switching to the runtime
On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment BSS is zeroed before the MMU and D-Cache is turned on.
> In other words, the cache will be bypassed when zeroing the BSS section.
>
> Per the Image protocol [1], the state of the cache for BSS region is not
> known because it is not part of
Hi,
On 6/26/19 7:51 PM, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
setup_fixmap() will setup the fixmap in the boot page tables in order to
use earlyprintk and also update the register x23 holding the address to
the UART.
However, secondary CPUs are switching to the
Hi Stefano,
On 6/26/19 7:32 PM, Stefano Stabellini wrote:
On Wed, 26 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 26/06/2019 16:27, Stefano Stabellini wrote:
On Wed, 26 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 26/06/2019 00:59, Stefano Stabellini wrote:
On Tue, 25 Jun 2019, Stefano
On 26/06/2019, 18:44, "Stefano Stabellini" wrote:
On Wed, 26 Jun 2019, Rich Persaud wrote:
> > On Jun 26, 2019, at 06:45, Lars Kurth wrote:
> >
> >
> >
> > On 25/06/2019, 21:27, "Rich Persaud" wrote:
> >
> >> On Jun 25, 2019, at 16:17, Julien Grall
On Mon, 10 Jun 2019, Julien Grall wrote:
> Boot CPU and secondary CPUs will use different entry point to C code. At
> the moment, the decision on which entry to use is taken within launch().
>
> In order to avoid a branch for the decision and make the code clearer,
> launch() is reworked to take
From: Sergey Dyasli
Otherwise hvm_set_cr0() will check the wrong CR4 bits (L1 instead of L2
and vice-versa).
Signed-off-by: Sergey Dyasli
Reviewed-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Jun Nakajima
CC: Kevin Tian
I found this patch languishing in the
On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment, the fixmap table is only hooked when earlyprintk is used.
> This is fine today because in C land, the fixmap is not used by anyone
> until the the boot CPU is switching to the runtime page-tables.
>
> In the future, the boot CPU will not
On Mon, 10 Jun 2019, Julien Grall wrote:
> At the moment, the fixmap table is only hooked when earlyprintk is used.
> This is fine today because in C land, the fixmap is not used by anyone
> until the the boot CPU is switching to the runtime page-tables.
>
> In the future, the boot CPU will not
On Mon, 10 Jun 2019, Julien Grall wrote:
> setup_fixmap() will setup the fixmap in the boot page tables in order to
> use earlyprintk and also update the register x23 holding the address to
> the UART.
>
> However, secondary CPUs are switching to the runtime page tables before
> using the
flight 138560 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 26/06/2019 16:27, Stefano Stabellini wrote:
> > On Wed, 26 Jun 2019, Julien Grall wrote:
> > > Hi Stefano,
> > >
> > > On 26/06/2019 00:59, Stefano Stabellini wrote:
> > > > On Tue, 25 Jun 2019, Stefano Stabellini wrote:
> > > > > On
On 26.06.19 19:19, Anthony PERARD wrote:
> On Wed, Jun 26, 2019 at 06:48:50PM +0200, Max Reitz wrote:
>> On 09.04.19 18:40, Paul Durrant wrote:
>>> A recent Xen commit [1] clarified the semantics of sector based quantities
>>> used in the blkif protocol such that it is now safe to create a
On Wed, 26 Jun 2019, Rich Persaud wrote:
> > On Jun 26, 2019, at 06:45, Lars Kurth wrote:
> >
> >
> >
> > On 25/06/2019, 21:27, "Rich Persaud" wrote:
> >
> >> On Jun 25, 2019, at 16:17, Julien Grall wrote:
> >>
> >> Hi Rich,
> >>
> >> On 6/25/19 8:38 PM, Rich Persaud wrote:
> On Jun
Clang observes:
tools/kconfig/conf.c:77:10:
warning: format string is not a string literal (potentially insecure)
[-Wformat-security]
printf(_("aborted!\n\n"));
^
And it is absolutely correct. gettext() can easily return a string with
flight 138559 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138559/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
On Wed, Jun 26, 2019 at 06:48:50PM +0200, Max Reitz wrote:
> On 09.04.19 18:40, Paul Durrant wrote:
> > A recent Xen commit [1] clarified the semantics of sector based quantities
> > used in the blkif protocol such that it is now safe to create a xen-block
> > device with a logical_block_size !=
On 09.04.19 18:40, Paul Durrant wrote:
> A recent Xen commit [1] clarified the semantics of sector based quantities
> used in the blkif protocol such that it is now safe to create a xen-block
> device with a logical_block_size != 512, as long as the device only
> connects to a frontend advertizing
flight 138457 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138457/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 137600
build-amd64-xsm
flight 138557 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138557/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
CC George
On Wed, Jun 26, 2019 at 12:27:32PM +0200, Nicolas Belouin wrote:
> The Go bindings for libxl miss functions from libxl_utils, lets start
> with the simple libxl_domid_to_name and its counterpart
> libxl_name_to_domid.
>
> Signed-off-by: Nicolas Belouin
> ---
>
On 26/06/2019 16:20, Roger Pau Monné wrote:
> On Wed, Jun 26, 2019 at 08:45:27AM -0600, Jan Beulich wrote:
> On 26.06.19 at 15:55, wrote:
>>> Kconfig makes heavy use of non-literals as format strings, disable
>>> compiler warnings since this is expected usage.
>> I've never seen any with any
Hi Julien,
Thank you for information provided.
Per the binding, domU1 node should contain the properties
#address-cells and #size-cells.
Adding xen-devel to CC.
Thanks
On Wed, Jun 26, 2019 at 6:42 PM Julien Grall wrote:
>
>
>
> On 26/06/2019 16:21, Viktor Mitin wrote:
> > Hi All,
>
> Hi,
>
>
> On Jun 26, 2019, at 06:45, Lars Kurth wrote:
>
>
>
> On 25/06/2019, 21:27, "Rich Persaud" wrote:
>
>> On Jun 25, 2019, at 16:17, Julien Grall wrote:
>>
>> Hi Rich,
>>
>> On 6/25/19 8:38 PM, Rich Persaud wrote:
On Jun 25, 2019, at 12:36, Lars Kurth wrote:
Hi all:
Hi Stefano,
On 26/06/2019 16:27, Stefano Stabellini wrote:
On Wed, 26 Jun 2019, Julien Grall wrote:
Hi Stefano,
On 26/06/2019 00:59, Stefano Stabellini wrote:
On Tue, 25 Jun 2019, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
The current implementation of the macro
On Wed, 26 Jun 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 26/06/2019 00:59, Stefano Stabellini wrote:
> > On Tue, 25 Jun 2019, Stefano Stabellini wrote:
> > > On Mon, 10 Jun 2019, Julien Grall wrote:
> > > > > The current implementation of the macro PRINT will clobber x30/lr.
> > > > > This
On Wed, Jun 26, 2019 at 08:45:27AM -0600, Jan Beulich wrote:
> >>> On 26.06.19 at 15:55, wrote:
> > Kconfig makes heavy use of non-literals as format strings, disable
> > compiler warnings since this is expected usage.
>
> I've never seen any with any version of gcc - are there more
> aspects to
On Wed, 26 Jun 2019, Juergen Gross wrote:
> On 26.06.19 14:21, Chao Gao wrote:
> > On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
> > > On 24.06.19 20:47, Stefano Stabellini wrote:
> > > > + xen-devel
> > > >
> > > > On Mon, 24 Jun 2019, Stefano Stabellini wrote:
> > > > > Hi all,
flight 138555 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138555/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138426 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138426/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-migrupgrade 22 guest-migrate/src_host/dst_host fail REGR. vs.
127792
>>> On 26.06.19 at 15:55, wrote:
> Kconfig makes heavy use of non-literals as format strings, disable
> compiler warnings since this is expected usage.
I've never seen any with any version of gcc - are there more
aspects to be mentioned here?
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Doug
On 26.06.19 16:34, Chao Gao wrote:
On Wed, Jun 26, 2019 at 03:36:35PM +0200, Juergen Gross wrote:
On 26.06.19 14:21, Chao Gao wrote:
On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
On 24.06.19 20:47, Stefano Stabellini wrote:
+ xen-devel
On Mon, 24 Jun 2019, Stefano
On Wed, Jun 26, 2019 at 03:36:35PM +0200, Juergen Gross wrote:
>On 26.06.19 14:21, Chao Gao wrote:
>>On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
>>>On 24.06.19 20:47, Stefano Stabellini wrote:
+ xen-devel
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
>Hi all,
flight 138550 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138550/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
Hi all,
I have been using a probably a fairly old list of people to CC on mail related
to community calls. If you received this mail and don’t want to be on the CC
list, please remove your name and e-mail address from the list in
https://cryptpad.fr/pad/#/2/pad/edit/D9vGzihPxxAOe6RFPz0sRCf+/
and instead export them from the top-level Xen makefile.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/Makefile | 10 +-
Kconfig makes heavy use of non-literals as format strings, disable
compiler warnings since this is expected usage.
Signed-off-by: Roger Pau Monné
---
Cc: Doug Goldstein
---
xen/tools/kconfig/Makefile.kconfig | 5 +
1 file changed, 5 insertions(+)
diff --git
Infer the values of HOST{CC/CXX} from CC/CXX if unset, do this in
StdGNU.mk, together with the rest of the toolchain variables.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano
Hello,
The following fixes arise from the travis-ci fallout caused by
b41666f2c1 ('config: don't hardcode toolchain binaries'). First patches
aim to simplify and group together the place where toolchain binaries to
be used by the build system. Last patch changes the travis-ci build
script to
After b41666f2c1 Xen no longer overwrites the names of the build
toolchain utilities required during the build process, and instead
uses the values from the environment.
In that case, if the user wants to define CC or other variables to
point to specific toolchain utilities to use it must also
Include config/$(OS).mk which contains the default values for the
toolchain variables. This removes the need to pass HOST{CC/CXX} as
parameters from the high level make target.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien
On Wed, 26 Jun 2019, Juergen Gross wrote:
> On 24.06.19 14:02, Zhenzhong Duan wrote:
> > This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
> >
> > Instead we use an unified parameter 'nopv' for all the hypervisor
> > platforms.
> >
> > Signed-off-by: Zhenzhong Duan
> > Cc: Boris
After a reboot of a guest only the first pci device configuration will
be retrieved from Xenstore resulting in loss of any further assigned
passed through pci devices.
The main reason is that all passed through pci devices reside under a
common root device "0" in Xenstore. So when the device list
On 26.06.19 14:21, Chao Gao wrote:
On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
On 24.06.19 20:47, Stefano Stabellini wrote:
+ xen-devel
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
Hi all,
I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with
On 04/06/2019 13:15, Jan Beulich wrote:
> For find_iommu_for_device() to consistently (independent of ACPI tables)
> return NULL for the PCI devices corresponding to IOMMUs, make sure
> IOMMUs don't get mapped to themselves by ivrs_mappings[].
>
> While amd_iommu_add_device() won't be called for
On Wed, Jun 26, 2019 at 08:17:50AM +0200, Juergen Gross wrote:
>On 24.06.19 20:47, Stefano Stabellini wrote:
>>+ xen-devel
>>
>>On Mon, 24 Jun 2019, Stefano Stabellini wrote:
>>>Hi all,
>>>
>>>I might have found a bug with PCI passthrough to a Linux HVM guest on
>>>x86 with Xen 4.12. It is not
flight 138547 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138547/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138418 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138418/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-xl-arndale 1
Looks good to me
> There are a few places in include/public/arch-arm.h that are still
> suffixing immediate with ULL instead of using xen_mk_ullong.
>
> The latter allows a consumer to easily tweak the header if ULL is not
> supported.
>
> So switch the remaining users of ULL to xen_mk_ullong.
Hi Stefano,
On 26/06/2019 02:03, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
Document the behavior and the main registers usage within enable_mmu().
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 7 +++
1 file changed, 7 insertions(+)
diff --git
Hi Stefano,
On 26/06/2019 02:03, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
Adjust the coding style used in the comments within create_pages_tables()
Lastly, document the behavior and the main registers usage within the
function. Note that x25 is now only used within
Hi,
Gentle ping.
Cheers,
On 03/06/2019 17:08, Julien Grall wrote:
There are a few places in include/public/arch-arm.h that are still
suffixing immediate with ULL instead of using xen_mk_ullong.
The latter allows a consumer to easily tweak the header if ULL is not
supported.
So switch the
We want those other jobs to finish so that we can include the time
they took, and the fact that they completed, in our calculations.
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
On 25/06/2019, 21:27, "Rich Persaud" wrote:
> On Jun 25, 2019, at 16:17, Julien Grall wrote:
>
> Hi Rich,
>
> On 6/25/19 8:38 PM, Rich Persaud wrote:
>>> On Jun 25, 2019, at 12:36, Lars Kurth wrote:
>>>
>>> Hi all:
>>> please add your agenda items. I
Hi,
It looks like I forgot to CC Stefano on this one.
Cheers,
On 06/06/2019 18:10, Julien Grall wrote:
Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.
However, the structure is only needed
Gentle ping.
Cheers,
On 02/06/2019 11:26, Julien Grall wrote:
While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state.
For host interrupt (i.e routed to Xen), the deactivation of the
interrupt is done at
Hi Stefano,
On 26/06/2019 02:01, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
Adjust the coding style used in the comments within cpu_init(). Take the
opportunity to alter the early print to match the function name.
Lastly, document the behavior and the main registers
From: Oleksandr Tyshchenko
The purpose of this patch is to add IPMMU-VMSA support to Xen on ARM.
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please
The Go bindings for libxl miss functions from libxl_utils, lets start
with the simple libxl_domid_to_name and its counterpart
libxl_name_to_domid.
Signed-off-by: Nicolas Belouin
---
tools/golang/xenlight/xenlight_utils.go | 61 +
1 file changed, 61 insertions(+)
create
flight 138542 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138542/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
From: Oleksandr Tyshchenko
The IPMMU-VMSA is VMSA-compatible I/O Memory Management Unit (IOMMU)
which provides address translation and access protection functionalities
to processing units and interconnect networks.
Please note, current driver is supposed to work only with newest
Gen3 SoCs
flight 138539 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138539/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 85fd4f7a09d8aaa783932b8c15b80ddaff0a174d
baseline version:
xen
Jan Beulich writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
> On 25.06.19 at 17:53, wrote:
> > Indeed, precisely. Are happy with me doing a force push now ?
>
> I think so, yes.
Now done. I have un-stopped 4.6 and 4.7. (I don't expect 4.6 to do
anything.)
Ian.
On 24.06.19 14:02, Zhenzhong Duan wrote:
This reverts commit 8d693b911bb9c57009c24cb1772d205b84c7985c.
Instead we use an unified parameter 'nopv' for all the hypervisor
platforms.
Signed-off-by: Zhenzhong Duan
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
On 24.06.19 14:02, Zhenzhong Duan wrote:
In virtualization environment, PV extensions (drivers, interrupts,
timers, etc) are enabled in the majority of use cases which is the
best option.
However, in some cases (kexec not fully working, benchmarking)
we want to disable PV extensions. As such
flight 138538 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138538/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
Hi Stefano,
On 26/06/2019 02:01, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
On secondary CPUs, zero_bss() will be a NOP because BSS only need to be
zeroed once at boot. So the call in the secondary CPUs path can be
removed. It also means that x26 does not need to set
Hi Stefano,
On 26/06/2019 02:00, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
The boot code is currently quite difficult to go through because of the
lack of documentation and a number of indirection to avoid executing
some path in either the boot CPU or secondary CPUs.
Hi Stefano,
On 26/06/2019 01:09, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
At the moment, the user should save x30/lr if it cares about it.
Follow-up patches will introduce more use of putn in place where lr
should be preserved.
Furthermore, any user of putn should
Hi Stefano,
On 26/06/2019 01:01, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
After the recent rework, the CPUID is only used at the very beginning of
the secondary CPUs boot path. So there is no need to "reserve" x24 for
he CPUID.
If you are going to resend the series
Hi Stefano,
On 26/06/2019 00:59, Stefano Stabellini wrote:
On Tue, 25 Jun 2019, Stefano Stabellini wrote:
On Mon, 10 Jun 2019, Julien Grall wrote:
The current implementation of the macro PRINT will clobber x30/lr. This
means the user should save lr if it cares about it.
By x30/lr, do you
On 26.06.19 10:56, Zhenzhong Duan wrote:
On 2019/6/25 20:31, Juergen Gross wrote:
On 24.06.19 14:02, Zhenzhong Duan wrote:
PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.
In order for nopv parameter to take effect for HVM guest, we need to
On 2019/6/25 20:31, Juergen Gross wrote:
On 24.06.19 14:02, Zhenzhong Duan wrote:
PVH guest needs PV extentions to work, so nopv parameter is ignored
for PVH but not for HVM guest.
In order for nopv parameter to take effect for HVM guest, we need to
distinguish between PVH and HVM guest early
>>> On 25.06.19 at 17:53, wrote:
> Jan Beulich writes ("Re: [xen-4.6-testing test] 138333: regressions - FAIL"):
>> I've taken a look. The guests now triple fault during BIOS initialization:
>
> Thanks. Hrm.
>
>> I wouldn't be surprised if the rombios build is broken - did you happen
>> to
flight 138537 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138537/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138531 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138531/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 138424
flight 138414 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/138414/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
On 24.06.19 20:47, Stefano Stabellini wrote:
+ xen-devel
On Mon, 24 Jun 2019, Stefano Stabellini wrote:
Hi all,
I might have found a bug with PCI passthrough to a Linux HVM guest on
x86 with Xen 4.12. It is not easy for me to get access, and especially
change components, on this particular
99 matches
Mail list logo
