On 2020-06-25 22:26, Souptick Joarder wrote:
On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote:
On 2020-06-24 20:02, Souptick Joarder wrote:
...
@@ -612,13 +612,7 @@ static int lock_pages(
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
- unsigned int i;
-
On Fri, Jun 26, 2020 at 11:22 AM Jürgen Groß wrote:
>
> On 25.06.20 05:02, Souptick Joarder wrote:
> > Previously, if lock_pages() end up partially mapping pages, it used
> > to return -ERRNO due to which unlock_pages() have to go through
> > each pages[i] till *nr_pages* to validate them. This ca
flight 151350 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did no
On 25.06.20 05:02, Souptick Joarder wrote:
Previously, if lock_pages() end up partially mapping pages, it used
to return -ERRNO due to which unlock_pages() have to go through
each pages[i] till *nr_pages* to validate them. This can be avoided
by passing correct number of partially mapped pages &
On Fri, Jun 26, 2020 at 5:01 AM Boris Ostrovsky
wrote:
>
> On 6/24/20 11:02 PM, Souptick Joarder wrote:
> > Previously, if lock_pages() end up partially mapping pages, it used
> > to return -ERRNO due to which unlock_pages() have to go through
> > each pages[i] till *nr_pages* to validate them. Th
On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote:
>
> On 2020-06-24 20:02, Souptick Joarder wrote:
> > In 2019, we introduced pin_user_pages*() and now we are converting
> > get_user_pages*() to the new API as appropriate. [1] & [2] could
> > be referred for more information. This is case 5 as
flight 151352 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151352/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151330
test-armhf-armhf-libvirt-raw 13 saveresto
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid guest-start/debian
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git:
flight 151341 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151341/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 150176
build-amd64-pr
On 6/24/20 11:02 PM, Souptick Joarder wrote:
> Previously, if lock_pages() end up partially mapping pages, it used
> to return -ERRNO due to which unlock_pages() have to go through
> each pages[i] till *nr_pages* to validate them. This can be avoided
> by passing correct number of partially mapped
flight 151347 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151347/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a4a2258a1fec5481b0bd929b049921cb07a0
baseline version:
ovmf 1a992030522622c42aa06
flight 151340 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151340/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 150375
test-amd64-amd64-xl-qemuu-win7-amd64 17 g
flight 151339 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151339/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 151307
test-armhf-armhf-xl-rtds 1
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
>
Jason Andryuk writes ("Re: [PATCH] scripts: don't rely on "stat -" support"):
> On Thu, Jun 25, 2020 at 11:47 AM Jan Beulich wrote:
> >
> > On 25.06.2020 17:45, Ian Jackson wrote:
> > > Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"):
> > >> While commit b72682c602b8 ("scrip
On Thu, Jun 25, 2020 at 11:47 AM Jan Beulich wrote:
>
> On 25.06.2020 17:45, Ian Jackson wrote:
> > Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"):
> >> While commit b72682c602b8 ("scripts: Use stat to check lock claim")
> >> validly indicates that stat has gained support f
On Thu, Jun 25, 2020 at 11:05:52AM +0200, Roger Pau Monné wrote:
> On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote:
> > On 24.06.2020 15:41, Julien Grall wrote:
> > > On 24/06/2020 11:12, Jan Beulich wrote:
> > >> On 23.06.2020 19:26, Roger Pau Monné wrote:
> > >>> I'm confused. Couldn'
On 25.06.2020 17:45, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"):
>> While commit b72682c602b8 ("scripts: Use stat to check lock claim")
>> validly indicates that stat has gained support for the special "-"
>> command line option in 2009, we should st
Jan Beulich writes ("[PATCH] scripts: don't rely on "stat -" support"):
> While commit b72682c602b8 ("scripts: Use stat to check lock claim")
> validly indicates that stat has gained support for the special "-"
> command line option in 2009, we should still try to avoid breaking being
> able to run
While commit b72682c602b8 ("scripts: Use stat to check lock claim")
validly indicates that stat has gained support for the special "-"
command line option in 2009, we should still try to avoid breaking being
able to run on even older distros. As it has been determined, contary to
the comment in the
Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
> On Thu, Jun 25, 2020 at 10:08 AM Jan Beulich wrote:
> > I'm about to test this then, but to be honest I have no idea what
> > to do with the comment. I don't think I could properly justify its
> > deletion in the description (b
On Thu, Jun 25, 2020 at 04:16:43PM +0200, Roger Pau Monne wrote:
> XENMEM_acquire_resource and it's related structure is currently inside
> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the
> hypervisor or the toolstack only. This is wrong as the hypercall is
> already being use
Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
> I'm about to test this then, but to be honest I have no idea what
> to do with the comment. I don't think I could properly justify its
> deletion in the description (beyond saying it's not really true),
> nor would I be certain wh
On Thu, Jun 25, 2020 at 10:08 AM Jan Beulich wrote:
>
> On 25.06.2020 15:27, Ian Jackson wrote:
> > Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
> >> I was going to just write a patch to replace - with /dev/stdin and ask
> >> Jan to test it. When I opened the script, this
On Thu, Jun 25, 2020 at 9:48 AM Jan Beulich wrote:
>
> On 25.06.2020 15:31, Ian Jackson wrote:
> > Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
> >> Looking at vfs_statx() in the kernel, I can't see any provisions to
> >> get at the data without traversing the specified path.
XENMEM_acquire_resource and it's related structure is currently inside
a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the
hypervisor or the toolstack only. This is wrong as the hypercall is
already being used by the Linux kernel at least, and as such needs to
be public.
Also swi
On 25.06.2020 15:27, Ian Jackson wrote:
> Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
>> I was going to just write a patch to replace - with /dev/stdin and ask
>> Jan to test it. When I opened the script, this comment was staring at
>> me:
>> # We can't just stat /
On 25.06.2020 15:31, Ian Jackson wrote:
> Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
>> Looking at vfs_statx() in the kernel, I can't see any provisions to
>> get at the data without traversing the specified path.
>
> The question is what "traversing the path" means.
>
> H
Jan Beulich writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
> Looking at vfs_statx() in the kernel, I can't see any provisions to
> get at the data without traversing the specified path.
The question is what "traversing the path" means.
How do you explain this ?
$ >t
$ exec 3>t
$ stat -L
Jason Andryuk writes ("Re: [XEN RFC for-4.14] Re: use of "stat -""):
> I was going to just write a patch to replace - with /dev/stdin and ask
> Jan to test it. When I opened the script, this comment was staring at
> me:
> # We can't just stat /dev/stdin or /proc/self/fd/$_lockfd or
>
flight 151337 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151337/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim12 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 13
On Thu, Jun 25, 2020 at 3:05 AM Jan Beulich wrote:
>
> On 25.06.2020 04:37, Jason Andryuk wrote:
> > On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote:
> >>
> >> Jan Beulich writes ("Re: use of "stat -""):
> >>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> >>> unl
Commit e9aca9470ed86 introduced a regression when avoiding sending
IPIs for certain flush operations. Xen page fault handler
(spurious_page_fault) relies on blocking interrupts in order to
prevent handling TLB flush IPIs and thus preventing other CPUs from
removing page tables pages. Switching to a
flight 151356 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151356/
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 Jun 25, 2020, at 12:10 AM, Andrew Cooper wrote:
>
> On 24/06/2020 17:13, Ian Jackson wrote:
>> I think it would be a good idea to rename this branch name.
[snip]
> Describing someone as a "master of their trade/skill/other", is a
> totally different context, and it would be excessive to
flight 151334 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151334/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151311
test-amd64-amd64-xl-qemut-win7-amd64
On Wed, Jun 24, 2020 at 12:10:45PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 23/06/2020 17:16, Roger Pau Monné wrote:
> > On Tue, Jun 23, 2020 at 04:46:29PM +0100, Julien Grall wrote:
> > >
> > >
> > > On 23/06/2020 16:15, Roger Pau Monné wrote:
> > > > On Tue, Jun 23, 2020 at 04:08:06PM +01
Hi Jan,
On 24/06/2020 15:01, Jan Beulich wrote:
On 24.06.2020 15:41, Julien Grall wrote:
On 24/06/2020 11:12, Jan Beulich wrote:
On 23.06.2020 19:26, Roger Pau Monné wrote:
I'm confused. Couldn't we switch from uint64_aligned_t to plain
uint64_t (like it's currently on the Linux headers), and
On Wed, Jun 24, 2020 at 04:01:44PM +0200, Jan Beulich wrote:
> On 24.06.2020 15:41, Julien Grall wrote:
> > On 24/06/2020 11:12, Jan Beulich wrote:
> >> On 23.06.2020 19:26, Roger Pau Monné wrote:
> >>> I'm confused. Couldn't we switch from uint64_aligned_t to plain
> >>> uint64_t (like it's curren
> On 24 Jun 2020, at 18:38, Stefano Stabellini wrote:
>
> On Wed, 24 Jun 2020, Ian Jackson wrote:
>> I think it would be a good idea to rename this branch name. This name
>> has unfortunate associations[1], even if it can be argued[2] that the
>> etymology is not as bad as in some uses of the
On Jun 24, 2020, at 22:39, Jason Andryuk wrote:
>
> On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote:
>>
>> Jan Beulich writes ("Re: use of "stat -""):
>>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>>> unless you have verified the sender and know the content
On 25.06.2020 04:37, Jason Andryuk wrote:
> On Wed, Jun 24, 2020 at 12:19 PM Ian Jackson wrote:
>>
>> Jan Beulich writes ("Re: use of "stat -""):
>>> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
>>> unless you have verified the sender and know the content is safe.
>>>
> -Original Message-
> From: Ian Jackson
> Sent: 24 June 2020 17:20
> To: Jan Beulich
> Cc: Elliott Mitchell ; Andrew Cooper
> ; Jason Andryuk
> ; Paul Durrant ; Wei Liu ;
> xen-
> de...@lists.xenproject.org
> Subject: [XEN RFC for-4.14] Re: use of "stat -"
>
> Jan Beulich writes ("Re:
43 matches
Mail list logo
