flight 131082 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131082/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs.
129996
On Thu, 6 Dec 2018, Julien Grall wrote:
> Hi,
>
> On 12/4/18 8:26 PM, Julien Grall wrote:
> > At the moment, the implementation of Set/Way operations will go through
> > all the entries of the guest P2M and flush them. However, this is very
> > expensive and may render unusable a guest OS using
On Sat, Dec 8, 2018 at 2:40 AM Robin Murphy wrote:
>
> On 2018-12-07 7:28 pm, Souptick Joarder wrote:
> > On Fri, Dec 7, 2018 at 10:41 PM Matthew Wilcox wrote:
> >>
> >> On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
> +int vm_insert_range(struct vm_area_struct *vma, unsigned
CC'ing Dario
Dario, please give a look at the preemption question below.
On Fri, 7 Dec 2018, Julien Grall wrote:
> On 06/12/2018 23:32, Stefano Stabellini wrote:
> > On Tue, 4 Dec 2018, Julien Grall wrote:
> > > Set/Way operations are used to perform maintenance on a given cache.
> > > At the
On Fri, 7 Dec 2018, Julien Grall wrote:
> > > @@ -1547,6 +1551,25 @@ int p2m_cache_flush_range(struct domain *d, gfn_t
> > > start, gfn_t end)
> > > while ( gfn_x(start) < gfn_x(end) )
> > > {
> > > + /*
> > > + * Cleaning the cache for the P2M may take a long time. So
On Fri, Dec 7, 2018 at 3:15 PM David Woodhouse wrote:
>
> During a context switch, if clearing a descriptor which is currently
> referenced by the old process's user %gs, if Xen preempts the vCPU
> before %gs is set for the new process, a fault may occur.
>
> This fault actually seems to be
Hi Jan,
> > > Without a full hypervisor log this is going to remain guesswork, but
> > > could you check whether "pcid=no" and/or "pv-l1tf=no" on the Xen
> > > boot command line help?
> >
> > [vagrant@localhost ~]$ cat /proc/cmdline
> > placeholder root=UUID=f4dcb7e6-e430-4b8b-8e83-5deb3522c88b
flight 131118 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131118/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 3c25eec2c353aafe1b3338c66bfbaed78075ef43
baseline version:
freebsd
Hi Paul,
On 12/07/2018 05:39 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Dongli Zhang
>> Sent: 07 December 2018 04:18
>> To: linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org; linux-
>>
On 07/12/2018 15:09, Julien Grall wrote:
> Hi Andrew,
>
> On 07/12/2018 13:45, Andrew Cooper wrote:
>> A large amount of the information here is obsolete since Xen 4.7
>>
>> To being with, however, this patch marks a change in style for section
>> headings, due to how HTML anchors are generated.
On 06/12/2018 18:39, Souptick Joarder wrote:
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new
On Thu, Dec 06, 2018 at 03:08:31PM +, Paul Durrant wrote:
> @@ -36,6 +54,12 @@ static void xen_block_unrealize(XenDevice *xendev, Error
> **errp)
>
> trace_xen_block_unrealize(type, vdev->disk, vdev->partition);
>
> +/* Disconnect from the frontend in case this has not already
On Thu, Dec 06, 2018 at 03:08:33PM +, Paul Durrant wrote:
> The legacy PV backend infrastructure provides functions to bind, unbind
> and send notifications to event channnels. Similar functionality will be
> required by XenDevice implementations so this patch adds the necessary
> support.
>
On Thu, Dec 06, 2018 at 03:08:36PM +, Paul Durrant wrote:
> This patch adds the transformations necessary to get dataplane/xen-block.c
> to build against the new XenBus/XenDevice framework. MAINTAINERS is also
> updated due to the introduction of dataplane/xen-block.h.
>
> NOTE: Existing data
On Fri, Dec 07, 2018 at 03:34:56PM +, Robin Murphy wrote:
> > +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> > + struct page **pages, unsigned long page_count)
> > +{
> > + unsigned long uaddr = addr;
> > + int ret = 0, i;
>
> Some of the sites
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Dongli Zhang
> Sent: 07 December 2018 04:18
> To: linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org; linux-
> bl...@vger.kernel.org
> Cc: ax...@kernel.dk; Roger Pau Monne ;
>
From: Oleksandr Tyshchenko
This is a follow-up patch to
commit 01a7e8ccef6e7d5718a251ad587567afbe723330
xen/arm: Remove __initdata and __init to enable CPU hotplug
Signed-off-by: Oleksandr Tyshchenko
Acked-by: Julien Grall
---
xen/arch/arm/arm32/smpboot.c | 2 +-
xen/arch/arm/platform.c
From: Oleksandr Tyshchenko
To be able to use it for the hot-plugged CPUs as well.
Signed-off-by: Oleksandr Tyshchenko
---
Changes in v2:
- Fix typoes
- Rename ".init.proc.info" to ".data.proc.info"
---
xen/arch/arm/arm32/proc-v7.S | 6 +++---
xen/arch/arm/xen.lds.S
From: Oleksandr Tyshchenko
Hi, all.
This is small patch series for ARM32 which needed to be able to bring
secondary CPUs up not only during the initial boot, but at runtime also.
For example, during CPU hotplug.
Actually these are follow-up patches to the following series [1], which covers
On 07/12/2018 09:21, osstest service owner wrote:
> flight 131065 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/131065/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-xtf-amd64-amd64-5 69
On 07/12/2018 09:45, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Hi, all.
This is small patch series for ARM32 which needed to be able to bring
secondary CPUs up not only during the initial boot, but at runtime also.
For example, during CPU hotplug.
OOI, we don't have CPU
Hi Oleksandr,
On 07/12/2018 09:45, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
To be able to use it for the hot-plugged CPUs as well.
You need to explain in the commit message why you rename .init.proc.info.
Signed-off-by: Oleksandr Tyshchenko
---
Changes in v2:
Hi Stefano
On 06/12/2018 22:02, Stefano Stabellini wrote:
On Wed, 5 Dec 2018, Julien Grall wrote:
On 04/12/2018 23:50, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
The LPAE format allows to store information in an entry even with the
valid bit unset. In a follow-up
On Thu, Dec 06, 2018 at 06:03:54PM +, Andrew Cooper wrote:
> The struct suffix is redundant in the name, and a future change will want to
> turn it into a union, rather than a structure. As this represents a segment
> descriptor, give it an appropriate typedef.
>
> No functional change.
>
>
Hi Stefano,
On 06/12/2018 22:04, Stefano Stabellini wrote:
On Wed, 5 Dec 2018, Julien Grall wrote:
On 04/12/2018 23:59, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
A follow-up patch will re-purpose the valid bit of LPAE entries to
generate fault even on entry containing
Hi Ravzan,
On 04/12/2018 20:35, Razvan Cojocaru wrote:
On 12/4/18 10:26 PM, Julien Grall wrote:
With the recent changes, a P2M entry may be populated but may as not
valid. In some situation, it would be useful to know whether the entry
I think you mean to say "may not be valid"?
Correct. I
>>> On 06.12.18 at 19:46, wrote:
> On 06/12/2018 08:54, Jan Beulich wrote:
> On 05.12.18 at 18:05, wrote:
>>> On 05/12/2018 16:57, Jan Beulich wrote:
>>> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -419,6 +419,97 @@ static
Hi Stefano,
On 06/12/2018 23:53, Stefano Stabellini wrote:
On Tue, 4 Dec 2018, Julien Grall wrote:
A follow-up patch will add support for preemption in p2m_cache_flush_range.
Because of the complexity for the 2 loops, it would be necessary to add
preemption in both of them.
This can be
[ the math added to xen-tscmode.7 suggests that a domU should see a time
drift, which ntpd corrects. But the actual correction reported in
ntp.drift is entirely different than the one calculated in the
example. To me it is unclear why the example is wrong, more research
must be done. I'm
flight 131070 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131070/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail like 130894
test-armhf-armhf-libvirt 14
flight 131065 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131065/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 69 xtf/test-hvm64-xsa-278 fail REGR. vs. 130985
101 - 131 of 131 matches
Mail list logo
