flight 124180 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124180/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 47 xtf/test-hvm64-fpu-exception-emulation fail REGR.
vs. 124043
test-x
On Thu, Jun 14, 2018 at 9:33 PM, Philippe Mathieu-Daudé wrote:
> On 06/14/2018 04:17 PM, John Snow wrote:
>> On 06/14/2018 12:44 PM, Stefan Hajnoczi wrote:
>>> Determining the size of a field is useful when you don't have a struct
>>> variable handy. Open-coding this is ugly.
>>>
>>> This patch a
Adding Daniel Kiper.
On Wed, Jun 13, 2018 at 02:09:45AM +0300, Kristaps Čivkulis wrote:
> Hello,
>
> I am implementing Multiboot2 support for FreeBSD loader to load Xen
> kernel. Currently I pass EFI 64-bit system table pointer tag, EFI boot
> services not terminated tag, EFI 64-bit image handle
flight 124184 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124184/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124058
version targeted for testi
flight 124188 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124188/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 123814
build-i386-libvirt
As both XenRT and osstest have found, the XSA-267 patches overlooked a
special case in HVM insn emulation. While looking into this I've also noticed
an omission in the sibling function to the one needing to be changed. At
least patch 1 should be strongly considered for 4.11; patch 2 will need
backp
In fully eager mode we must not clear fpu_dirtied, set CR0.TS, or invoke
the fpu_leave() hook. Instead do what the mode's name says: Restore
state right away.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2139,13 +2139,20 @@ static void hvmemul_
My original way of thinking here was that this would be set anyway at
the point state gets reloaded after the adjustments hvmemul_put_fpu()
does, but the flag should already be set before that - after all the
guest may never again touch the FPU before e.g. getting migrated/saved.
Signed-off-by: Ja
On 15/06/18 09:47, Jan Beulich wrote:
> As both XenRT and osstest have found, the XSA-267 patches overlooked a
> special case in HVM insn emulation. While looking into this I've also noticed
> an omission in the sibling function to the one needing to be changed. At
> least patch 1 should be strongl
On 15/06/18 10:47, Jan Beulich wrote:
> As both XenRT and osstest have found, the XSA-267 patches overlooked a
> special case in HVM insn emulation. While looking into this I've also noticed
> an omission in the sibling function to the one needing to be changed. At
> least patch 1 should be strongl
flight 124181 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124181/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw 5 host-ping-check-native fail REGR. vs. 123389
test-xtf-amd64
From: Oleksandr Andrushchenko
Dan Carpenter has reported that there is the following static checker
warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
315
316 if (!IS_ERR(sgt
>>> On 15.06.18 at 11:27, wrote:
> On 15/06/18 09:47, Jan Beulich wrote:
>> As both XenRT and osstest have found, the XSA-267 patches overlooked a
>> special case in HVM insn emulation. While looking into this I've also
> noticed
>> an omission in the sibling function to the one needing to be cha
On 5 June 2018 at 17:55, Anthony PERARD wrote:
> On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote:
>> The xen pci_assign_dev_load_option_rom() currently creates a RAM
>> memory region with memory_region_init_ram_nomigrate(), and then
>> manually registers it with vmstate_register_ram(
From: Oleksandr Grytsov
This patch set adds PV sound device support to xl.cfg and xl.
See sndif.h for protocol implementation details.
Changes since v2:
* address comments
* rename libxl_vsnd_stream.id -> libxl_vsnd_stream.unique_id
* use XENSND_FIELD_... defines in xl_parse.c and xl_vsnd.c
On Fri, Jun 15, 2018 at 10:06:15AM +0200, Roger Pau Monné wrote:
> Adding Daniel Kiper.
>
> On Wed, Jun 13, 2018 at 02:09:45AM +0300, Kristaps Čivkulis wrote:
> > Hello,
> >
> > I am implementing Multiboot2 support for FreeBSD loader to load Xen
> > kernel. Currently I pass EFI 64-bit system table
From: Oleksandr Grytsov
Add getting vsnd list and info API
Signed-off-by: Oleksandr Grytsov
---
tools/libxl/libxl.h | 10 +
tools/libxl/libxl_types.idl | 19 ++
tools/libxl/libxl_utils.h | 3 +
tools/libxl/libxl_vsnd.c| 365 +++-
4 files change
From: Oleksandr Grytsov
Add config parser for virtual sound devices
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/xl/xl_parse.c | 246
tools/xl/xl_parse.h | 1 +
2 files changed, 247 insertions(+)
diff --git a/tools/xl/xl_parse.c
From: Oleksandr Grytsov
Add CLI commands to attach, detach and list virtual sound devices
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 3 +
tools/xl/xl_cmdtable.c | 15 +++
tools/xl/xl_vsnd.c | 206
From: Oleksandr Grytsov
Add PV sound device described in sndif.h
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.h | 14 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_internal.h
From: Oleksandr Grytsov
Update documentation with virtual sound device
Signed-off-by: Oleksandr Grytsov
Acked-by: Wei Liu
---
docs/man/xl.cfg.pod.5.in | 149 +++
docs/man/xl.pod.1.in | 30
2 files changed, 179 insertions(+)
diff --git a/docs/
Roger Pau Monné writes ("[osstest] add FreeBSD flight"):
> I've run a test flight of my FreeBSD osstest series today, the flight
> shows all green:
>
> http://logs.test-lab.xenproject.org/osstest/logs/124163/
>
> The series can be found at:
>
> git://xenbits.xen.org/people/royger/osstest.git fre
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 124214 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124214/
Failures and p
Ian Jackson writes ("Re: [osstest] add FreeBSD flight"):
> We are discussing this on IRC. Meanwhile I have unblessed 124214.
11:52 Diziet: I've managed to build new images in
http://logs.test-lab.xenproject.org/osstest/logs/124163/ maybe
those will have the right
Ian Jackson writes ("Re: [osstest] add FreeBSD flight"):
> Thanks. It LGTM. I have rebased it again and put it in
> ~osstest/branches/for-freebsd-master.git#master and am now running an
> instance of the cron job run (with --real, ie as if actually run from
> cron).
This did not work,
Subject
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.17 next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
flight 74872 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74872/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like
74806
baseline version:
fl
flight 124213 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124213/
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 06/14/2018 07:34 PM, Zhouyang Jia wrote:
> When xenbus_printf fails, the lack of error-handling code may
> cause unexpected results.
>
> This patch adds error-handling code after calling xenbus_printf.
>
> Signed-off-by: Zhouyang Jia
Reviewed-by: Boris Ostrovsky
(I wasn't asking you to use x
For passing arbitrary data from user land to the Xen hypervisor the
Xen tools today are using mlock()ed buffers. Unfortunately the kernel
might change access rights of such buffers for brief periods of time
e.g. for page migration or compaction, leading to access faults in the
hypervisor, as the hy
A hypercall issued via the privcmd driver can very rarely return
-EFAULT even if the hypercall buffers are locked in memory. This
happens for hypercall buffers in user memory when the Linux kernel
is doing memory scans e.g. for page migration or compaction.
Retry the getpageframeinfo3 hypercall up
Instead of using anonymous memory for hypercall buffers which is then
locked into memory, use the hypercall buffer device of the Linux
privcmd driver if available.
This has the advantage of needing just a single mmap() for allocating
the buffer and page migration or compaction can't make the buffe
On Linux systems hypercall buffers in user memory are allocated with
MAP_LOCKED attribute. Unfortunately that doesn't mean that the buffer
will always be accessible by the hypervisor, as the kernel might set
the PTE for the buffer to invalid or read only for short periods of
time, e.g. due to page
Add a new function to query whether hypercall buffers are always safe
to access by the hypervisor or might result in EFAULT.
Signed-off-by: Juergen Gross
---
tools/libs/call/Makefile | 2 +-
tools/libs/call/freebsd.c | 5 +
tools/libs/call/include/xencall.h | 7 +++
tool
Hello. Some update on my 4.11rc6 tests. In brief, Linux guest
migration works fine. Some issues with NetBSD guests' migrations but
this is not necessarily related to 4.11rc6. I am rather addressing this
to the port-xen netbsd mailing-list.
In detail, I am maintaining a farm of 4 XEN hosts runn
>>> On 15.06.18 at 15:26, wrote:
> Add a new function to query whether hypercall buffers are always safe
> to access by the hypervisor or might result in EFAULT.
>
> Signed-off-by: Juergen Gross
> ---
> tools/libs/call/Makefile | 2 +-
> tools/libs/call/freebsd.c | 5 +
> t
On 15/06/18 14:17, Juergen Gross wrote:
> +MODULE_LICENSE("GPL");
> +
> +static int limit = 64;
> +module_param(limit, int, 0644);
> +MODULE_PARM_DESC(limit, "Maximum number of pages that may be allocated by "
> + "the privcmd-buf device per open file");
I have a feeling that,
On 15/06/18 16:06, Jan Beulich wrote:
On 15.06.18 at 15:26, wrote:
>> Add a new function to query whether hypercall buffers are always safe
>> to access by the hypervisor or might result in EFAULT.
>>
>> Signed-off-by: Juergen Gross
>> ---
>> tools/libs/call/Makefile | 2 +-
>> too
>>> On 15.06.18 at 15:17, wrote:
> --- /dev/null
> +++ b/drivers/xen/privcmd-buf.c
> @@ -0,0 +1,216 @@
> +// SPDX-License-Identifier: GPL-2.0 OR MIT
> +
> +/**
> + * privcmd-buf.c
> + *
> + * Mmap of hypercall buffers.
> +
On 15/06/18 16:15, Andrew Cooper wrote:
> On 15/06/18 14:17, Juergen Gross wrote:
>> +MODULE_LICENSE("GPL");
>> +
>> +static int limit = 64;
>> +module_param(limit, int, 0644);
>> +MODULE_PARM_DESC(limit, "Maximum number of pages that may be allocated by "
>> +"the privcmd-buf d
On Fri, Jun 15, 2018 at 11:06:47AM +0100, Peter Maydell wrote:
> On 5 June 2018 at 17:55, Anthony PERARD wrote:
> > On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote:
> >> The xen pci_assign_dev_load_option_rom() currently creates a RAM
> >> memory region with memory_region_init_ram_no
On 06/15/2018 09:17 AM, Juergen Gross wrote:
> +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct privcmd_buf_private *file_priv = file->private_data;
> + struct privcmd_buf_vma_private *vma_priv;
> + unsigned int count = vma_pages(vma);
> +
Juergen Gross writes ("[PATCH 1/3] tools/libxencall: use hypercall buffer
device if available"):
> Instead of using anonymous memory for hypercall buffers which is then
> locked into memory, use the hypercall buffer device of the Linux
> privcmd driver if available.
>
> This has the advantage of
Juergen Gross writes ("[PATCH 2/3] tools/libxencalls: add new function to query
hypercall buffer safety"):
> Add a new function to query whether hypercall buffers are always safe
> to access by the hypervisor or might result in EFAULT.
Acked-by: Ian Jackson
_
Juergen Gross writes ("[PATCH 3/3] tools/libxc: retry hypercall in case of
EFAULT"):
> A hypercall issued via the privcmd driver can very rarely return
> -EFAULT even if the hypercall buffers are locked in memory. This
> happens for hypercall buffers in user memory when the Linux kernel
> is doing
On 15/06/18 14:26, Juergen Gross wrote:
> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> index 03bc9a7776..18add80232 100644
> --- a/tools/libxc/xc_private.h
> +++ b/tools/libxc/xc_private.h
> @@ -254,9 +254,12 @@ out1:
> return ret;
> }
>
> -static inline int do_domctl(
flight 124186 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124186/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. vs.
123091
test-ar
On Thu, Jun 14, 2018 at 08:33:17AM -0600, Jan Beulich wrote:
> > So far I've not been able to make Xen panic with the new xen kernel.
> > Attached is a log of the serial console, in case you notice something.
>
> None of the printk()s replacing ASSERT()s have triggered, so nothing
> interesting to
>>> On 08.06.18 at 17:07, wrote:
> Instead of the stale value inside the periodic_time struct.
I think this wants its title changed, because ...
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -445,8 +445,8 @@ void create_periodic_time(
> uint64_t period, uint8_t irq, tim
>>> On 08.06.18 at 17:07, wrote:
> The value written by the guest must be valid according to the mask
> provided in the interrupt routing capabilities register. If the
> interrupt is not valid set it to the first valid IRQ in the
> capabilities field if the timer is enabled, else just clear the fi
>>> On 08.06.18 at 17:07, wrote:
> No functional change.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 15/06/18 16:35, Jan Beulich wrote:
On 15.06.18 at 15:17, wrote:
>> --- /dev/null
>> +++ b/drivers/xen/privcmd-buf.c
>> @@ -0,0 +1,216 @@
>> +// SPDX-License-Identifier: GPL-2.0 OR MIT
>> +
>> +/**
>> + * privcmd-bu
On 15/06/18 16:43, Boris Ostrovsky wrote:
> On 06/15/2018 09:17 AM, Juergen Gross wrote:
>> +static int privcmd_buf_mmap(struct file *file, struct vm_area_struct *vma)
>> +{
>> +struct privcmd_buf_private *file_priv = file->private_data;
>> +struct privcmd_buf_vma_private *vma_priv;
>> +
On Fri, 15 Jun 2018, Anthony PERARD wrote:
> On Fri, Jun 15, 2018 at 11:06:47AM +0100, Peter Maydell wrote:
> > On 5 June 2018 at 17:55, Anthony PERARD wrote:
> > > On Fri, Jun 01, 2018 at 06:59:10PM +0100, Peter Maydell wrote:
> > >> The xen pci_assign_dev_load_option_rom() currently creates a RA
This run is configured for baseline tests only.
flight 74871 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74871/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-
On 15/06/18 16:48, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH 1/3] tools/libxencall: use hypercall buffer
> device if available"):
>> Instead of using anonymous memory for hypercall buffers which is then
>> locked into memory, use the hypercall buffer device of the Linux
>> privcmd driver
On 15/06/18 16:54, Andrew Cooper wrote:
> On 15/06/18 14:26, Juergen Gross wrote:
>> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
>> index 03bc9a7776..18add80232 100644
>> --- a/tools/libxc/xc_private.h
>> +++ b/tools/libxc/xc_private.h
>> @@ -254,9 +254,12 @@ out1:
>> retu
In XSA-254, we advertised siome special new branches, comet and vixen,
which were intended to be used as the shim in the PV-in-HVM shim
approaches to XSA-254 mitigation.
With my Debian maintainer hat on, I chose to do that. (I don't know,
of course, what proportion of Debian users are using shim
Juergen Gross writes ("Re: [PATCH 1/3] tools/libxencall: use hypercall buffer
device if available"):
> On 15/06/18 16:48, Ian Jackson wrote:
> > I find this early exit approach a bit clumsy, but maybe putting all
> > the rest in an else branch would be worse.
>
> What about two sub-functions and
Juergen Gross writes ("Re: [Xen-devel] [PATCH 3/3] tools/libxc: retry hypercall
in case of EFAULT"):
> On 15/06/18 16:54, Andrew Cooper wrote:
> > Probably a very minor issue, but is it worth caching never_fault once
> > when opening the xc_interface? Calling into a separate shared object on
> >
When dom0-strict mode is enabled the iommu_inclusive_mapping workaround
for firmware with undeclared RMRRs is rendered useless. This series fixes
the problem.
Paul Durrant (2):
VT-d: re-phrase logic in vtd_set_hwdom_mapping() for clarity
VT-d: reconcile iommu_inclusive_mapping and iommu=dom0-s
It is hard to reconcile the comment at the top of the loop in
vtd_set_hwdom_mapping() with the if statement following it. This patch
re-phrases the logic, preserving the semantics, but making it easier
to read.
The patch also modifies the Xen command line documentation to make it
clear that iommu_
The documentation for the iommu_inclusive_mapping Xen command line option
states:
"Use this to work around firmware issues providing incorrect RMRR entries"
Unfortunately this workaround does not function correctly if the dom0-strict
iommu option is also specified.
The documentation goes on to s
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked if the produced result is valid, removing a few
false-positives.
Acked-by: Takashi Iwai
Acked-by: Masami Hiramatsu
Acked-by: Stephen B
When xenbus_printf fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling xenbus_printf.
Signed-off-by: Zhouyang Jia
v1->v2:
- Fix dereferencing before checking.
v2->v3:
- Use xenbus_dev_error to report errors.
v3->v4:
- Fix compila
When xenbus_printf fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling xenbus_printf.
Signed-off-by: Zhouyang Jia
---
v1->v2:
- Use xenbus_dev_error to report errors.
---
drivers/xen/xen-scsiback.c | 18 --
1 fil
flight 124190 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124190/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 7 xen-bootfail REGR. vs. 122969
test-amd64-amd64-libv
On Fri, 15 Jun 2018, Ian Jackson wrote:
In XSA-254, we advertised siome special new branches, comet and vixen,
which were intended to be used as the shim in the PV-in-HVM shim
approaches to XSA-254 mitigation.
With my Debian maintainer hat on, I chose to do that. (I don't know,
of course, what
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on xen-tip/linux-next]
[also build test ERROR on v4.17 next-20180615]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Memory {increase|decrease}_reservation and VA mappings update/reset
> code used in balloon driver can be made common, so other drivers can
> also re-use the same functionality without open-coding.
> Create a
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add UAPI and IOCTLs for dma-buf grant device driver extension:
> the extension allows userspace processes and kernel modules to
> use Xen backed dma-buf implementation. With this extension grant
> references
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Create a dma-buf from grant references provided by the foreign
>domain. By default dma-buf is backed by system memory pages, but
>by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
>
On 06/15/2018 02:27 AM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> 1. Import a dma-buf with the file descriptor provided and export
>granted references to the pages of that dma-buf into the array
>of grant references.
>
> 2. Add API to close all references to an imp
On 06/15/2018 02:50 AM, Oleksandr Andrushchenko wrote:
> On 06/15/2018 09:46 AM, Juergen Gross wrote:
>> On 15/06/18 08:32, Oleksandr Andrushchenko wrote:
>>> Please note, that this will need a change (attached) while
>>> applying to the mainline kernel because of API changes [1].
>>>
>>> Unfortuna
flight 124191 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124191/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 7 xen-boot fail REGR. vs. 124090
build-i386-libvirt
flight 124174 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-libvirt-xsm
When xenbus_printf fails, the lack of error-handling code may
cause unexpected results.
This patch adds error-handling code after calling xenbus_printf.
Signed-off-by: Zhouyang Jia
---
v1->v2:
- Use xenbus_dev_error to report errors.
v2->v3:
- Fix compilation errors.
---
drivers/xen/xen-scsibac
flight 124199 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124199/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124177
test-armhf-armhf-libvirt 14 sav
78 matches
Mail list logo
