On 08.12.2020 17:49, Oleksandr wrote:
> On 08.12.20 17:24, Jan Beulich wrote:
>> On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
>>> --- a/xen/include/xen/sched.h
>>> +++ b/xen/include/xen/sched.h
>>> @@ -552,6 +552,8 @@ struct domain
>>> struct ioreq_server *server[MAX_NR_IOREQ_SERV
Hello !
> diff --git a/hw/net/ftgmac100.c b/hw/net/ftgmac100.c
> index 782ff19..fbae1f1 100644
> --- a/hw/net/ftgmac100.c
> +++ b/hw/net/ftgmac100.c
> @@ -573,7 +573,15 @@ static void ftgmac100_do_tx(FTGMAC100State *s, uint32_t
> tx_ring,
> }
>
> if (flags & FTGMAC100_
On 08.12.2020 19:13, Andrew Cooper wrote:
> On 08/12/2020 17:57, Manuel Bouyer wrote:
>> Hello,
>> for the first time I tried to boot a xen kernel from devel with
>> a NetBSD PV dom0. The kernel boots, but when the first userland prcess
>> is launched, it seems to enter a loop involving search_pre_
> -Original Message-
> From: Oleksandr
> Sent: 08 December 2020 20:17
> To: p...@xen.org
> Cc: 'Jan Beulich' ; 'Oleksandr Tyshchenko'
> ;
> 'Stefano Stabellini' ; 'Julien Grall'
> ; 'Volodymyr Babchuk'
> ; 'Andrew Cooper' ;
> 'George Dunlap'
> ; 'Ian Jackson' ; 'Wei Liu'
> ; 'Julien Gr
On 09/12/2020 07:55, Bertrand Marquis wrote:
Hi,
Hi,
I also agree with the issue on the spinlock but we have no equivalent of
something
looking like a mutex for now in Xen so this would require some major redesign
and
will take us far from the linux driver.
I agree that keeping the Xen
Hi Jan,
On 07/12/2020 10:23, Jan Beulich wrote:
On 24.11.2020 17:57, Julien Grall wrote:
On 24/11/2020 00:40, Andrew Cooper wrote:
On a totally separate point, I wonder if we'd be better off compiling
with -fgnu89-inline because I can't see any case we're we'd want the C99
inline semantics an
flight 157343 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157343/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 777e3590f154e6a8af560dd318b9465fa168db20
baseline version:
xen 5e66
On Wed, Dec 09, 2020 at 09:39:49AM +0100, Jan Beulich wrote:
> On 08.12.2020 19:13, Andrew Cooper wrote:
> > On 08/12/2020 17:57, Manuel Bouyer wrote:
> >> Hello,
> >> for the first time I tried to boot a xen kernel from devel with
> >> a NetBSD PV dom0. The kernel boots, but when the first userlan
Hi Jan,
On 03/12/2020 09:46, Jan Beulich wrote:
On 02.12.2020 20:03, Julien Grall wrote:
On 23/11/2020 13:28, Jan Beulich wrote:
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending() when v->virq_to_evtchn[]
is zero, provide suf
In case a process waits for any Xenstore action in the xenbus driver
it should be interruptible via SIGKILL.
Signed-off-by: Juergen Gross
---
drivers/xen/xenbus/xenbus_xs.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xe
On Tue, Dec 08, 2020 at 06:13:46PM +, Andrew Cooper wrote:
> On 08/12/2020 17:57, Manuel Bouyer wrote:
> > Hello,
> > for the first time I tried to boot a xen kernel from devel with
> > a NetBSD PV dom0. The kernel boots, but when the first userland prcess
> > is launched, it seems to enter a l
Hi Jan,
On 23/11/2020 13:28, Jan Beulich wrote:
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(so far by means of a barrier). To facilitate the conversion, switch to
an ordinary write locked region in e
flight 157335 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157335/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine 4 memdisk-try-append fail pass in 157327
test-armhf-armhf-xl-rtds 18
Hi Jan,
I will review this today, sorry for the delay.
Regards
Bertrand
> On 23 Nov 2020, at 15:16, Jan Beulich wrote:
>
> In a few cases we link in library-like functions when they're not
> actually needed. While we could use Kconfig options for each one
> of them, I think the better approach
Hi Jan,
> On 23 Nov 2020, at 15:20, Jan Beulich wrote:
>
> This case can occur when combining empty lists
>
> obj-y :=
> ...
> obj-y += $(empty)
>
> or
>
> obj-y := $(empty) $(empty)
>
> where (only) blanks would accumulate. This was only a latent issue until
> now, but would become an activ
Hi,
> On 23 Nov 2020, at 15:21, Jan Beulich wrote:
>
> In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
> just to avoid bloating binaries when only some arch-es and/or
> configurations need generic library routines, combine objects under lib/
> into an archive, which the li
> On 23 Nov 2020, at 15:21, Jan Beulich wrote:
>
> Build the source file always, as by putting it into an archive it still
> won't be linked into final binaries when not needed. This way possible
> build breakage will be easier to notice, and it's more consistent with
> us unconditionally buil
> On 23 Nov 2020, at 15:22, Jan Beulich wrote:
>
> ... into its own CU, to build it into an archive.
>
> Signed-off-by: Jan Beulich
> Acked-by: Julien Grall
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> xen/common/lib.c | 39 --
> xen/lib/Makef
flight 157338 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157338/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7061294be500de021bef3d4bc5218134d223315f
baseline version:
ovmf cee5b0441af39dd6f76cc
Hi Jan,
On 23/11/2020 13:29, Jan Beulich wrote:
@@ -620,7 +620,7 @@ int evtchn_close(struct domain *d1, int
long rc = 0;
again:
-spin_lock(&d1->event_lock);
+write_lock(&d1->event_lock);
if ( !port_is_valid(d1, port1) )
{
@@ -690,13 +690,11 @@ int e
On Wed, Dec 09, 2020 at 08:30:53AM +0100, Jürgen Groß wrote:
> Hey, I already suggested to use ~FEATURE for that purpose (see
> https://lore.kernel.org/lkml/f105a63d-6b51-3afb-83e0-e899ea408...@suse.com/
Great minds think alike!
:-P
> I'd rather make the syntax:
>
> ALTERNATIVE_TERNARY
>
Hi,
Sorry for jumping late in the discussion.
On 26/11/2020 11:20, 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 int
On 09.12.20 13:03, Borislav Petkov wrote:
On Wed, Dec 09, 2020 at 08:30:53AM +0100, Jürgen Groß wrote:
Hey, I already suggested to use ~FEATURE for that purpose (see
https://lore.kernel.org/lkml/f105a63d-6b51-3afb-83e0-e899ea408...@suse.com/
Great minds think alike!
:-P
I'd rather make the
On 12/9/20 5:11 AM, Juergen Gross wrote:
> In case a process waits for any Xenstore action in the xenbus driver
> it should be interruptible via SIGKILL.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
On Sun, Nov 22, 2020 at 01:44:53PM -0800, Andy Lutomirski wrote:
> On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
> >
> > On 20.11.20 12:59, Peter Zijlstra wrote:
> > > On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> > >> +static __always_inline void arch_local_irq_restore(un
On 09/12/2020 10:15, Manuel Bouyer wrote:
> On Tue, Dec 08, 2020 at 06:13:46PM +, Andrew Cooper wrote:
>> On 08/12/2020 17:57, Manuel Bouyer wrote:
>>> Hello,
>>> for the first time I tried to boot a xen kernel from devel with
>>> a NetBSD PV dom0. The kernel boots, but when the first userland
On Wed, Dec 09, 2020 at 01:28:54PM +, Andrew Cooper wrote:
>
> Pagefaults on IRET come either from stack accesses for operands (not the
> case here as Xen is otherwise working fine), or from segement selector
> loads for %cs and %ss.
>
> In this example, %ss is in the LDT, which specifically
On Wed, Dec 09, 2020 at 01:27:10PM +, Mark Rutland wrote:
> On Sun, Nov 22, 2020 at 01:44:53PM -0800, Andy Lutomirski wrote:
> > On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
> > > On 20.11.20 12:59, Peter Zijlstra wrote:
> > > > If someone were to write horrible code like:
> > > >
> > >
On 09.12.20 15:02, Mark Rutland wrote:
On Wed, Dec 09, 2020 at 01:27:10PM +, Mark Rutland wrote:
On Sun, Nov 22, 2020 at 01:44:53PM -0800, Andy Lutomirski wrote:
On Sat, Nov 21, 2020 at 10:55 PM Jürgen Groß wrote:
On 20.11.20 12:59, Peter Zijlstra wrote:
If someone were to write horrible
Hi Jan,
> On 23 Nov 2020, at 15:22, Jan Beulich wrote:
>
> ... into its own CU, for being unrelated to other things in
> common/lib.c.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> xen/common/lib.c | 14 --
> xen/lib/Makefile | 1 +
> xen/
Hi,
> On 23 Nov 2020, at 15:23, Jan Beulich wrote:
>
> Build this code into an archive, which results in not linking it into
> x86 final binaries. This saves about 1.5k of dead code.
>
> While moving the source file, take the opportunity and drop the
> pointless EXPORT_SYMBOL() and an instance
On 09.12.2020 10:53, Julien Grall wrote:
> On 03/12/2020 09:46, Jan Beulich wrote:
>> On 02.12.2020 20:03, Julien Grall wrote:
>>> On 23/11/2020 13:28, Jan Beulich wrote:
The per-vCPU virq_lock, which is being held anyway, together with there
not being any call to evtchn_port_set_pending(
Hi Jan,
> On 9 Dec 2020, at 09:41, Julien Grall wrote:
>
> Hi Jan,
>
> On 07/12/2020 10:23, Jan Beulich wrote:
>> On 24.11.2020 17:57, Julien Grall wrote:
>>> On 24/11/2020 00:40, Andrew Cooper wrote:
On a totally separate point, I wonder if we'd be better off compiling
with -fgnu89-
Hi,
> On 23 Nov 2020, at 15:24, Jan Beulich wrote:
>
> Build this code into an archive, partly paralleling bsearch().
>
> Signed-off-by: Jan Beulich
> Acked-by: Julien Grall
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> xen/common/Makefile| 1 -
> xen/lib/Makefile
On 09.12.2020 13:11, Julien Grall wrote:
> On 26/11/2020 11:20, 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 man
On 09/12/2020 13:59, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 01:28:54PM +, Andrew Cooper wrote:
>> Pagefaults on IRET come either from stack accesses for operands (not the
>> case here as Xen is otherwise working fine), or from segement selector
>> loads for %cs and %ss.
>>
>> In this ex
On 09.12.2020 12:37, Bertrand Marquis wrote:
>> On 23 Nov 2020, at 15:21, Jan Beulich wrote:
>>
>> In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
>> just to avoid bloating binaries when only some arch-es and/or
>> configurations need generic library routines, combine object
flight 157345 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157345/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f95e80d832e923046c92cd6f0b8208cec147138e
baseline version:
ovmf 7061294be500de021bef3
Hi Jan,
> On 9 Dec 2020, at 14:42, Jan Beulich wrote:
>
> On 09.12.2020 12:37, Bertrand Marquis wrote:
>>> On 23 Nov 2020, at 15:21, Jan Beulich wrote:
>>>
>>> In order to (subsequently) drop odd things like CONFIG_NEEDS_LIST_SORT
>>> just to avoid bloating binaries when only some arch-es and/
On 09.12.2020 12:33, Bertrand Marquis wrote:
> I will review this today, sorry for the delay.
Thanks for the reviews, and no problem at all. Since iirc it was
you who asked on the last community call, I wanted to point out
that despite your reviews and despite Wei's acks the series
still won't be
On 09/12/2020 14:47, Jan Beulich wrote:
On 09.12.2020 12:33, Bertrand Marquis wrote:
I will review this today, sorry for the delay.
Thanks for the reviews, and no problem at all. Since iirc it was
you who asked on the last community call, I wanted to point out
that despite your reviews and
On 09.12.2020 15:27, Bertrand Marquis wrote:
>> On 9 Dec 2020, at 09:41, Julien Grall wrote:
>> On 07/12/2020 10:23, Jan Beulich wrote:
>>> On 24.11.2020 17:57, Julien Grall wrote:
On 24/11/2020 00:40, Andrew Cooper wrote:
> On a totally separate point, I wonder if we'd be better off com
On 09.12.2020 15:51, Julien Grall wrote:
> On 09/12/2020 14:47, Jan Beulich wrote:
>> On 09.12.2020 12:33, Bertrand Marquis wrote:
>>> I will review this today, sorry for the delay.
>>
>> Thanks for the reviews, and no problem at all. Since iirc it was
>> you who asked on the last community call, I
On Sun, Nov 08, 2020 at 03:59:42PM +0100, Marek Marczykowski-Górecki wrote:
> When device is removed, backend domain (which may be a driver domain) is
> responsible for removing backend entries from xenstore. But in case of
> driver domain, it has no access to remove all of them - specifically the
Hi Jan,
> On 9 Dec 2020, at 14:54, Jan Beulich wrote:
>
> On 09.12.2020 15:27, Bertrand Marquis wrote:
>>> On 9 Dec 2020, at 09:41, Julien Grall wrote:
>>> On 07/12/2020 10:23, Jan Beulich wrote:
On 24.11.2020 17:57, Julien Grall wrote:
> On 24/11/2020 00:40, Andrew Cooper wrote:
>
On Wed, Dec 09, 2020 at 02:41:23PM +, Andrew Cooper wrote:
>
> Huh, so it is the LDT, but we're not getting as far as inspecting the
> target frame.
>
> I wonder if the LDT is set up correctly.
I guess it is, otherwise it wouldn't boot with a Xen 4.13 kernel, isn't it ?
> How about this inc
Allocate enough memory so that the returned pointer can be safely
accessed as an array of unsigned long.
The actual bitmap size in units of bytes, as returned by bitmap_size,
remains unchanged.
Signed-off-by: Olaf Hering
---
tools/libs/ctrl/xc_bitops.h | 5 -
1 file changed, 4 insertions(+)
There are no users left, xenpaging has its own variant.
The last user was removed with commit 11d0044a168994de85b9b328452292852aedc871
Signed-off-by: Olaf Hering
---
tools/libs/ctrl/xc_bitops.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/libs/ctrl/xc_bitops.h b/tools/libs/ctrl/xc_
Introduce new API to test if a fixed number of bits is clear or set,
and clear or set them all at once.
The caller has to make sure the input bitnumber is a multiply of BITS_PER_LONG.
This API avoids the loop over each bit in a known range just to see
if all of them are either clear or set.
Sign
On 09/12/2020 15:44, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 02:41:23PM +, Andrew Cooper wrote:
>> Huh, so it is the LDT, but we're not getting as far as inspecting the
>> target frame.
>>
>> I wonder if the LDT is set up correctly.
> I guess it is, otherwise it wouldn't boot with a Xen
The node specific write functions take a void user address handle as
parameter. As a write won't change the user memory use a const_void
handle instead.
This requires a new macro for casting a guest handle to a const type.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
---
V3:
- new pat
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 for moving a domain to a new granularity,
as this requi
Add /cpupool/ directories to hypfs. Those are completely
dynamic, so the related hypfs access functions need to be implemented.
Signed-off-by: Juergen Gross
---
V2:
- added const (Jan Beulich)
- call hypfs_add_dir() in helper (Dario Faggioli)
- switch locking to enter/exit callbacks
V3:
- use ge
When moving a domain between cpupools with different scheduling
granularity the sched_units of the domain need to be adjusted.
Do that by allocating new sched_units and throwing away the old ones
in sched_move_domain().
Signed-off-by: Juergen Gross
---
xen/common/sched/core.c | 121
Add a "sched-gran" entry to the per-cpupool hypfs directories.
For now make this entry read-only and let it contain one of the
strings "cpu", "core" or "socket".
Signed-off-by: Juergen Gross
---
V2:
- added const (Jan Beulich)
- modify test in cpupool_gran_read() (Jan Beulich)
---
docs/misc/hyp
Make /cpupool//sched-gran in hypfs writable. This will enable per
cpupool selectable scheduling granularity.
Writing this node is allowed only with no cpu assigned to the cpupool.
Allowed are values "cpu", "core" and "socket".
Signed-off-by: Juergen Gross
---
V2:
- test user parameters earlier (
Add some helpers to hypfs.c to support dynamic directories with a
numerical id as name.
The dynamic directory is based on a template specified by the user
allowing to use specific access functions and having a predefined
set of entries in the directory.
Signed-off-by: Juergen Gross
---
V2:
- use
In order to better support resource allocation and locking for dynamic
hypfs nodes add enter() and exit() callbacks to struct hypfs_funcs.
The enter() callback is called when entering a node during hypfs user
actions (traversing, reading or writing it), while the exit() callback
is called when lea
Add a HYPFS_VARDIR_INIT() macro for initializing such a directory
statically, taking a struct hypfs_funcs pointer as parameter additional
to those of HYPFS_DIR_INIT().
Modify HYPFS_VARSIZE_INIT() to take the function vector pointer as an
additional parameter as this will be needed for dynamical en
On Tue, Dec 08, 2020 at 05:02:50PM -0800, Stefano Stabellini wrote:
> The pipeline failed because the "fedora-gcc-debug" build failed with a
> timeout:
>
> ERROR: Job failed: execution took longer than 1h0m0s seconds
>
> given that all the other jobs passed (including the other Fedora job), I
>
This small series is meant as an example how to add further dynamical
directories to hypfs. It can be used to replace Paul's current approach
to specify ABI-features via domain create flags and replace those by
hypfs nodes.
The related libxl part could just use libxenhypfs to set the values.
This
Add support for reading fixed sized leafs and writing bool leafs in
dynamic directories with the backing variable being a member of the
structure anchored in struct hypfs_dyndir->data.
This adds the related leaf read and write functions and a helper
macro HYPFS_STRUCT_ELEM() for referencing the el
Add /domain/ directories to hypfs. Those are completely
dynamic, so the related hypfs access functions need to be implemented.
Signed-off-by: Juergen Gross
---
V3:
- new patch
---
docs/misc/hypfs-paths.pandoc | 10 +++
xen/common/Makefile | 1 +
xen/common/hypfs_dom.c | 137 +++
Add a new per-domain hypfs directory "abi-features" used to control
some feature availability. Changing the availability of a feature is
allowed only before the first activation of the domain.
The related leafs right now are "event-channel-upcall" and
"fifo-event-channels". For those bool elements
flight 157337 qemu-mainline real [real]
flight 157347 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157337/
http://logs.test-lab.xenproject.org/osstest/logs/157347/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi,
On 09/12/2020 16:16, Juergen Gross wrote:
This small series is meant as an example how to add further dynamical
directories to hypfs. It can be used to replace Paul's current approach
to specify ABI-features via domain create flags and replace those by
hypfs nodes.
This can only work if al
On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
> [...]
> >> I wonder if the LDT is set up correctly.
> > I guess it is, otherwise it wouldn't boot with a Xen 4.13 kernel, isn't it ?
>
> Well - you said you always saw it once on 4.13, which clearly shows that
> something was wonky,
The goal of this serie is to emulate coprocessor ID registers so that
Xen only publish to guest features that are supported by Xen and can
actually be used by guests.
One practical example where this is required are SVE support which is
forbidden by Xen as it is not supported, but if Linux is compi
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_MMFR5: Memory model feature registers 4 and 5
- ID_ISA6: ISA Feature register 6
Add more bitfie
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 and that are accessible to
guests.
Also define a case to catch all reserved registers that
Add support for emulation of cp15 based ID registers (on arm32 or when
running a 32bit guest on arm64).
The handlers are returning the values stored in the guest_cpuinfo
structure for known registers and RAZ for all reserved registers.
In the current status the MVFR registers are no supported.
Sig
Add support for cp10 exceptions decoding to be able to emulate the
values for MVFR0, MVFR1 and MVFR2 when TID3 bit of HSR is activated.
This is required for aarch32 guests accessing MVFR registers using
vmrs and vmsr instructions.
Signed-off-by: Bertrand Marquis
---
Changes in V2: Rebase
Changes
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 allow to guests (like AMU) or we do not
support (like S
Activate TID3 bit in HSR register when starting a guest.
This will trap all coprecessor ID registers so that we can give to guest
values corresponding to what they can actually use and mask some
features to guests even though they would be supported by the underlying
hardware (like SVE or MPAM).
S
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 know registers and is handling reserved registers as RAZ.
Signed-off-by: Bertrand Marquis
---
Changes in V2: Rebase
Changes in V3:
Fix commit
Hi Juergen,
On 09/12/2020 16:16, Juergen Gross wrote:
Add /domain/ directories to hypfs. Those are completely
dynamic, so the related hypfs access functions need to be implemented.
Signed-off-by: Juergen Gross
---
V3:
- new patch
---
docs/misc/hypfs-paths.pandoc | 10 +++
xen/common/Makefi
On Mon, Nov 23, 2020 at 04:20:52PM +0100, Jan Beulich wrote:
> This case can occur when combining empty lists
>
> obj-y :=
> ...
> obj-y += $(empty)
>
> or
>
> obj-y := $(empty) $(empty)
>
> where (only) blanks would accumulate. This was only a latent issue until
> now, but would become an acti
On 09/12/2020 16:30, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
>> [...]
I wonder if the LDT is set up correctly.
>>> I guess it is, otherwise it wouldn't boot with a Xen 4.13 kernel, isn't it ?
>> Well - you said you always saw it once on 4.13, which
On Fri, Nov 20, 2020 at 12:59:43PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> > +static __always_inline void arch_local_irq_restore(unsigned long flags)
> > +{
> > + if (!arch_irqs_disabled_flags(flags))
> > + arch_local_irq_enable();
On Wed, 9 Dec 2020, Michal Orzel wrote:
> On 09.12.2020 02:34, Stefano Stabellini wrote:
> > On Tue, 8 Dec 2020, Julien Grall wrote:
> >> On 08/12/2020 14:38, Bertrand Marquis wrote:
> >>> Hi Julien,
> >>>
> On 8 Dec 2020, at 09:47, Julien Grall wrote:
>
> Hi,
>
> On 08/12
flight 157348 ovmf real [real]
flight 157350 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/157348/
http://logs.test-lab.xenproject.org/osstest/logs/157350/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-
flight 157341 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/157341/
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-
Hello Julien,
> On 9 Dec 2020, at 9:18 am, Julien Grall wrote:
>
>
>
> On 09/12/2020 07:55, Bertrand Marquis wrote:
>> Hi,
>
> Hi,
>
>> I also agree with the issue on the spinlock but we have no equivalent of
>> something
>> looking like a mutex for now in Xen so this would require some maj
On Wed, 9 Dec 2020, Wei Liu wrote:
> On Tue, Dec 08, 2020 at 05:02:50PM -0800, Stefano Stabellini wrote:
> > The pipeline failed because the "fedora-gcc-debug" build failed with a
> > timeout:
> >
> > ERROR: Job failed: execution took longer than 1h0m0s seconds
> >
> > given that all the other j
On Wed, Dec 09 2020 at 18:15, Mark Rutland wrote:
> In arch/x86/kernel/apic/io_apic.c's timer_irq_works() we do:
>
> local_irq_save(flags);
> local_irq_enable();
>
> [ trigger an IRQ here ]
>
> local_irq_restore(flags);
>
> ... and in check_timer() we call that a number of t
On Wed, Dec 09, 2020 at 06:08:53PM +, Andrew Cooper wrote:
> On 09/12/2020 16:30, Manuel Bouyer wrote:
> > On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
> >> [...]
> I wonder if the LDT is set up correctly.
> >>> I guess it is, otherwise it wouldn't boot with a Xen 4.13 ke
Hi Oleksandr and Paul,
Sorry for jumping late in the conversation.
On 09/12/2020 09:01, Paul Durrant wrote:
-Original Message-
From: Oleksandr
Sent: 08 December 2020 20:17
To: p...@xen.org
Cc: 'Jan Beulich' ; 'Oleksandr Tyshchenko'
;
'Stefano Stabellini' ; 'Julien Grall' ;
'Volodymyr
On 09/12/2020 18:57, Manuel Bouyer wrote:
> On Wed, Dec 09, 2020 at 06:08:53PM +, Andrew Cooper wrote:
>> On 09/12/2020 16:30, Manuel Bouyer wrote:
>>> On Wed, Dec 09, 2020 at 04:00:02PM +, Andrew Cooper wrote:
[...]
>> I wonder if the LDT is set up correctly.
> I guess it is,
On Wed, 9 Dec 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 know registers and is handling reserved registers as RAZ.
>
> Signed-off-by: Bertrand Marqui
On Wed, 9 Dec 2020, Bertrand Marquis wrote:
> Add support for emulation of cp15 based ID registers (on arm32 or when
> running a 32bit guest on arm64).
> The handlers are returning the values stored in the guest_cpuinfo
> structure for known registers and RAZ for all reserved registers.
> In the cu
Hi Paul.
On 30.11.2020 11:31, Oleksandr Tyshchenko wrote:
--- a/xen/include/xen/ioreq.h
+++ b/xen/include/xen/ioreq.h
@@ -55,6 +55,20 @@ struct ioreq_server {
uint8_tbufioreq_handling;
};
+/*
+ * This should only be used when d == current->domain and it's not
On Fri, Nov 20 2020 at 12:46, Juergen Gross wrote:
> Xen PV guests don't use IST. For machine check interrupts switch to
> the same model as debug interrupts.
>
> Signed-off-by: Juergen Gross
> Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
On Fri, Nov 20 2020 at 12:46, Juergen Gross wrote:
> Xen PV guests don't use IST. For double fault interrupts switch to
> the same model as NMI.
>
> Correct a typo in a comment while copying it.
>
> Signed-off-by: Juergen Gross
> Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
On Wed, 9 Dec 2020, Bertrand Marquis wrote:
> Add support for cp10 exceptions decoding to be able to emulate the
> values for MVFR0, MVFR1 and MVFR2 when TID3 bit of HSR is activated.
> This is required for aarch32 guests accessing MVFR registers using
> vmrs and vmsr instructions.
>
> Signed-off-
On 09.12.20 20:58, Julien Grall wrote:
Hi Oleksandr and Paul,
Hi Julien, Paul.
Sorry for jumping late in the conversation.
On 09/12/2020 09:01, Paul Durrant wrote:
-Original Message-
From: Oleksandr
Sent: 08 December 2020 20:17
To: p...@xen.org
Cc: 'Jan Beulich' ; 'Oleksandr Ty
On Wed, 9 Dec 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_MMFR5: Memory model feature registers 4 a
On Wed, 9 Dec 2020, Bertrand Marquis wrote:
> 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 and that are accessible to
> guests.
>
On Wed, 9 Dec 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 a
On Wed, 9 Dec 2020, Bertrand Marquis wrote:
> Activate TID3 bit in HSR register when starting a guest.
> This will trap all coprecessor ID registers so that we can give to guest
> values corresponding to what they can actually use and mask some
> features to guests even though they would be support
On Fri, Nov 20 2020 at 12:46, Juergen Gross wrote:
> SWAPGS is used only for interrupts coming from user mode or for
> returning to user mode. So there is no reason to use the PARAVIRT
> framework, as it can easily be replaced by an ALTERNATIVE depending
> on X86_FEATURE_XENPV.
>
> There are severa
1 - 100 of 127 matches
Mail list logo
