flight 157213 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157213/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On 05.12.20 00:53, Andrew Cooper wrote:
On 01/12/2020 08:21, Juergen Gross wrote:
Support scheduling granularity per cpupool. Setting the granularity is
done via hypfs, which needed to gain dynamical entries for that
purpose.
Apart from the hypfs related additional functionality the main change
flight 157216 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 157205 xen-unstable real [real]
flight 157217 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157205/
http://logs.test-lab.xenproject.org/osstest/logs/157217/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
flight 157214 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157214/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 265eabc905eaa38b7c6deb3fedb83fe6d37e9b11
baseline version:
ovmf 97e2b622d1f32ba35194d
On Fri, 4 Dec 2020, Durrant, Paul wrote:
> > -Original Message-
> > From: Andrew Cooper
> > Sent: 04 December 2020 17:45
> > To: Stefano Stabellini
> > Cc: Julien Grall ; Jan Beulich ;
> > p...@xen.org; Durrant, Paul
> > ; Elnikety, Eslam ; 'Ian
> > Jackson' ;
> > 'Wei Liu' ; 'Anthony P
On Thu, 26 Nov 2020, Jan Beulich wrote:
> On 26.11.2020 09:03, Juergen Gross wrote:
> > When the host crashes it would sometimes be nice to have additional
> > debug data available which could be produced via debug keys, but
> > halting the server for manual intervention might be impossible due to
On Wed, 2 Dec 2020, Bertrand Marquis wrote:
> > On 2 Dec 2020, at 11:12, Bertrand Marquis wrote:
> >
> > HI Volodymyr,
> >
> >> On 1 Dec 2020, at 16:54, Volodymyr Babchuk
> >> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Bertrand Marquis writes:
> >>
> >>> Hi Volodymyr,
> >>>
> On 1 Dec 2020,
On Mon, 30 Nov 2020, Bertrand Marquis wrote:
> Add vsysreg emulation for registers trapped when TID3 bit is activated
> in HSR.
> The emulation is returning the value stored in cpuinfo_guest structure
> for most values and the hardware value for registers not stored in the
> structure (those are mo
On Mon, 30 Nov 2020, Bertrand Marquis wrote:
> Create a cpuinfo structure for guest and mask into it the features that
> we do not support in Xen or that we do not want to publish to guests.
>
> Modify some values in the cpuinfo structure for guests to mask some
> features which we do not want to
On Mon, 30 Nov 2020, Volodymyr Babchuk wrote:
> Bertrand Marquis writes:
>
> > Add coprocessor registers definitions for all ID registers trapped
> > through the TID3 bit of HSR.
> > Those are the one that will be emulated in Xen to only publish to guests
> > the features that are supported by Xen
On 01/12/2020 08:21, Juergen Gross wrote:
> Support scheduling granularity per cpupool. Setting the granularity is
> done via hypfs, which needed to gain dynamical entries for that
> purpose.
>
> Apart from the hypfs related additional functionality the main change
> for cpupools was the support fo
There is a typo in the subject line
On Mon, 30 Nov 2020, Bertrand Marquis wrote:
> Add definition and entries in cpuinfo for ID registers introduced in
> newer Arm Architecture reference manual:
> - ID_PFR2: processor feature register 2
> - ID_DFR1: debug feature register 1
> - ID_MMFR4 and ID_MM
flight 157199 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157199/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Fri, 4 Dec 2020, Wei Liu wrote:
> On Tue, Nov 24, 2020 at 08:27:34PM -0800, Stefano Stabellini wrote:
> > Use QEMU to start Xen (just the hypervisor) up until it stops because
> > there is no dom0 kernel to boot.
> >
> > It is based on the existing build job unstable-arm64v8.
> >
> > Also use
On Fri, Dec 4, 2020 at 2:22 PM Julien Grall wrote:
>
> On Fri, 4 Dec 2020 at 19:15, Tamas K Lengyel
> wrote:
> >
> > On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote:
> > >
> > >
> > >
> > > On 04/12/2020 15:21, Tamas K Lengyel wrote:
> > > > On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote
On Fri, 4 Dec 2020 at 19:15, Tamas K Lengyel wrote:
>
> On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote:
> >
> >
> >
> > On 04/12/2020 15:21, Tamas K Lengyel wrote:
> > > On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote:
> > >>
> > >> Hi Jan,
> > >>
> > >> On 03/12/2020 10:09, Jan Beulich wr
On Fri, Dec 4, 2020 at 10:29 AM Julien Grall wrote:
>
>
>
> On 04/12/2020 15:21, Tamas K Lengyel wrote:
> > On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote:
> >>
> >> Hi Jan,
> >>
> >> On 03/12/2020 10:09, Jan Beulich wrote:
> >>> On 02.12.2020 22:10, Julien Grall wrote:
> On 23/11/2020 13
> -Original Message-
> From: Andrew Cooper
> Sent: 04 December 2020 17:45
> To: Stefano Stabellini
> Cc: Julien Grall ; Jan Beulich ;
> p...@xen.org; Durrant, Paul
> ; Elnikety, Eslam ; 'Ian Jackson'
> ;
> 'Wei Liu' ; 'Anthony PERARD' ;
> 'George Dunlap'
> ; 'Christian Lindig' ;
> 'Da
flight 157206 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157206/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 04/12/2020 17:41, Stefano Stabellini wrote:
>>> FAOD, I am sure there might be other features that need to be
>>> disabled. But we have to start somewhere :).
>> Absolutely top of the list, importance wise, is so we can test different
>> configurations, without needing to rebuild the hypervisor
flight 157198 qemu-mainline real [real]
flight 157207 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157198/
http://logs.test-lab.xenproject.org/osstest/logs/157207/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Fri, 4 Dec 2020, Andrew Cooper wrote:
> On 04/12/2020 11:45, Julien Grall wrote:
> > Hi,
> >
> > I haven't looked at the series yet. Just adding some thoughts on why
> > one would want such option.
> >
> > On 04/12/2020 09:43, Jan Beulich wrote:
> >> On 04.12.2020 09:22, Paul Durrant wrote:
> >>
On Tue, 2020-12-01 at 09:21 +0100, Juergen Gross wrote:
> Instead of open coding something like a linked list just use the
> available functionality from list.h.
>
Yep, much better.
> While adding the required new include to private.h sort the includes.
>
> Signed-off-by: From: Juergen Gross
>
On Tue, 2020-12-01 at 09:21 +0100, Juergen Gross wrote:
> Instead of a pointer to an error variable as parameter just use
> ERR_PTR() to return the cause of an error in cpupool_create().
>
Yes... And thanks!
Happy to see more of this happening and more of the ad-hoc error
handling going away.
>
On Fri, 2020-12-04 at 17:16 +0100, Jürgen Groß wrote:
> On 04.12.20 17:13, Dario Faggioli wrote:
> >
> >
> > What I'd do is:
> > - add a comment here, explaining quickly exactly this fact, i.e.,
> > that it's not that we've forgotten to deal with this and it's
> > all
> > on purpose. Ac
On 04.12.20 17:13, Dario Faggioli wrote:
On Tue, 2020-12-01 at 10:18 +0100, Jürgen Groß wrote:
On 01.12.20 10:12, Jan Beulich wrote:
What guarantees that you managed to find an unused ID, other
than at current CPU speeds it taking too long to create 4
billion pools? Since you're doing this unde
On Tue, 2020-12-01 at 10:18 +0100, Jürgen Groß wrote:
> On 01.12.20 10:12, Jan Beulich wrote:
> > What guarantees that you managed to find an unused ID, other
> > than at current CPU speeds it taking too long to create 4
> > billion pools? Since you're doing this under lock, wouldn't
> > it help an
On Tue, 2020-12-01 at 09:21 +0100, Juergen Gross wrote:
> The cpupool id is an unsigned value in the public interface header,
> so
> there is no reason why it is a signed value in struct cpupool.
>
> Switch it to unsigned int.
>
I think we can add:
"No functional change intended"
> Signed-off-b
flight 157203 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157203/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 04/12/2020 15:21, Tamas K Lengyel wrote:
On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote:
Hi Jan,
On 03/12/2020 10:09, Jan Beulich wrote:
On 02.12.2020 22:10, Julien Grall wrote:
On 23/11/2020 13:30, Jan Beulich wrote:
While there don't look to be any problems with this right now,
On Fri, Dec 4, 2020 at 6:29 AM Julien Grall wrote:
>
> Hi Jan,
>
> On 03/12/2020 10:09, Jan Beulich wrote:
> > On 02.12.2020 22:10, Julien Grall wrote:
> >> On 23/11/2020 13:30, Jan Beulich wrote:
> >>> While there don't look to be any problems with this right now, the lock
> >>> order implication
Hi,
On 04/12/2020 12:01, Jan Beulich wrote:
On 04.12.2020 12:51, Julien Grall wrote:
On 04/12/2020 11:48, Jan Beulich wrote:
On 04.12.2020 12:28, Julien Grall wrote:
Hi Jan,
On 03/12/2020 10:09, Jan Beulich wrote:
On 02.12.2020 22:10, Julien Grall wrote:
On 23/11/2020 13:30, Jan Beulich
Hi, Jan!
On 11/13/20 4:51 PM, Jan Beulich wrote:
> On 13.11.2020 15:44, Oleksandr Andrushchenko wrote:
>> On 11/13/20 4:38 PM, Jan Beulich wrote:
>>> On 13.11.2020 15:32, Oleksandr Andrushchenko wrote:
On 11/13/20 4:23 PM, Jan Beulich wrote:
> Earlier on I didn't say you should get th
flight 157204 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157204/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 97e2b622d1f32ba35194dbca104c3bf918bf3271
baseline version:
ovmf 31e8a47b62a4f3dc45d8f
On Wed, Nov 11, 2020 at 11:01:43AM +0100, Juergen Gross wrote:
> A guest with memory < maxmem often can't be dumped via xl dump-core
> without an error message today:
>
> xc: info: exceeded nr_pages (262144) losing pages
>
> In case the last page of the guest isn't allocated the loop in
> xc_doma
flight 157192 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157192/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 157182
test-amd64-amd64-xl-qemuu-ws16-amd64
Dear Wim, dear Daniel,
First, thank you for including all parties in the discussion.
Am 04.12.20 um 13:52 schrieb Wim Vervoorn:
I agree with you. Using an existing standard is better than inventing
a new one in this case. I think using the coreboot logging is a good
idea as there is indeed a l
On 04.12.20 10:16, Jan Beulich wrote:
On 04.12.2020 09:52, Jürgen Groß wrote:
On 03.12.20 16:44, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
--- a/xen/common/hypfs.c
+++ b/xen/common/hypfs.c
@@ -355,6 +355,81 @@ unsigned int hypfs_getsize(const struct hypfs_entry *entry)
On Thu, Dec 03, 2020 at 02:25:28PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and use in 'libxl_device_pci'
>
> This patch is preparatory work for restricting the type passed to functions
> that only require BDF information, rather than passing a 'libxl_device_pci'
> structure which
Hello Julius,
I agree with you. Using an existing standard is better than inventing a new one
in this case. I think using the coreboot logging is a good idea as there is
indeed a lot of support already available and it is lightweight and simple.
Best Regards,
Wim Vervoorn
Eltan B.V.
Ambachtstr
On Fri, Dec 04, 2020 at 01:08:03PM +0100, Christoph Hellwig wrote:
> On Fri, Dec 04, 2020 at 12:08:47PM +0100, Marek Marczykowski-Górecki wrote:
> > culprit:
> >
> > commit 9e2369c06c8a181478039258a4598c1ddd2cadfa
> > Author: Roger Pau Monne
> > Date: Tue Sep 1 10:33:26 2020 +0200
> >
> >
> -Original Message-
> From: Wei Liu
> Sent: 04 December 2020 11:36
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Christian Lindig
> ; Ian Jackson ; Wei Liu
> ; David Scott
> ; Anthony PERARD
> Subject: Re: [PATCH v5 19/23] libxl: modify
> libxl_device_pci_
On Fri, Dec 04, 2020 at 12:08:47PM +0100, Marek Marczykowski-Górecki wrote:
> culprit:
>
> commit 9e2369c06c8a181478039258a4598c1ddd2cadfa
> Author: Roger Pau Monne
> Date: Tue Sep 1 10:33:26 2020 +0200
>
> xen: add helpers to allocate unpopulated memory
>
> I'm adding relevant peopl
On 04.12.2020 12:51, Julien Grall wrote:
>
>
> On 04/12/2020 11:48, Jan Beulich wrote:
>> On 04.12.2020 12:28, Julien Grall wrote:
>>> Hi Jan,
>>>
>>> On 03/12/2020 10:09, Jan Beulich wrote:
On 02.12.2020 22:10, Julien Grall wrote:
> On 23/11/2020 13:30, Jan Beulich wrote:
>> While t
On Fri, Dec 04, 2020 at 12:46:20PM +0100, Olaf Hering wrote:
> Am Fri, 4 Dec 2020 10:53:15 +
> schrieb Wei Liu :
>
> > Did you accidentally swap 15 and 30 in XENWATCHDOGD_ARGS above?
>
> This is indeed a mistake. Thanks for spotting.
Fixed and pushed. Thanks.
Wei.
On 04.12.2020 12:08, Jürgen Groß wrote:
> On 04.12.20 10:10, Jan Beulich wrote:
>> On 01.12.2020 09:21, Juergen Gross wrote:
>>> +static struct hypfs_funcs cpupool_dir_funcs = {
>>
>> Yet another missing const?
>
> Already fixed.
>
>>
>>> +.enter = cpupool_dir_enter,
>>> +.exit = cpupool_
On 04/12/2020 11:45, Julien Grall wrote:
> Hi,
>
> I haven't looked at the series yet. Just adding some thoughts on why
> one would want such option.
>
> On 04/12/2020 09:43, Jan Beulich wrote:
>> On 04.12.2020 09:22, Paul Durrant wrote:
From: Jan Beulich
Sent: 04 December 2020 07:53
>>>
On 04/12/2020 11:48, Jan Beulich wrote:
On 04.12.2020 12:28, Julien Grall wrote:
Hi Jan,
On 03/12/2020 10:09, Jan Beulich wrote:
On 02.12.2020 22:10, Julien Grall wrote:
On 23/11/2020 13:30, Jan Beulich wrote:
While there don't look to be any problems with this right now, the lock
order i
On 04.12.2020 12:28, Julien Grall wrote:
> Hi Jan,
>
> On 03/12/2020 10:09, Jan Beulich wrote:
>> On 02.12.2020 22:10, Julien Grall wrote:
>>> On 23/11/2020 13:30, Jan Beulich wrote:
While there don't look to be any problems with this right now, the lock
order implications from holding t
flight 157194 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157194/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 31e8a47b62a4f3dc45d8f9bbf3529a188e867a87
baseline version:
ovmf 6af76adbbfccd31f4f875
Am Fri, 4 Dec 2020 10:53:15 +
schrieb Wei Liu :
> Did you accidentally swap 15 and 30 in XENWATCHDOGD_ARGS above?
This is indeed a mistake. Thanks for spotting.
Olaf
pgpusq8ph5fnX.pgp
Description: Digitale Signatur von OpenPGP
Hi,
I haven't looked at the series yet. Just adding some thoughts on why one
would want such option.
On 04/12/2020 09:43, Jan Beulich wrote:
On 04.12.2020 09:22, Paul Durrant wrote:
From: Jan Beulich
Sent: 04 December 2020 07:53
On 03.12.2020 18:07, Paul Durrant wrote:
From: Jan Beulich
On Mon, Nov 23, 2020 at 04:16:02PM +0100, Jan Beulich wrote:
[...]
>
> 1: xen: fix build when $(obj-y) consists of just blanks
> 2: lib: collect library files in an archive
> 3: lib: move list sorting code
> 4: lib: move parse_size_and_unit()
> 5: lib: move init_constructors()
> 6: lib: move rbtre
On Mon, Nov 23, 2020 at 04:00:50PM +0100, Jan Beulich wrote:
> 1: drop three unused variables
> 2: reduce casting involved in guest action retrieval
Reviewed-by: Wei Liu
On Thu, Dec 03, 2020 at 02:25:34PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch adds a 'name' field into the idl for 'libxl_device_pci' and
> libxlu_pci_parse_spec_string() is modified to parse the new 'name'
> parameter of PCI_SPEC_STRING detailed in the updated documention in
On Thu, Dec 03, 2020 at 02:25:33PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Since assignable devices can be named, a subsequent patch will support use
> of a PCI_SPEC_STRING containing a 'name' parameter instead of a 'bdf'. In
> this case the name will be used to look up the 'bdf' in t
On Thu, Dec 03, 2020 at 02:25:32PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch modifies libxl_device_pci_assignable_add() to take an optional
> 'name' argument, which (if supplied) is saved into xenstore and can hence be
> used to refer to the now-assignable BDF in subsequent o
On Thu, Dec 03, 2020 at 02:25:31PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> A subsequent patch will introduce code to allow a name to be specified to
> 'xl pci-assignable-add' such that the assignable device may be referred to
> by than name in subsequent operations.
>
> Signed-off-by
On Thu, Dec 03, 2020 at 02:25:30PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to use 'libxl_pci_bdf' rather than 'libxl_device_pci'.
>
> This patch modifies the API and callers accordingly. It also modifies
> several internal functions in libxl_pci.c that support the API to also use
On Thu, Dec 03, 2020 at 02:25:29PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> This patch largely re-writes the code to parse a PCI_SPEC_STRING and enters
> it via the newly introduced function. The new parser also deals with 'bdf'
> and 'vslot' as non-positional paramaters, as per the do
On Thu, Dec 03, 2020 at 02:25:28PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and use in 'libxl_device_pci'
>
> This patch is preparatory work for restricting the type passed to functions
> that only require BDF information, rather than passing a 'libxl_device_pci'
> structure which
On Thu, Dec 03, 2020 at 02:25:27PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Currently the documentation completely fails to mention the existence of
> PCI_SPEC_STRING. This patch tidies things up, specifically clarifying that
> 'pci-assignable-add/remove' take arguments where as 'pci-
On Thu, Dec 03, 2020 at 02:25:26PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and prepare for adding support for non-positional parsing of 'bdf' and
> 'vslot' in a subsequent patch.
>
> Also document 'BDF' as a first-class parameter type and fix the documentation
> to state that the
On Thu, Dec 03, 2020 at 02:25:24PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... rather than an open-coded equivalent.
>
> This patch tidies up the is_pci_in_array() function, making it take a single
> 'libxl_device_pci' argument rather than separate domain, bus, device and
> function
On Thu, Dec 03, 2020 at 02:25:25PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... and put it into a new xl-pci-configuration(5) manpage, akin to the
> xl-network-configration(5) and xl-disk-configuration(5) manpages.
>
> This patch moves the content of the section verbatim. A subsequent
On Thu, Dec 03, 2020 at 02:25:23PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to be used by callers of libxl_device_pci_assignable_list().
>
> Currently there is no API for callers of libxl_device_pci_assignable_list()
> to free the list. The xl function pciassignable_list() calls
>
Hi Jan,
On 03/12/2020 10:09, Jan Beulich wrote:
On 02.12.2020 22:10, Julien Grall wrote:
On 23/11/2020 13:30, Jan Beulich wrote:
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to
On Thu, Dec 03, 2020 at 02:25:22PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> A previous patch introduced libxl_device_pci_list_free() which should be used
> by callers of libxl_device_pci_list() to properly dispose of the exported
> 'libxl_device_pci' types and the free the memory holdi
On Thu, Dec 03, 2020 at 02:25:21PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Use of this function is a very inefficient way to check whether a device
> has already been assigned.
>
> This patch adds code that saves the domain id in xenstore at the point of
> assignment, and removes it
> -Original Message-
> From: Wei Liu
> Sent: 04 December 2020 11:22
> To: p...@xen.org
> Cc: 'Wei Liu' ; xen-devel@lists.xenproject.org; 'Paul Durrant'
> ;
> 'Oleksandr Andrushchenko' ; 'Ian Jackson'
> ;
> 'Anthony PERARD'
> Subject: Re: [PATCH v5 01/23] xl / libxl: s/pcidev/pci and rem
On Thu, Dec 03, 2020 at 02:25:20PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> The code currently checks explicitly whether the device is already assigned,
> but this is actually unnecessary as assigned devices do not form part of
> the list returned by libxl_device_pci_assignable_list()
On Thu, Dec 03, 2020 at 02:25:19PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> For the purposes of re-binding a device to its previous driver
> libxl__device_pci_assignable_add() writes the driver path into xenstore.
> This path is then read back in libxl__device_pci_assignable_remove().
On Thu, Dec 03, 2020 at 02:25:18PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to hold a pointer to the device.
>
> There is already a 'pci' field in 'pci_add_state' so simply use that from
> the start. This also allows the 'pci' (#3) argument to be dropped from
> do_pci_add().
>
>
On Fri, Dec 04, 2020 at 11:19:47AM -, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 04 December 2020 11:13
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> > Oleksandr Andrushchenko
> > ; Ian Jackson ; Wei
> > Liu ; Anthony
> > P
> -Original Message-
> From: Wei Liu
> Sent: 04 December 2020 11:13
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ;
> Oleksandr Andrushchenko
> ; Ian Jackson ; Wei
> Liu ; Anthony
> PERARD
> Subject: Re: [PATCH v5 01/23] xl / libxl: s/pcidev/pci and remove
> DE
On Thu, Dec 03, 2020 at 02:25:17PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Both 'domid' and 'pci' are available in 'pci_remove_state' so there is no
> need to also pass them as separate arguments.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Oleksandr Andrushchenko
Acked-by: Wei
On Thu, Dec 03, 2020 at 02:25:16PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Simply spelling correction. Purely cosmetic fix.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Oleksandr Andrushchenko
Acked-by: Wei Liu
On Thu, Dec 03, 2020 at 02:25:15PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Other parameters, such as 'msitranslate' and 'permissive' are dealt with
> but 'rdm_policy' appears to be have been completely missed.
>
> Signed-off-by: Paul Durrant
> Reviewed-by: Oleksandr Andrushchenko
On Thu, Dec 03, 2020 at 02:25:14PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> Currently libxl__device_pci_add_xenstore() is broken in that does not
> update the domain's configuration for the first device added (which causes
> creation of the overall backend area in xenstore). This can b
On Thu, Dec 03, 2020 at 02:25:13PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> ... devices.
>
> Currently there is an assumption built into libxl__device_list() that device
> backends are fully enumarated under the '/libxl' path in xenstore. This is
> not the case for PCI backend devices
On Fri, Dec 04, 2020 at 11:13:26AM +, Wei Liu wrote:
> On Thu, Dec 03, 2020 at 02:25:12PM +, Paul Durrant wrote:
> > From: Paul Durrant
> >
> > The seemingly arbitrary use of 'pci' and 'pcidev' in the code in libxl_pci.c
> > is confusing and also compromises use of some macros used for ot
On 04.12.20 09:58, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -197,28 +235,12 @@ static struct hypfs_entry *hypfs_get_entry_rel(struct
hypfs_entry_dir *dir,
end = strchr(path, '\0');
name_len = end - path;
-again = false;
+entry =
On Thu, Dec 03, 2020 at 02:25:12PM +, Paul Durrant wrote:
> From: Paul Durrant
>
> The seemingly arbitrary use of 'pci' and 'pcidev' in the code in libxl_pci.c
> is confusing and also compromises use of some macros used for other device
> types. Indeed it seems that DEFINE_DEVICE_TYPE_STRUCT_
On Wed, Dec 02, 2020 at 01:06:46AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Dec 01, 2020 at 01:40:10AM +0900, Keith Busch wrote:
> > On Sun, Nov 29, 2020 at 04:56:39AM +0100, Marek Marczykowski-Górecki wrote:
> > > I can reliably hit kernel panic in nvme_map_data() which looks like the
>
On 04.12.20 10:10, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -1003,12 +1006,131 @@ static struct notifier_block cpu_nfb = {
.notifier_call = cpu_callback
};
+#ifdef CONFIG_HYPFS
+static const struct hypfs_entry *cpupool_pooldir_enter(
+const struct hypfs_ent
On Thu, Dec 03, 2020 at 07:34:36AM +0100, Olaf Hering wrote:
> Currently the arguments for xenwatchdogd are hardcoded with 15s
> keep-alive interval and 30s timeout.
>
> It is not possible to tweak these values via
> /etc/systemd/system/xen-watchdog.service.d/*.conf because ExecStart
> can not be
On Thu, Dec 03, 2020 at 08:19:39AM +0100, Olaf Hering wrote:
> Am Thu, 3 Dec 2020 07:47:58 +0100
> schrieb Jürgen Groß :
>
> > Could you please add a section for XENWATCHDOGD_ARGS in
> > tools/hotplug/Linux/init.d/sysconfig.xencommons.in ?
>
> No. Such details have to go into a to-be-written xenc
On Fri, Dec 04, 2020 at 08:26:01AM -, Paul Durrant wrote:
> > -Original Message-
> > From: Jan Beulich
> > Sent: 04 December 2020 08:12
> > To: Wei Liu ; Paul Durrant
> > Cc: Paul Durrant ; xen-devel@lists.xenproject.org
> > Subject: Re: [PATCH v4 00/11] viridian: add support for ExPr
On Wed, Dec 02, 2020 at 10:05:31AM +0100, Jan Beulich wrote:
> On 30.11.2020 18:39, Diederik de Haas wrote:
> > Only spelling errors; no functional changes.
> >
> > In docs/misc/dump-core-format.txt there are a few more instances of
> > 'informations'. I'll leave that up to someone who can properl
Adjust so we uniformly avoid needlessly arranging for a continuation on
the last iteration.
Fixes: 5777a3742d88 ("IOMMU: hold page ref until after deferred TLB flush")
Signed-off-by: Jan Beulich
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -854,8 +854,9 @@ int xenmem_add_to_physmap(str
On Tue, Nov 24, 2020 at 08:27:21PM -0800, Stefano Stabellini wrote:
> Hi all,
>
> This series does a few things:
>
> 1) it introduces a simple Xen arm64 dom0less smoke test based on QEMU
> 2) it introduces alpine linux builds x86 and arm64
> 3) it introduces two tests artifacts containers
> 4) it
On Tue, Nov 24, 2020 at 08:27:34PM -0800, Stefano Stabellini wrote:
> Use QEMU to start Xen (just the hypervisor) up until it stops because
> there is no dom0 kernel to boot.
>
> It is based on the existing build job unstable-arm64v8.
>
> Also use make -j$(nproc) to build Xen.
>
> Signed-off-by:
On Tue, Dec 01, 2020 at 02:09:40PM -, Paul Durrant wrote:
> Wei,
>
> I'll likely send a v4 to address the style nit Jan picked up in patch #1
> but the rest should be stable now. Could you have a look over it?
I've only been able to skim-read this patch set, but I agree in general
that add
flight 157200 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157200/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 02.12.2020 19:31, Julien Grall wrote:
> On 05/11/2020 15:55, Jan Beulich wrote:
>> This array can be large when many grant frames are permitted; avoid
>> allocating it when it's not going to be used anyway.
>
> Given there are not many users of grant-table v2, would it make sense to
> avoid a
On 04.12.2020 10:29, Julien Grall wrote:
> On 03/12/2020 09:39, Jan Beulich wrote:
>> On 02.12.2020 18:35, Julien Grall wrote:
>>> On 02/12/2020 14:50, Jan Beulich wrote:
xen/mm.h has heavy dependencies, while in a number of cases only these
type definitions are needed. This separation th
On 04.12.2020 09:22, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 04 December 2020 07:53
>>
>> On 03.12.2020 18:07, Paul Durrant wrote:
From: Jan Beulich
Sent: 03 December 2020 15:57
... this sound to me more like workarounds for buggy guests than
functionality the h
flight 157195 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157195/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Jan,
On 03/12/2020 09:39, Jan Beulich wrote:
On 02.12.2020 18:35, Julien Grall wrote:
On 02/12/2020 14:50, Jan Beulich wrote:
xen/mm.h has heavy dependencies, while in a number of cases only these
type definitions are needed. This separation then also allows pulling in
these definitions whe
1 - 100 of 125 matches
Mail list logo
