flight 132382 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
test-amd64-i386-xl-qemu
On Tue, Jan 22, 2019 at 11:59:31AM -0800, Stefano Stabellini wrote:
> > if (!virtio_has_iommu_quirk(vdev))
> > return true;
> >
> > @@ -260,7 +262,7 @@ static bool vring_use_dma_api(struct virtio_device
> > *vdev)
> > * the DMA API if we're a Xen guest, which at least allows
OASIS members and other interested parties,
OASIS and the OASIS Virtual I/O Device (VIRTIO) TC are pleased to announce
that Virtual I/O Device (VIRTIO) Version 1.1 is now available for public
review and comment.
Specification Overview:
This document describes the specifications of the “virtio” f
flight 132374 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132374/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 6 xen-install fail REGR. vs. 125898
test-amd64-amd64-xl
On Tue, Jan 22, 2019 at 11:59:31AM -0800, Stefano Stabellini wrote:
> On Mon, 21 Jan 2019, Peng Fan wrote:
> > on i.MX8QM, M4_1 is communicating with DomU using rpmsg with a fixed
> > address as the dma mem buffer which is predefined.
> >
> > Without this patch, the flow is:
> > vring_map_one_sg -
flight 132290 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132290/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 128858
test-amd64-i386-xl-q
On Fri, 30 Nov 2018, Julien Grall wrote:
> GICv2 and GICv3 supports up to 1020 interrupts. However, the value computed
> from GICD_TYPER.ITLinesNumber can be up to 1024. On GICv3, we will end up to
> write in reserved registers that are right after the IROUTERs one as the
> value is not capped earl
flight 132270 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132270/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
test-amd64-amd64-i38
flight 132316 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132316/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
On Mon, 21 Jan 2019, Peng Fan wrote:
> on i.MX8QM, M4_1 is communicating with DomU using rpmsg with a fixed
> address as the dma mem buffer which is predefined.
>
> Without this patch, the flow is:
> vring_map_one_sg -> vring_use_dma_api
> -> dma_map_page
> ->
flight 132271 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132271/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131437
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
On 22/01/2019 10:46, Jan Beulich wrote:
>
>> Regardless of the
>> alignment though, the fact that order comes from a hypercall argument and
>> may
>> not match any of the orders supported by the IOMMU implementation makes me
>> think that using a page count is better.
> Splitting up guest reque
flight 132318 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132318/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132083
test-armhf-armhf-libvirt-raw 13 saveresto
On Mon, Jan 21, 2019 at 03:56:29PM -0800, Stefano Stabellini wrote:
> > Where should we pick this up? I could pick it up through the dma-mapping
> > tree given that is where the problem is introduced, but the Xen or arm64
> > trees would also fit.
>
> I am happy for you to carry it in the dma-map
On Mon, Jan 21, 2019 at 04:27:38AM -0700, Jan Beulich wrote:
> >>> On 18.01.19 at 17:03, wrote:
> > ...and remove alignment assertions.
> >
> > Testing shows that certain callers of iommu_legacy_map/unmap() specify
> > order > 0 ranges that are not order aligned thus causing one of the
> > IS_ALI
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 22 January 2019 10:47
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap ; Ian
> Jackson ; Roger Pau Monne ;
> Wei Liu ; Sander Eikelenboom ;
> Chao Gao ; Jun Nakajima ;
> Kevin Tian ; Stefano
>>> On 22.01.19 at 17:08, wrote:
> On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
> On 22.01.19 at 06:50, wrote:
>>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> @@ -1529,6 +1591,8 @@ int dea
On Sun, Jan 20, 2019 at 11:09:25PM +0100, Sander Eikelenboom wrote:
> On 18/01/2019 18:56, Roger Pau Monné wrote:
> > On Fri, Jan 18, 2019 at 03:17:57PM +0100, Sander Eikelenboom wrote:
> >> On 18/01/2019 13:50, Roger Pau Monné wrote:
> >>> On Fri, Jan 18, 2019 at 01:03:04PM +0100, Sander Eikelenbo
flight 132302 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132302/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
129475
test-amd64-i386-xl-qemu
On Tue, Jan 22, 2019 at 10:18:55AM +0100, Roger Pau Monné wrote:
>On Tue, Jan 22, 2019 at 01:50:20PM +0800, Chao Gao wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>> >> +}
>> >> +}
>> >> +/*
>
On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
On 22.01.19 at 06:50, wrote:
>> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>>>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
@@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg,
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 7f2590a110b8 x86/entry/64: Use a per-CPU trampoline stack for
IDT entries.
The bot has tested the following trees: v4.20.3, v4.19.16, v4.14.94.
v4.20.3: Build OK!
v4.19.16: Build
There is a flaw in the xen-bus state model. To allow a frontend to re-
connect the backend state of an online XenDevice is transitioned from
Closed to InitWait, but this is currently done unilaterally which is
incorrect. The backend state should remain Closed until the frontend state
transitions to
> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 22 January 2019 14:40
> To: qemu-de...@nongnu.org; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; Anthony Perard
> Subject: [PATCH] xen: fix xen-bus state model to allow frontend
flight 132230 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132230/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132093
test-amd64-amd64-xl-qemuu-win7-amd64
flight 132342 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132342/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 2019-01-22 15:46, Kevin Wolf wrote:
> Am 22.01.2019 um 15:19 hat Thomas Huth geschrieben:
>> On 2018-12-18 17:11, Thomas Huth wrote:
>>> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
>>> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
>>> is derived from X
Am 22.01.2019 um 15:19 hat Thomas Huth geschrieben:
> On 2018-12-18 17:11, Thomas Huth wrote:
> > The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> > It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> > is derived from XenDevice which in turn is derived from Dev
There is a flaw in the xen-bus state model. To allow a frontend to re-
connect the backend state of an online XenDevice is transitioned from
Closed to InitWait, but this is currently done unilaterally which is
incorrect. The backend state should remain Closed until the frontend state
transitions to
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav P
On 1/22/19 1:48 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
On 21.01.19 19:29, Julien Grall wrote:
(+ Juergen)
All patches candidate for Xen 4.12 should have the release manager
CCed and explain the pros/cons to have those patches for this release.
It is also useful if you add for-4.12 (o
On 2018-12-18 17:11, Thomas Huth wrote:
> The last user of blk_attach_dev_legacy() is the code in xen_disk.c.
> It passes a pointer to a XenBlkDev as second parameter. XenBlkDev
> is derived from XenDevice which in turn is derived from DeviceState
> since commit 3a6c9172ac5951e ("xen: create qdev f
On Mon, Jan 21, 2019 at 01:59:40AM -0800, Christopher Clark wrote:
> Version five of this patch series:
>
> * Changes are primarily addressing feedback from the v4 series reviews.
> Many points noted on the invididual commit posts.
>
> * Critical sections have been shrunk, with allocations and
On Mon, Jan 21, 2019 at 01:59:50AM -0800, Christopher Clark wrote:
> Queries for data about space availability in registered rings and
> causes notification to be sent when space has become available.
>
> The hypercall op populates a supplied data structure with information about
> ring state and
Hello Julien,
On 21.01.19 19:29, Julien Grall wrote:
(+ Juergen)
All patches candidate for Xen 4.12 should have the release manager CCed and
explain the pros/cons to have those patches for this release. It is also useful
if you add for-4.12 (or similar) in the [...] so we can prioritize it.
On 22/01/2019 08:06, Jan Beulich wrote:
On 21.01.19 at 19:08, wrote:
>> On 17/01/2019 13:35, Jan Beulich wrote:
>> On 16.01.19 at 10:00, wrote:
@@ -709,6 +709,12 @@ Controls for the dom0 IOMMU setup.
This option is enabled by default on x86 systems, and invalid on ARM
Hello Julien,
On 21.01.19 19:39, Julien Grall wrote:
I think it would make sense to keep the interrupts disabled in is_lpi as well.
So we keep the behavior the same accross all interrupts.
Agree.
Will send v2 a bit later.
--
Sincerely,
Andrii Anisov.
_
On 21.01.19 19:40, Julien Grall wrote:
Reviewed-by: Julien Grall
I will queue this patch for 4.13.
Thank you.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xe
Hi there, I'm trying to pass through my primary graphics card, but I have trouble getting it to work. I posted already on xen-users, but no one replied. So I try again on the developers list.I have the latest xen-unstable, and as Dom0 kernel I run 4.20 (also latest from upstream).I have the followi
flight 132227 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132227/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pygrub 19 guest-start/debian.repeat fail REGR. vs. 125898
Tests which did not
On Mon, Jan 21, 2019 at 01:59:49AM -0800, Christopher Clark wrote:
> sendv operation is invoked to perform a synchronous send of buffers
> contained in iovs to a remote domain's registered ring.
>
> It takes:
> * A destination address (domid, port) for the ring to send to.
>It performs a most
On 1/22/19 10:28 AM, Oleksandr Andrushchenko wrote:
Hello, Julien!
Hi,
On 1/21/19 7:09 PM, Julien Grall wrote:
Well, I didn't get the attributes of pages at the backend side, but IMO
those
do not matter in my use-case (for simplicity I am not using zero-copying at
backend side):
They are
On Tue, Jan 22, 2019 at 12:38:36PM +0100, Juergen Gross wrote:
> On 16/01/2019 17:16, Anthony PERARD wrote:
> > Second try, this time also works for all links to xen-vbd-interface(7).
> >
> > We don't try anymore to have pod2html generate relative links, instead
> > we do it ourself.
> >
> > Firs
On 16/01/2019 17:16, Anthony PERARD wrote:
> Provide a better way to see the link to a different manpage, with simple
> words.
>
> Suggested-by: Ian Jackson
> Signed-off-by: Anthony PERARD
> Acked-by: Ian Jackson
Release-acked-by: Juergen Gross
Juergen
_
On 16/01/2019 17:16, Anthony PERARD wrote:
> Second try, this time also works for all links to xen-vbd-interface(7).
>
> We don't try anymore to have pod2html generate relative links, instead
> we do it ourself.
>
> First, we modify all links to man pages to have what looks like an
> absolute URL
>>> On 21.01.19 at 13:03, wrote:
On 20.01.19 at 22:18, wrote:
>> The "no repeated checks" problem also occurs when another separate
>> struct contains a field of a type that has already been checked:
>> whichever CHECK is performed second will break.
>>
>> eg.
>> typedef struct xen_argo_rin
On Mon, Jan 21, 2019 at 01:59:48AM -0800, Christopher Clark wrote:
> Takes a single argument: a handle to the ring unregistration struct,
> which specifies the port and partner domain id or wildcard.
>
> The ring's entry is removed from the hashtable of registered rings;
> any entries for pending
Hi Peng,
The commit title is a bit confusing. It suggests that all interrupts
should be deactivated at boot, however you are only deactivating the SGIs.
On 1/22/19 2:35 AM, Peng Fan wrote:
On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and Syste
>>> On 21.01.19 at 14:22, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 21 January 2019 12:05
>> To: Paul Durrant
>> Cc: Julien Grall ; Andrew Cooper
>> ; George Dunlap ; Ian
>> Jackson ; Roger Pau Monne ;
>> Wei Liu ; Sander Eikelenboom ;
>> Chao
Hello, Julien!
On 1/21/19 7:09 PM, Julien Grall wrote:
> Hello,
>
> On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
>> On 1/18/19 1:43 PM, Julien Grall wrote:
>>> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
> On Wed, Jan 16, 2019 a
On Wed, Jan 16, 2019 at 04:16:56PM +, Anthony PERARD wrote:
> Second try, this time also works for all links to xen-vbd-interface(7).
>
> We don't try anymore to have pod2html generate relative links, instead
> we do it ourself.
>
> First, we modify all links to man pages to have what looks l
On Tue, Jan 22, 2019 at 10:43:11AM +0100, nicolas.poi...@bertin.fr wrote:
> Hi everyone,
>
> I was wondering why when I build an x86_64 xen I got a mkelf32 command
> converting elf 64 to elf 32.
> My understanding, looking at git-log, is that that was needed for 32bits
> bootloaders.
>
> Is tha
On Mon, Jan 21, 2019 at 01:59:47AM -0800, Christopher Clark wrote:
> The register op is used by a domain to register a region of memory for
> receiving messages from either a specified other domain, or, if specifying a
> wildcard, any domain.
>
> This operation creates a mapping within Xen's priva
Hi everyone,
I was wondering why when I build an x86_64 xen I got a mkelf32 command
converting elf 64 to elf 32.
My understanding, looking at git-log, is that that was needed for 32bits
bootloaders.
Is that the only reason ? Is it still necessary today ?
Thanks.
Nicolas
.
_
Hello Jan,
On 22.01.19 10:20, Jan Beulich wrote:
What's excessive there? How come you alter the function's
return value without saying why? The more that you make
it potentially return success when there was an error.
Ah, I've realized the difference. In unmap, for hardware domain, we will
it
On Tue, Jan 22, 2019 at 01:50:20PM +0800, Chao Gao wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
> >On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
> >> +}
> >> +}
> >> +/*
> >> + * All pirq-s should have been unmapped and corresponding msi_
>>> On 22.01.19 at 00:41, wrote:
> We haven't managed to reach consensus on this topic. Your view might be
> correct, but it is not necessarily supported by compilers' behavior,
> which depends on the opinion of compilers engineers on the topic, and
> MISRAC compliance, which depends on the opinio
On 22/01/2019 09:52, Jan Beulich wrote:
On 22.01.19 at 09:06, wrote:
>> Don't allow memory to be added above the allowed maximum allocation
>> limit set by Xen.
>
> This reads as if the hypervisor was imposing a limit here, but looking at
> xen_get_max_pages(), xen_foreach_remap_area(), and
>>> On 22.01.19 at 00:15, wrote:
> On Mon, 21 Jan 2019, Jan Beulich wrote:
>> >>> On 21.01.19 at 11:22, wrote:
>> > Hi Jan,
>> >
>> > On 21/01/2019 09:34, Jan Beulich wrote:
>> > On 18.01.19 at 11:48, wrote:
>> >>> On 18/01/2019 09:54, Jan Beulich wrote:
>> >>> On 18.01.19 at 02:24, wr
>>> On 22.01.19 at 09:06, wrote:
> Don't allow memory to be added above the allowed maximum allocation
> limit set by Xen.
This reads as if the hypervisor was imposing a limit here, but looking at
xen_get_max_pages(), xen_foreach_remap_area(), and
xen_count_remap_pages() I take it that it's a res
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-shadow
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>>> On 22.01.19 at 06:50, wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>>On Wed, Jan 16, 2019 at 04:17:30PM +0800, Chao Gao wrote:
>>> @@ -1529,6 +1591,8 @@ int deassign_device(struct domain *d, u16 seg, u8
>>> bus, u8 devfn)
>>> if ( !pdev )
>>> return
>>> On 21.01.19 at 17:04, wrote:
> Wipe out excessive lines from an iommu_unmap(), and align it with an
> iommu_map() code.
What's excessive there? How come you alter the function's
return value without saying why? The more that you make
it potentially return success when there was an error.
Jan
>>> On 21.01.19 at 19:08, wrote:
> On 17/01/2019 13:35, Jan Beulich wrote:
> On 16.01.19 at 10:00, wrote:
>>> @@ -709,6 +709,12 @@ Controls for the dom0 IOMMU setup.
>>> This option is enabled by default on x86 systems, and invalid on ARM
>>> systems.
>>>
>>> +* The `none` optio
Don't allow memory to be added above the allowed maximum allocation
limit set by Xen.
Trying to do so would result in cases like the following:
[ 584.559652] [ cut here ]
[ 584.564897] WARNING: CPU: 2 PID: 1 at ../arch/x86/xen/multicalls.c:129
xen_alloc_pte+0x1c7/0x390(
On a customer system running Xen a boot problem was observed due to
the kernel not respecting the memory size limit imposed by the Xen
hypervisor.
During analysis I found the same problem should be able to occur on
bare metal in case the memory would be limited via the "mem=" boot
parameter.
The
When limiting memory size via kernel parameter "mem=" this should be
respected even in case of memory made accessible via a PCI card.
Today this kind of memory won't be made usable in initial memory
setup as the memory won't be visible in E820 map, but it might be
added when adding PCI devices due
On Mon, Jan 21, 2019 at 11:13 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> > >
> > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy
> > > kms drivers. Just removing it from all the atomic drivers caused lots of
> > > fallout, I expect even more if you entirely remove
On Mon, Jan 21, 2019 at 07:02:25PM +, Andrew Cooper wrote:
> This option is unique to x86 PV dom0's, but it is not sensible to have a
> catch-all which blindly maps all non-RAM regions into the IOMMU.
>
> The map-reserved option remains, and covers all the buggy firmware issues that
> I am awa
69 matches
Mail list logo
