> -Original Message-
> From: Ian Jackson
> Sent: 17 January 2020 15:31
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> jandr...@gmail.c
On 19.01.2020 03:44, Tian, Kevin wrote:
>> From: Jan Beulich
>> Sent: Tuesday, January 7, 2020 12:39 AM
>>
>> If the hardware can handle accesses, we should allow it to do so. This
>> way we can expose EFRO to HVM guests, and "all" that's left for exposing
>> APERF/MPERF is to figure out how to ha
On 19.01.2020 11:39, Pasi Kärkkäinen wrote:
> On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
>> On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote:
>>> I have a multi-function PCI device, behind a PCI bridge, that normally
>>> I assign to a single domain. But now it fails with:
>>
On 18.01.2020 13:32, Julien Grall wrote:
> On 17/01/2020 08:33, Jan Beulich wrote:
>> On 17.01.2020 04:40, Wei Xu wrote:
>>> --- a/xen/drivers/char/ns16550.c
>>> +++ b/xen/drivers/char/ns16550.c
>>> @@ -1620,6 +1620,61 @@ DT_DEVICE_START(ns16550, "NS16550 UART",
>>> DEVICE_SERIAL)
>>> DT_DEVICE_
On 17.01.2020 20:06, Eslam Elnikety wrote:
> On 20.12.19 10:53, Jan Beulich wrote:
>> On 19.12.2019 22:08, Eslam Elnikety wrote:
>>> On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
> Decouple the microcode referencing mechanism when using GRUB to that
>
On 17.01.2020 21:06, Eslam Elnikety wrote:
> On 20.12.19 11:12, Jan Beulich wrote:
>> On 19.12.2019 23:11, Eslam Elnikety wrote:
>>> On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
> --- /dev/null
> +++ b/xen/arch/x86/microcode/Makefile
> @@ -0,0 +1
On Fri, 17 Jan 2020 at 12:59, Sergey Dyasli wrote:
>
> From: Ross Lagerwall
>
> When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
> non-power-of-two allocations are not aligned to the next power of 2 of
> the size. Therefore, handle grant copies that cross page boundaries.
>
On Mon, Jan 20, 2020 at 09:36:27AM +0100, Jan Beulich wrote:
> On 19.01.2020 11:39, Pasi Kärkkäinen wrote:
> > On Mon, Jan 06, 2020 at 02:06:14PM +0100, Jan Beulich wrote:
> >> On 04.01.2020 02:07, Marek Marczykowski-Górecki wrote:
> >>> I have a multi-function PCI device, behind a PCI bridge, tha
On 17.01.2020 17:23, Anthony PERARD wrote:
> On Thu, Jan 16, 2020 at 01:40:39PM +0100, Jan Beulich wrote:
>> On 16.01.2020 13:29, Anthony PERARD wrote:
>> Indeed, hence also my "as suggested before". I remain unconvinced
>> that is it useful to have e.g.
>>
>> CONFIG_GCC_VERSION=80300
>> CONFIG_CLA
On 18.01.2020 19:59, peter.kur...@gdata.de wrote:
> Hi,
>
> I was advised to bump this also to the devel mailing list, because the
> mentioned error message was apparently added in Kernel 4.20 (and upwards) and
> this kernel version is not broadly adopted already and therefore it is
> unlikely
On 17.01.2020 17:44, Sergey Dyasli wrote:
> Signed-off-by: Sergey Dyasli
In principle
Acked-by: Jan Beulich
But I think it would be nice to have a non-empty description, at
least to reason why the option addition is deemed useful.
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -236
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 20 January 2020 09:51
> To: Sergey Dyasli
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George Dunlap ;
> Andrew Cooper ; Doug Goldstein
> ; xen-de...@lists.xen.org; Daniel De Graaf
On 17.01.2020 17:44, Sergey Dyasli wrote:
> v2 --> v3:
> - Remove hvmloader filtering
Why? Seeing the prior discussion, how about adding XENVER_denied to
return the "denied" string, allowing components which want to filter
to know exactly what to look for? And then re-add the filtering you
had? (T
Allow to build Xen with python3.
Also, QEMU upstream (to be 4.3) now requires python >= 3.5, but that
affect only xen-unstable.
Signed-off-by: Anthony PERARD
---
ts-xen-build-prep | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 5d2
On Sun, Jan 19, 2020 at 02:36:32AM +, Tian, Kevin wrote:
> > From: Roger Pau Monné
> > Sent: Tuesday, December 31, 2019 11:30 PM
> >
> > On Mon, Dec 30, 2019 at 08:19:23PM +, osstest service owner wrote:
> > > flight 145393 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.or
On Sun, Jan 19, 2020 at 04:15:04AM +, Tian, Kevin wrote:
> > From: Roger Pau Monne
> > Sent: Wednesday, January 8, 2020 6:39 PM
> >
> > When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
> > interrupts shouldn't be injected using the virtual interrupt delivery
> > mechanism, and
On 17.01.2020 21:42, Andrew Cooper wrote:
> The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
> total, which is a limit looking to be lifted.
>
> Move l2_xenmap[] into the BSS, and adjust both the BIOS and EFI paths to fill
> it in dynamically, based on the final linked
On 17.01.2020 21:42, Andrew Cooper wrote:
> ... rather than presuming that 16M will do. On the EFI side, use
> l2e_add_flags() to reduce the code-generation overhead of using
> l2e_from_paddr() twice.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
__
On 17.01.2020 21:42, Andrew Cooper wrote:
> The trampoline relocation code uses %fs for accessing Xen, and this comes with
> an arbitrary 16M limitation. We could adjust the limit, but the boot code is
> a confusing mix of %ds/%esi-based and %fs-based accesses, and the use of %fs
> is longer to en
On 17.01.2020 21:42, Andrew Cooper wrote:
> For __page_tables_{start,end} and L3 bootmap initialisation, the logic is
> unnecesserily complicated owing to its attempt to use the LOOP instruction,
> which results in an off-by-8 memory address owing to LOOP's termination
> condition.
>
> Rewrite bot
On Mon, Jan 06, 2020 at 05:35:16PM +0100, Jan Beulich wrote:
> This largely reverts f19af2f1138e ("x86: re-order clang no integrated
> assembler tests"): Other CFLAGS setup would better happen first, in case
> any of it affects the behavior of the integrated assembler. The comment
> addition of cou
On 17.01.2020 21:42, Andrew Cooper wrote:
> All remaining users of sym_fs() can trivially be switched to using sym_esi()
> instead. This is shorter to encode and faster to execute.
>
> This removes the final uses of %fs during boot, which allows us to drop
> BOOT_FS from the trampoline GDT, which
flight 146286 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146286/
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 10 debian-hvm-install
fail REGR. vs. 146058
flight 146297 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146297/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-amd64-xl-
Recent version of QEMU will not build anymore if Python < 3.5.
That is, QEMU 4.3 not released yet.
That check would also prevent the GitLab CI from building QEMU if
python3 binary isn't present.
Signed-off-by: Anthony PERARD
---
automation/scripts/build | 4 ++--
1 file changed, 2 insertions(+)
Main reason, newer version of QEMU doesn't support python 2.x anymore.
Second main reason, python2 is EOL.
Signed-off-by: Anthony PERARD
---
Please, rerun ./autogen.sh
---
tools/configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/configure.ac b/tools/configure
Those containers have already been updated in GitLab:
- debian/stretch
- debian/stretch-i386
- debian/unstable
- debian/unstable-i386
- fedora/29
- suse/opensuse-leap
- ubuntu/bionic
- ubuntu/trusty
- ubuntu/xenial
The container debian:unstable-arm64v8 haven't been changed.
Signed-off-by: Anthony
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.python3-default-v1
Hi,
I think it's time for Xen to build with python3 by default.
The main reason for that is that QEMU upstream don't build with python 2.x
anymore, and the python bi
On Mon, Jan 20, 2020 at 11:50:50AM +, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
> br.python3-default-v1
>
> Hi,
>
> I think it's time for Xen to build with python3 by default.
>
> The main reason for
flight 146307 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146307/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Mon, Jan 06, 2020 at 05:34:45PM +0100, Jan Beulich wrote:
> With the exception of HAVE_AS_QUOTED_SYM, populate the results into a
> generated header instead of (at least once per [sub]directory) into
> CFLAGS. This results in proper rebuilds (via make dependencies) in case
> the compiler used ch
On Fri, Jan 17, 2020 at 06:12:07PM +, Ian Jackson wrote:
> There is already an identical comment for
> libxl_osevent_register_hooks.
>
> libxl_childproc_setmode's hooks parameter has the same property and
> this should be documented.
>
> Reported-by; George Dunlap
> Signed-off-by: Ian Jackso
I will enable debug logs on two hosts today to see if I can correlate the
aforementioned error message with some debug logs.
Anything I should consider to ensure that everything required is included?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.
On 20.01.2020 13:09, peter.kur...@gdata.de wrote:
> I will enable debug logs on two hosts today to see if I can correlate the
> aforementioned error message with some debug logs.
> Anything I should consider to ensure that everything required is included?
"loglvl=all guest_loglvl=all" should be p
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over drivers.
The current implementation looks at the number of initialized CRTCs
wrt vblanking. If vblanking ha
At the end of a commit, atomic helpers can generate a VBLANK event
automatically. Originally implemented for writeback connectors, the
functionality can be used by any driver and/or hardware without proper
VBLANK interrupt.
First of all, the patch updates the documentation to make this behaviour
o
As ast does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/
The new interface drm_crtc_has_vblank() return true if vblanking has
been initialized for a certain CRTC, or false otherwise. This function
will be useful for initializing CRTC state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vblank.c | 21 +
include/drm/drm_vb
As udl does not initialize vblanking, atomic helpers initialize the
value of struct drm_crtc_state.no_vblank to be true. No need to set
it from within the driver.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_modeset.c | 11 ---
1 file changed, 11 deletions(-)
diff --git
On 20.01.2020 13:04, Roger Pau Monné wrote:
> On Mon, Jan 06, 2020 at 05:34:45PM +0100, Jan Beulich wrote:
>> --- a/Config.mk
>> +++ b/Config.mk
>> @@ -151,7 +151,7 @@ endif
>> # as-insn: Check whether assembler supports an instruction.
>> # Usage: cflags-y += $(call as-insn,CC FLAGS,"insn",optio
flight 146308 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
flight 146321 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146321/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, Jan 16, 2020 at 04:00:03PM +, Igor Druzhinin wrote:
> Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
> running 32-bit PV guest inside PV shim comes with significant performance
> hit. Moreover, for SMEP in particular every time CR4.SMEP changes on context
>
From: Julien Grall
The structure domain may be bigger than a page size when lock profiling
is enabled. However, the function free_domheap_struct will only free the
first page.
This is not a security issue because struct domain can only be bigger
than a page size for lock profiling. The feature c
branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.x
On 20.01.2020 15:07, Roger Pau Monné wrote:
> On Thu, Jan 16, 2020 at 04:00:03PM +, Igor Druzhinin wrote:
>> Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
>> running 32-bit PV guest inside PV shim comes with significant performance
>> hit. Moreover, for SMEP in pa
On 20.01.2020 15:31, Julien Grall wrote:
> From: Julien Grall
>
> The structure domain may be bigger than a page size when lock profiling
> is enabled. However, the function free_domheap_struct will only free the
> first page.
>
> This is not a security issue because struct domain can only be bi
On Mon, Jan 20, 2020 at 02:31:42PM +, Julien Grall wrote:
> From: Julien Grall
>
> The structure domain may be bigger than a page size when lock profiling
> is enabled. However, the function free_domheap_struct will only free the
> first page.
>
> This is not a security issue because struct
flight 146322 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146322/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Mon, Jan 20, 2020 at 03:38:02PM +0100, Jan Beulich wrote:
> On 20.01.2020 15:07, Roger Pau Monné wrote:
> > On Thu, Jan 16, 2020 at 04:00:03PM +, Igor Druzhinin wrote:
> >> Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
> >> running 32-bit PV guest inside PV shi
When passed a non-NULL pdev, the function does an owner check when it
finds an already existing context mapping. Bridges, however, don't get
passed through to guests, and hence their owner is always going to be
Dom0, leading to the assigment of all but one of the function of multi-
function PCI dev
On 17.01.2020 10:52, Roger Pau Monne wrote:
> If the IPI destination mask matches the mask of online CPUs use the
> APIC ALLBUT destination shorthand in order to send an IPI to all CPUs
> on the system except the current one. This can only be safely used
> when no CPU hotplug or unplug operations a
On Mon, Jan 20, 2020 at 04:42:22PM +0100, Jan Beulich wrote:
> When passed a non-NULL pdev, the function does an owner check when it
> finds an already existing context mapping. Bridges, however, don't get
> passed through to guests, and hence their owner is always going to be
> Dom0, leading to th
On 17.01.2020 12:08, Roger Pau Monne wrote:
> When placing memory BARs with sizes smaller than 4K multiple memory
> BARs can end up mapped to the same guest physical address, and thus
> won't work correctly.
Thinking about it again, aren't you fixing one possible case by
breaking the opposite one:
On 20.01.2020 17:07, Roger Pau Monné wrote:
> On Mon, Jan 20, 2020 at 04:42:22PM +0100, Jan Beulich wrote:
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -1493,18 +1493,28 @@ static int domain_context_mapping(struct
>> if ( find_upstream_br
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> Trying to share these would fail anyway, better to skip them early.
>
> Signed-off-by: Tamas K Lengyel
Reviewed-by: Jan Beulich
albeit I wonder if this couldn't be further generalized by ...
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x8
On 08.01.2020 18:14, Tamas K Lengyel wrote:
> --- a/xen/arch/x86/mm/mem_sharing.c
> +++ b/xen/arch/x86/mm/mem_sharing.c
> @@ -652,19 +652,18 @@ static int page_make_sharable(struct domain *d,
> return -EBUSY;
> }
>
> -/* Change page type and count atomically */
> -if ( !get_
On Mon, Jan 20, 2020 at 05:15:22PM +0100, Jan Beulich wrote:
> On 20.01.2020 17:07, Roger Pau Monné wrote:
> > On Mon, Jan 20, 2020 at 04:42:22PM +0100, Jan Beulich wrote:
> >> --- a/xen/drivers/passthrough/vtd/iommu.c
> >> +++ b/xen/drivers/passthrough/vtd/iommu.c
> >> @@ -1493,18 +1493,28 @@ sta
On 20.01.2020 17:32, Tamas K Lengyel wrote:
> On Mon, Jan 20, 2020 at 9:23 AM Jan Beulich wrote:
>>
>> On 08.01.2020 18:14, Tamas K Lengyel wrote:
>>> Trying to share these would fail anyway, better to skip them early.
>>>
>>> Signed-off-by: Tamas K Lengyel
>>
>> Reviewed-by: Jan Beulich
>> albe
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional
On 20.01.2020 17:37, Roger Pau Monné wrote:
> On Mon, Jan 20, 2020 at 05:15:22PM +0100, Jan Beulich wrote:
>> On 20.01.2020 17:07, Roger Pau Monné wrote:
>>> On Mon, Jan 20, 2020 at 04:42:22PM +0100, Jan Beulich wrote:
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrou
On Mon, Jan 20, 2020 at 9:34 AM Jan Beulich wrote:
>
> On 08.01.2020 18:14, Tamas K Lengyel wrote:
> > --- a/xen/arch/x86/mm/mem_sharing.c
> > +++ b/xen/arch/x86/mm/mem_sharing.c
> > @@ -652,19 +652,18 @@ static int page_make_sharable(struct domain *d,
> > return -EBUSY;
> > }
> >
>
On Mon, Jan 20, 2020 at 9:23 AM Jan Beulich wrote:
>
> On 08.01.2020 18:14, Tamas K Lengyel wrote:
> > Trying to share these would fail anyway, better to skip them early.
> >
> > Signed-off-by: Tamas K Lengyel
>
> Reviewed-by: Jan Beulich
> albeit I wonder if this couldn't be further generalized
On 08.01.2020 18:24, David Woodhouse wrote:
> @@ -980,6 +1015,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> set_kexec_crash_area_size((u64)nr_pages << PAGE_SHIFT);
> kexec_reserve_area(&boot_e820);
>
> +if ( lu_bootmem_start )
> +{
> +/* XX: Check it's in
On Mon, Jan 20, 2020 at 05:41:17PM +0100, Jan Beulich wrote:
> On 20.01.2020 17:37, Roger Pau Monné wrote:
> > On Mon, Jan 20, 2020 at 05:15:22PM +0100, Jan Beulich wrote:
> >> On 20.01.2020 17:07, Roger Pau Monné wrote:
> >>> On Mon, Jan 20, 2020 at 04:42:22PM +0100, Jan Beulich wrote:
> ---
flight 146330 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146330/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, Jan 20, 2020 at 05:10:33PM +0100, Jan Beulich wrote:
> On 17.01.2020 12:08, Roger Pau Monne wrote:
> > When placing memory BARs with sizes smaller than 4K multiple memory
> > BARs can end up mapped to the same guest physical address, and thus
> > won't work correctly.
>
> Thinking about it
On Mon, 2020-01-20 at 17:58 +0100, Jan Beulich wrote:
> On 08.01.2020 18:24, David Woodhouse wrote:
> > @@ -980,6 +1015,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> > set_kexec_crash_area_size((u64)nr_pages << PAGE_SHIFT);
> > kexec_reserve_area(&boot_e820);
> >
> > +
Hi all,
I was doing some experiments on the Xen network Driver Domain using Ubuntu
18.04. I was able to see the driver domain works fine when I run it in PV
mode. However, I wasn't able to make the driver domain work when I run it in
HVM mode. I get the following error when I want my DomU to u
On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki
wrote:
>
> Add documentation based on reverse-engineered toolstack-ioemu stubdomain
> protocol.
>
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> docs/misc/stubdom.txt | 53 -
> 1 file chan
On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki
wrote:
> +
> +Limitations:
> + - PCI passthrough require permissive mode
> + - only one nic is supported
Why is only 1 nic supported? Multiple were supported previously, but
peeking ahead in the series, script=/etc/qemu-ifup is no lon
On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki
wrote:
>
> Do not prohibit anymore using stubdomain with qemu-xen.
> To help distingushing MiniOS and Linux stubdomain, add helper inline
> functions libxl__stubdomain_is_linux() and
> libxl__stubdomain_is_linux_running(). Those should be
On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
wrote:
>
> From: Eric Shelton
>
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
>
> NOTE: a number of items are not currently implemented for Linux-based
> stubdomains, such as
On Tue, Jan 14, 2020 at 9:41 PM Marek Marczykowski-Górecki
wrote:
>
> This allows using arguments with spaces, like -append, without
> nominating any special "separator" character.
>
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> Changes in v3:
> - previous version of this patch "libxl: use
On Tue, Jan 14, 2020 at 9:40 PM Marek Marczykowski-Górecki
wrote:
>
> Signed-off-by: Marek Marczykowski-Górecki
> Reviewed-by: Jason Andryuk
> ---
> docs/man/xl.cfg.5.pod.in | 23 +++
> tools/xl/xl_parse.c | 7 +++
> 2 files changed, 26 insertions(+), 4 deletions(-
On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
wrote:
>
> Let the server know when the client is connected. Otherwise server will
> notice only when client send some data.
> This change does not break existing clients, as libvchan user should
> handle spurious notifications anyway (for
On Tue, Jan 14, 2020 at 9:42 PM Marek Marczykowski-Górecki
wrote:
>
> libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
> with it needs applicable -I in CFLAGS too.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
_
On Mon, Jan 20, 2020 at 12:18 PM Roger Pau Monné wrote:
>
> On Mon, Jan 20, 2020 at 05:10:33PM +0100, Jan Beulich wrote:
> > On 17.01.2020 12:08, Roger Pau Monne wrote:
> > > When placing memory BARs with sizes smaller than 4K multiple memory
> > > BARs can end up mapped to the same guest physical
flight 146319 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146319/
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 10 debian-hvm-install
fail REGR. vs. 146058
> Empty Go strings should be converted to `nil` libxl_cpuid_policy_list;
> otherwise libxl_cpuid_parse_config gets confused.
>
> Also, libxl_cpuid_policy_list returns a weird error, not a "normal"
> libxl error; if it returns one of these non-standard errors, convert
> it to ErrorInval.
>
> Finally
> If an error is encountered deep in a complicated data structure, it's
> often difficult to tell where the error actually is. Make the error
> message from the generated toC() and fromC() structures more
> informative by tagging which field being converted encountered the
> error. This will have
Sorry I didn't catch this the first time around, but:
> diff --git a/tools/golang/xenlight/helpers.gen.go
> b/tools/golang/xenlight/helpers.gen.go
> index b9a7e828a0..889807d928 100644
> --- a/tools/golang/xenlight/helpers.gen.go
> +++ b/tools/golang/xenlight/helpers.gen.go
> @@ -623,12 +623,14
> Commit 871e51d2d4 changed the sign on the xenlight error types (making
> the values negative, same as the C-generated constants), but failed to
> flip the sign in the Error() string function. The result is that
> ErrorNonspecific.String() prints "libxl error: 1" rather than the
> human-readable
> The other option would be to expose the XTL logging levels and let the
> caller set them somehow.
I think this is fine for now.
For the future, I like using the "functional option" pattern for this
sort of thing. That way, if a user wanted to set a non-default log
level, they could do:
ctx, err
> If libxl_ctx_alloc() returns an error, we need to destroy the logger
> that we made.
>
> Restructure the Close() method such that it checks for each resource
> to be freed and then frees it. This allows Close() to be come
> idempotent, as well as to be a useful clean-up to a partially-created
>
On 20.01.20 09:42, Jan Beulich wrote:
On 17.01.2020 20:06, Eslam Elnikety wrote:
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism when
> From: Jan Beulich
> Sent: Monday, January 20, 2020 4:33 PM
>
> On 19.01.2020 03:44, Tian, Kevin wrote:
> >> From: Jan Beulich
> >> Sent: Tuesday, January 7, 2020 12:39 AM
> >>
> >> If the hardware can handle accesses, we should allow it to do so. This
> >> way we can expose EFRO to HVM guests,
Hi Jan, Julien,
On 2020/1/20 16:38, Jan Beulich wrote:
On 18.01.2020 13:32, Julien Grall wrote:
On 17/01/2020 08:33, Jan Beulich wrote:
On 17.01.2020 04:40, Wei Xu wrote:
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -1620,6 +1620,61 @@ DT_DEVICE_START(ns16550, "NS16550
> From: Roger Pau Monné
> Sent: Monday, January 20, 2020 6:19 PM
>
> On Sun, Jan 19, 2020 at 04:15:04AM +, Tian, Kevin wrote:
> > > From: Roger Pau Monne
> > > Sent: Wednesday, January 8, 2020 6:39 PM
> > >
> > > When doing a virtual vmexit (ie: a vmexit handled by the L1 VMM)
> > > interrup
Parse the ACPI SPCR table and initialize the 16550 compatible serial port
for ARM only. Currently we only support one UART on ARM. Some fields like
PCI, flow control and so on we do not care yet on ARM are ignored.
Signed-off-by: Wei Xu
---
Changes in v2:
- improve commit message
- remove the sp
flight 146336 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146336/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146324 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-amd64-xl-
flight 146331 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146331/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
test-amd64-amd64-xl-qemuu
> From: Jan Beulich
> Sent: Monday, January 20, 2020 11:42 PM
>
> When passed a non-NULL pdev, the function does an owner check when it
> finds an already existing context mapping. Bridges, however, don't get
> passed through to guests, and hence their owner is always going to be
> Dom0, leading
flight 146343 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146343/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
flight 146344 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146344/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
96 matches
Mail list logo
