Wei,
On 02.12.2020 10:21, Paul Durrant wrote:
> From: Paul Durrant
>
> Paul Durrant (11):
> viridian: don't blindly write to 32-bit registers is 'mode' is invalid
> viridian: move flush hypercall implementation into separate function
> viridian: move IPI hypercall implementation into separ
> -Original Message-
> From: Jan Beulich
> Sent: 04 December 2020 07:53
> To: p...@xen.org
> Cc: 'Paul Durrant' ; 'Eslam Elnikety'
> ; 'Ian Jackson'
> ; 'Wei Liu' ; 'Anthony PERARD'
> ; 'Andrew
> Cooper' ; 'George Dunlap'
> ; 'Julien Grall'
> ; 'Stefano Stabellini' ; 'Christian
> Lindi
> -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 ExProcessorMasks
>
> Wei,
>
> On 02.12.2020 10:21, Paul Durrant wrote:
> > F
On 01.12.2020 09:21, Juergen Gross wrote:
> @@ -100,11 +112,58 @@ static void hypfs_unlock(void)
> }
> }
>
> +const struct hypfs_entry *hypfs_node_enter(const struct hypfs_entry *entry)
> +{
> +return entry;
> +}
> +
> +void hypfs_node_exit(const struct hypfs_entry *entry)
> +{
> +}
> +
On 03.12.20 16:29, Jan Beulich wrote:
On 03.12.2020 16:14, Jürgen Groß wrote:
On 03.12.20 15:59, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -100,11 +112,58 @@ static void hypfs_unlock(void)
}
}
+const struct hypfs_entry *hypfs_node_enter(const struct hypfs_en
On 04.12.20 09:30, Jan Beulich wrote:
On 01.12.2020 09:21, Juergen Gross wrote:
@@ -100,11 +112,58 @@ static void hypfs_unlock(void)
}
}
+const struct hypfs_entry *hypfs_node_enter(const struct hypfs_entry *entry)
+{
+return entry;
+}
+
+void hypfs_node_exit(const struct hypfs_en
On 03/12/2020 12:57, Rahul Singh wrote:
Hello Julien,
Hi,
On 2 Dec 2020, at 1:46 pm, Julien Grall wrote:
Hi Rahul,
On 26/11/2020 17:02, Rahul Singh wrote:
XArray is not implemented in XEN revert the patch that introduce the
XArray code in SMMUv3 driver.
Similar to the atomic revert,
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)
return entry->size;
}
+int hypfs_read_dyndir_id_entry(const struct hypfs_e
From: Paul Durrant
Paul Durrant (11):
viridian: don't blindly write to 32-bit registers if 'mode' is invalid
viridian: move flush hypercall implementation into separate function
viridian: move IPI hypercall implementation into separate function
viridian: introduce a per-cpu hypercall_vpma
From: Paul Durrant
This patch moves the implementation of HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE/LIST
that is currently inline in viridian_hypercall() into a new hvcall_flush()
function.
The new function returns Xen erro values which are then dealt with
appropriately. A return value of -ERESTART tra
From: Paul Durrant
If hvm_guest_x86_mode() returns something other than 8 or 4 then
viridian_hypercall() will return immediately but, on the way out, will write
back status as if 'mode' was 4. This patch simply makes it leave the registers
alone.
NOTE: The formatting of the 'out' label and the s
From: Paul Durrant
This patch moves the implementation of HVCALL_SEND_IPI that is currently
inline in viridian_hypercall() into a new hvcall_ipi() function.
The new function returns Xen errno values similarly to hvcall_flush(). Hence
the errno translation code in viridial_hypercall() is generali
From: Paul Durrant
... and make use of them in hvcall_flush()/need_flush().
Subsequent patches will need to deal with virtual processor masks potentially
wider than 64 bits. Thus, to avoid using too much stack, this patch
introduces global per-cpu virtual processor masks and converts the
impleme
From: Paul Durrant
A subsequent patch will need to IPI a mask of virtual processors potentially
wider than 64 bits. A previous patch introduced per-cpu hypercall_vpmask
to allow hvcall_flush() to deal with such wide masks. This patch modifies
the implementation of hvcall_ipi() to make use of the
From: Paul Durrant
vlapic_ipi() uses a softirq batching mechanism to improve the efficiency of
sending a IPIs to large number of processors. This patch modifies send_ipi()
(the worker function called by hvcall_ipi()) to also make use of the
mechanism when there multiple bits set the hypercall_vpm
From: Paul Durrant
The Microsoft Hypervisor TLFS specifies variants of the already implemented
HVCALL_FLUSH_VIRTUAL_ADDRESS_SPACE/LIST hypercalls that take a 'Virtual
Processor Set' as an argument rather than a simple 64-bit mask.
This patch adds a new hvcall_flush_ex() function to implement the
From: Paul Durrant
A previous patch introduced variants of the flush hypercalls that take a
'Virtual Processor Set' as an argument rather than a simple 64-bit mask.
This patch introduces a similar variant of the HVCALL_SEND_IPI hypercall
(HVCALL_SEND_IPI_EX).
NOTE: As with HVCALL_FLUSH_VIRTUAL_A
From: Paul Durrant
To make is simpler to observe which viridian hypercalls are issued by a
particular Windows guest, this patch adds a per-domain mask to track them.
Each type of hypercall causes a different bit to be set in the mask and
when the bit transitions from clear to set, a log line is e
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 = dir->e.funcs->findentry(dir, p
From: Paul Durrant
Adding the new value into the enumeration makes it immediately available
to xl, so this patch adjusts the xl.cfg(5) documentation accordingly.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
---
docs/man/xl.cfg.5.pod.in | 8
From: Paul Durrant
... and advertise ExProcessorMasks support if it is set.
Support is advertised by setting bit 11 in CPUID:4004:EAX.
Signed-off-by: Paul Durrant
---
Cc: Wei Liu
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: "Roger Pau Monné"
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Gral
Hi Rahul,
On 03/12/2020 14:33, Rahul Singh wrote:
On 2 Dec 2020, at 2:45 pm, Julien Grall wrote:
-
-static struct iommu_device *arm_smmu_probe_device(struct device *dev)
-{
Most of the code here looks useful to Xen. I think you want to keep the code
and re-use it afterwards.
Ok. I removed
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_entry *entry);
> +
> +static struc
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)
>>> return entry->si
Hi Jan,
On 03/12/2020 09:27, Jan Beulich wrote:
On 02.12.2020 18:14, Julien Grall wrote:
Hi Jan,
On 02/12/2020 14:49, Jan Beulich wrote:
Doing so limits what can be done in (in particular included by) this per-
arch header. Abstract out page shift/size related #define-s, which is all
the reps
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
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
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
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 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
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 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
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, 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
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 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
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 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 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 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 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 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 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 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 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: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: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: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
> -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 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
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 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: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()
> -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: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
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
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: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
>
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: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: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: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: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: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: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: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: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: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: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 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 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
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
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
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
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
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 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 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 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: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: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
> -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 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
> >
> >
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 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 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)
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
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
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 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
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
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
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
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,
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 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
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 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 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
1 - 100 of 125 matches
Mail list logo
