flight 156620 linux-5.4 real [real]
flight 156676 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156620/
http://logs.test-lab.xenproject.org/osstest/logs/156676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
On 11.11.20 08:37, Jan Beulich wrote:
On 11.11.2020 08:27, Jürgen Groß wrote:
On 11.11.20 08:20, Jan Beulich wrote:
On 11.11.2020 06:49, Juergen Gross wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -61,7 +61,9 @@ static inline void evtchn_write_lock(struct evtchn
On 11.11.2020 08:27, Jürgen Groß wrote:
> On 11.11.20 08:20, Jan Beulich wrote:
>> On 11.11.2020 06:49, Juergen Gross wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -61,7 +61,9 @@ static inline void evtchn_write_lock(struct evtchn
>>> *evtchn)
>>> {
>>>
On 11.11.20 08:20, Jan Beulich wrote:
On 11.11.2020 06:49, Juergen Gross wrote:
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -61,7 +61,9 @@ static inline void evtchn_write_lock(struct evtchn *evtchn)
{
write_lock(>lock);
+#ifndef NDEBUG
On 10.11.2020 20:44, Oleksandr wrote:
>
> On 20.10.20 13:38, Paul Durrant wrote:
>
> Hi Jan, Paul
>
> Sorry for the late response.
>
>>> -Original Message-
>>> From: Jan Beulich
>>> Sent: 20 October 2020 11:05
>>> To: p...@xen.org
>>> Cc: 'Oleksandr Tyshchenko' ;
>>>
On 11.11.2020 06:49, Juergen Gross wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -61,7 +61,9 @@ static inline void evtchn_write_lock(struct evtchn *evtchn)
> {
> write_lock(>lock);
>
> +#ifndef NDEBUG
> evtchn->old_state = evtchn->state;
> +#endif
>
flight 156672 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156672/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156622
Tests which
Commit 5f2df45ead7c1195 ("xen/evtchn: rework per event channel lock")
introduced a build failure for NDEBUG builds.
Fixes: 5f2df45ead7c1195 ("xen/evtchn: rework per event channel lock")
Signed-off-by: Juergen Gross
---
xen/common/event_channel.c | 2 ++
xen/include/xen/sched.h| 2 --
2
Please don't reply.
.
Hi Oleksandr,
> -Original Message-
> From: Oleksandr
> Sent: 2020年11月11日 8:53
> To: Wei Chen ; xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Ian Jackson
> ; Wei Liu ; Anthony PERARD
> ; Julien Grall ; Stefano Stabellini
>
> Subject: Re: [PATCH V2 23/23] [RFC] libxl: Add
Christoph,
> This avoids the extra call to revalidate_disk_size in sd_rescan and
> is otherwise a no-op because the size did not change, or we are in
> the probe path.
Acked-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
flight 156667 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156667/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156622
Tests which
flight 156617 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR.
vs. 156525
On Thu, Oct 29, 2020 at 12:58 PM Stefano Stabellini
wrote:
>
> On Thu, 29 Oct 2020, Jürgen Groß wrote:
> > On 29.10.20 01:37, Stefano Stabellini wrote:
> > > On Tue, 27 Oct 2020, Elliott Mitchell wrote:
> > > > On Mon, Oct 26, 2020 at 06:44:27PM +, Julien Grall wrote:
> > > > > On 26/10/2020
flight 156659 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156659/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156622
Tests which
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On 09.11.20 08:45, Wei Chen wrote:
Hi Oleksandr,
Hi Wei
-Original Message-
From: Xen-devel On Behalf Of
Oleksandr Tyshchenko
Sent: 2020年10月16日 0:45
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Ian Jackson
; Wei Liu ; Anthony PERARD
; Julien Grall ; Stefano
flight 156608 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156608/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443
On 16.10.20 11:41, Julien Grall wrote:
Hi Jan, Julien
Sorry for the late response.
Hi Jan,
On 16/10/2020 07:29, Jan Beulich wrote:
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
@@ -1067,7 +1068,14 @@ static int __p2m_set_entry(struct p2m_domain
*p2m,
*/
if (
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-amd64
testid xen-build
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in
On Thu, Oct 29, 2020 at 12:57:58PM -0700, Stefano Stabellini wrote:
> On Thu, 29 Oct 2020, J??rgen Gro?? wrote:
> > What about having a small domain parsing the ACPI booting first and use
> > that information for booting dom0?
> >
> > That dom would be part of the Xen build and the hypervisor
flight 156642 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156642/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156622
Tests which
On Tue, Nov 10, 2020 at 10:14:21AM +0100, Christoph Hellwig wrote:
> On Wed, Nov 04, 2020 at 09:04:38AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Nov 03, 2020 at 10:46:43AM +0100, Christoph Hellwig wrote:
> > > ping?
> >
> > Hopefully this goes through. I am in the process of testing it but
On 20.10.20 13:55, Paul Durrant wrote:
Hi Paul.
Sorry for the late response.
-Original Message-
From: Oleksandr Tyshchenko
Sent: 15 October 2020 17:44
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Paul Durrant
; Jan Beulich
; Andrew Cooper ; Roger Pau Monné
; Wei
flight 156603 qemu-mainline real [real]
flight 156645 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156603/
http://logs.test-lab.xenproject.org/osstest/logs/156645/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
On 20.10.20 13:51, Paul Durrant wrote:
Hi Paul.
Sorry for the late response.
-Original Message-
From: Oleksandr Tyshchenko
Sent: 15 October 2020 17:44
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Stefano Stabellini
;
Julien Grall ; Volodymyr Babchuk ;
Andrew
On 20.10.20 13:41, Paul Durrant wrote:
Hi Paul
Sorry for the late response.
-Original Message-
From: Oleksandr Tyshchenko
Sent: 15 October 2020 17:44
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Paul Durrant
; Jan Beulich
; Andrew Cooper ; Roger Pau Monné
; Wei
flight 156628 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 156622
Tests which
On 20.10.20 13:38, Paul Durrant wrote:
Hi Jan, Paul
Sorry for the late response.
-Original Message-
From: Jan Beulich
Sent: 20 October 2020 11:05
To: p...@xen.org
Cc: 'Oleksandr Tyshchenko' ;
xen-devel@lists.xenproject.org; 'Oleksandr
Tyshchenko' ; 'Andrew Cooper'
; 'Roger Pau
We should never build something that calls this without having it.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201105175153.30489-13-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
---
stubs/xen-hw-stub.c | 4
1 file changed, 4 deletions(-)
diff
Chardev is already a typedef'ed struct.
Signed-off-by: Alex Bennée
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20201105175153.30489-12-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée
---
include/hw/xen/xen.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
flight 156611 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156611/
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
(Copy of advisory)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-351
Information leak via power sidechannel
ISSUE DESCRIPTION
=
Researchers have demonstrated using software power/energy monitoring
interfaces to
Fix the command line document to account for the default scheduler not
being credit anymore likely, and the fact that it's selectable from
Kconfig and thus different builds could end up with different default
schedulers.
Fixes: dafd936dddbd ('Make credit2 the default scheduler')
Signed-off-by:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-351
Information leak via power sidechannel
ISSUE DESCRIPTION
=
Researchers have demonstrated using software power/energy monitoring
interfaces to create covert
On 11/9/20 11:26 PM, Mauro Carvalho Chehab wrote:
> Hi Jonathan,
>
> Let's view ABI from the PoV of a system admin that doesn't know
> yet about a certain ABI symbol.
>
> He'll try to seek for the symbol, more likely using the HTML
> documentation. Only very senior system admins might try to
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
libxl_device_pci_dispose() on each element of the returned list, but
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
xl-pci-configuration(5).
If the 'name' field is non-NULL then both
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 is only partially filled. In this patch only the minimal
mechanical
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
'libxl_pci_bdf'.
NOTE: The OCaml bindings are adjusted to contain the
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 be easily observed
by running 'xl list -l' after adding a single device:
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 default value of 'rdm_policy' is actually 'strict', not
'relaxed', as can
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: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
docs/man/xl.1.pod.in
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 operations. To
facilitate this, a new
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
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 9 ++---
1 file changed, 6
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 holding them. Whilst all
current callers do ensure the memory is freed, only
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 documentation in
xl-pci-configuration(5).
The existing
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 arguments. The already-available COMPARE_PCI() macro can then be
used and
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 patch
will improve the documentation, once it is in its new location.
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-attach/detach'
take arguments (which will be enforced in a subsequent
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 the list of assignable
(or assigned) devices.
Signed-off-by: Paul
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_X exists solely because
of this duality.
This patch purges use of
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().
The functions that support this writing to and reading from xenstore
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 again when the device id de-assigned (or the
domain is destroyed). It is
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().
NOTE: This patch also changes the type of the 'pci_domid' field in
From: Paul Durrant
Simply spelling correction. Purely cosmetic fix.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/libs/light/libxl_pci.c
From: Paul Durrant
Remove open-coded definitions of libxl_device_nic_list() and
libxl_device_nic_list_free().
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
This patch is slightly tangential. I just happend to notice the inefficiency
while looking at code for various device
flight 156606 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156606/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0af7f8e6a9253960ba820cd6ddfd8c36543d30cb
baseline version:
ovmf
From: Paul Durrant
Remove open coded definition of libxl_device_pci_list().
NOTE: Using the macro also defines libxl_device_pci_list_free() so a prototype
for it is added. Subsequent patches will make used of it.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
---
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() and hence the
libxl_pci_assignable() test would have already failed.
From: Paul Durrant
Paul Durrant (24):
xl / libxl: s/pcidev/pci and remove DEFINE_DEVICE_TYPE_STRUCT_X
libxl: use LIBXL_DEFINE_DEVICE_LIST for pci devices
libxl: use LIBXL_DEFINE_DEVICE_LIST for nic devices
libxl: s/detatched/detached in libxl_pci.c
libxl: remove extraneous arguments to
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
---
Cc: Ian Jackson
Cc: Wei Liu
---
tools/libs/light/libxl_pci.c | 9 -
1 file changed, 4 insertions(+), 5
flight 156595 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 broken
test-amd64-i386-qemut-rhel6hvm-intel 7
On 20.10.20 10:57, Paul Durrant wrote:
Hi Paul
Sorry for the late response.
-Original Message-
From: Oleksandr Tyshchenko
Sent: 15 October 2020 17:44
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Andrew Cooper
;
George Dunlap ; Ian Jackson ;
Jan Beulich
; Julien
flight 156622 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156622/
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
A maximum extended leaf input value with the high half different from
0x8000 should not be considered valid - all leaves should be cleared in
this case.
Signed-off-by: Jan Beulich
--- a/tools/tests/cpu-policy/test-cpu-policy.c
+++ b/tools/tests/cpu-policy/test-cpu-policy.c
@@ -516,11 +516,22 @@
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-libvirt-xsm
testid guest-start
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
On 10.11.2020 14:59, Roger Pau Monné wrote:
> On Wed, Oct 28, 2020 at 10:24:53AM +0100, Jan Beulich wrote:
>> Fair parts of the present handlers are identical; in fact
>> nestedp2m_write_p2m_entry() lacks a call to p2m_entry_modify(). Move
>> common parts right into write_p2m_entry(), splitting
UNSUB xen-devel
On 10.11.2020 15:08, Roger Pau Monné wrote:
> On Tue, Nov 10, 2020 at 02:19:40PM +0100, Jan Beulich wrote:
>> On 10.11.2020 12:16, Roger Pau Monné wrote:
>>> On Tue, Nov 10, 2020 at 11:06:46AM +0100, Jan Beulich wrote:
On 10.11.2020 10:31, Roger Pau Monné wrote:
> On Fri, Oct 23, 2020 at
On Tue, Nov 10, 2020 at 02:19:40PM +0100, Jan Beulich wrote:
> On 10.11.2020 12:16, Roger Pau Monné wrote:
> > On Tue, Nov 10, 2020 at 11:06:46AM +0100, Jan Beulich wrote:
> >> On 10.11.2020 10:31, Roger Pau Monné wrote:
> >>> On Fri, Oct 23, 2020 at 10:38:04AM +0200, Jan Beulich wrote:
>
On Tue, Nov 10, 2020 at 02:21:43PM +0100, Jan Beulich wrote:
> On 10.11.2020 12:30, Roger Pau Monné wrote:
> > On Wed, Oct 28, 2020 at 10:23:42AM +0100, Jan Beulich wrote:
> >> When P2M_AUDIT is false, it's unused, so instead of having a dangling
> >> NULL pointer sit there, omit the field
On Wed, Oct 28, 2020 at 10:24:53AM +0100, Jan Beulich wrote:
> Fair parts of the present handlers are identical; in fact
> nestedp2m_write_p2m_entry() lacks a call to p2m_entry_modify(). Move
> common parts right into write_p2m_entry(), splitting the hooks into a
> "pre" one (needed just by shadow
On 10.11.2020 12:06, Roger Pau Monné wrote:
> On Wed, Oct 28, 2020 at 10:22:58AM +0100, Jan Beulich wrote:
>> @@ -1132,7 +1132,13 @@ void p2m_pt_init(struct p2m_domain *p2m)
>> p2m->recalc = do_recalc;
>> p2m->change_entry_type_global = p2m_pt_change_entry_type_global;
>>
flight 156592 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156592/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 13 debian-fixup fail REGR. vs. 156515
Tests which did not
The SDM specifically allows for earlier writes to fully overlapping
ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
would crash it if varying data was written to the same address. Detect
overlaps early, as doing so in hvmemul_{linear,phys}_mmio_access() would
be quite a bit
On 10.11.2020 12:30, Roger Pau Monné wrote:
> On Wed, Oct 28, 2020 at 10:23:42AM +0100, Jan Beulich wrote:
>> When P2M_AUDIT is false, it's unused, so instead of having a dangling
>> NULL pointer sit there, omit the field altogether.
>>
>> Instead of adding "#if P2M_AUDIT && defined(CONFIG_HVM)"
On 10.11.2020 12:16, Roger Pau Monné wrote:
> On Tue, Nov 10, 2020 at 11:06:46AM +0100, Jan Beulich wrote:
>> On 10.11.2020 10:31, Roger Pau Monné wrote:
>>> On Fri, Oct 23, 2020 at 10:38:04AM +0200, Jan Beulich wrote:
Under certain conditions CPUs can speculate into the instruction stream
On 10.11.2020 14:13, Jürgen Groß wrote:
> On 10.11.20 14:07, Andrew Cooper wrote:
>> On 10/11/2020 12:49, Roger Pau Monné wrote:
>>> On Tue, Nov 10, 2020 at 12:31:14PM +0100, Jürgen Groß wrote:
On 10.11.20 12:21, Roger Pau Monne wrote:
> Fix the command line document to account for
On 10.11.20 14:07, Andrew Cooper wrote:
On 10/11/2020 12:49, Roger Pau Monné wrote:
On Tue, Nov 10, 2020 at 12:31:14PM +0100, Jürgen Groß wrote:
On 10.11.20 12:21, Roger Pau Monne wrote:
Fix the command line document to account for credit2 now being the
default scheduler.
Fixes: dafd936dddbd
On 10/11/2020 12:49, Roger Pau Monné wrote:
> On Tue, Nov 10, 2020 at 12:31:14PM +0100, Jürgen Groß wrote:
>> On 10.11.20 12:21, Roger Pau Monne wrote:
>>> Fix the command line document to account for credit2 now being the
>>> default scheduler.
>>>
>>> Fixes: dafd936dddbd ('Make credit2 the
On Tue, Nov 10, 2020 at 12:31:14PM +0100, Jürgen Groß wrote:
> On 10.11.20 12:21, Roger Pau Monne wrote:
> > Fix the command line document to account for credit2 now being the
> > default scheduler.
> >
> > Fixes: dafd936dddbd ('Make credit2 the default scheduler')
> > Signed-off-by: Roger Pau
Hi everyone,
We got 2 potential dates for the initial tech meeting with at least one
OpenPOWER expert, so we can discuss the effort needed to port Xen on this
architecture.
Because of time zones (on OpenPower side, there's one guy in Australia), we
got 2 possible schedules in November:
1. 3pm
On 10.11.2020 11:32, Andrew Cooper wrote:
> On 10/11/2020 08:03, Jan Beulich wrote:
>> On 09.11.2020 18:38, Andrew Cooper wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -1069,6 +1069,23 @@ extern enum cpufreq_controller {
>>> FREQCTL_none,
On Wed, Oct 28, 2020 at 10:24:12AM +0100, Jan Beulich wrote:
> By latching the old MFN into a local variable, these calculations don't
> depend on anything but local variables anymore. Hence the point in time
> when they get performed doesn't matter anymore, so they can be moved
> past the locked
On 10.11.20 12:21, Roger Pau Monne wrote:
Fix the command line document to account for credit2 now being the
default scheduler.
Fixes: dafd936dddbd ('Make credit2 the default scheduler')
Signed-off-by: Roger Pau Monné
---
docs/misc/xen-command-line.pandoc | 2 +-
1 file changed, 1
On Wed, Oct 28, 2020 at 10:23:42AM +0100, Jan Beulich wrote:
> When P2M_AUDIT is false, it's unused, so instead of having a dangling
> NULL pointer sit there, omit the field altogether.
>
> Instead of adding "#if P2M_AUDIT && defined(CONFIG_HVM)" in even more
> places, fold the latter part right
Fix the command line document to account for credit2 now being the
default scheduler.
Fixes: dafd936dddbd ('Make credit2 the default scheduler')
Signed-off-by: Roger Pau Monné
---
docs/misc/xen-command-line.pandoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Tue, Nov 10, 2020 at 11:06:46AM +0100, Jan Beulich wrote:
> On 10.11.2020 10:31, Roger Pau Monné wrote:
> > On Fri, Oct 23, 2020 at 10:38:04AM +0200, Jan Beulich wrote:
> >> Under certain conditions CPUs can speculate into the instruction stream
> >> past a RET instruction. Guard against this
On Wed, Oct 28, 2020 at 10:22:58AM +0100, Jan Beulich wrote:
> The struct paging_mode instances get set to the same functions
> regardless of mode by both HAP and shadow code, hence there's no point
> having this hook there. The hook also doesn't need moving elsewhere - we
> can directly use
On 10/11/2020 08:03, Jan Beulich wrote:
> On 09.11.2020 18:38, Andrew Cooper wrote:
>> From: Roger Pau Monné
>>
>> Currently a PV hardware domain can also be given control over the CPU
>> frequency, and such guest is allowed to write to MSR_IA32_PERF_CTL.
>> However since commit 322ec7c89f6 the
On 10.11.2020 11:27, Roger Pau Monné wrote:
> On Wed, Oct 28, 2020 at 10:22:04AM +0100, Jan Beulich wrote:
>> As it gets installed by p2m_pt_init(), it doesn't need to live in
>> paging.c. The function working in terms of l1_pgentry_t even further
>> indicates its non-paging-generic nature. Move
On Wed, Oct 28, 2020 at 10:22:04AM +0100, Jan Beulich wrote:
> As it gets installed by p2m_pt_init(), it doesn't need to live in
> paging.c. The function working in terms of l1_pgentry_t even further
> indicates its non-paging-generic nature. Move it and drop its
> paging_ prefix, not adding any
On 10/11/2020 08:04, Jan Beulich wrote:
> On 09.11.2020 19:31, Roger Pau Monné wrote:
>> On Mon, Nov 09, 2020 at 05:38:19PM +, Andrew Cooper wrote:
>>> From: Roger Pau Monné
>>>
>>> Currently a PV hardware domain can also be given control over the CPU
>>> frequency, and such guest is allowed
On 10.11.2020 10:47, Julien Grall wrote:
> Hi,
>
> On 10/11/2020 07:39, Jan Beulich wrote:
>> On 09.11.2020 18:46, Julien Grall wrote:
>>> Hi,
>>>
>>> On 09/11/2020 16:48, Jan Beulich wrote:
On 09.11.2020 17:38, Juergen Gross wrote:
> Currently the lock for a single event channel needs
flight 156593 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156593/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 156399
Tests which did not
On 10.11.2020 10:31, Roger Pau Monné wrote:
> On Fri, Oct 23, 2020 at 10:38:04AM +0200, Jan Beulich wrote:
>> Under certain conditions CPUs can speculate into the instruction stream
>> past a RET instruction. Guard against this just like 3b7dab93f240
>> ("x86/spec-ctrl: Protect against CALL/JMP
flight 156594 xen-4.14-testing real [real]
flight 156615 xen-4.14-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156594/
http://logs.test-lab.xenproject.org/osstest/logs/156615/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
Hi,
On 10/11/2020 07:39, Jan Beulich wrote:
On 09.11.2020 18:46, Julien Grall wrote:
Hi,
On 09/11/2020 16:48, Jan Beulich wrote:
On 09.11.2020 17:38, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some
> -Original Message-
> From: Julien Grall
> Sent: Monday, November 9, 2020 8:04 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org
> Cc: Andre Przywara ; Bertrand Marquis
> ; Wei Chen ; Kaly Xin
> ; nd
> Subject: Re: [PATCH] xen/arm: Add Cortex-A73 erratum
1 - 100 of 105 matches
Mail list logo
