On 29.05.20 04:24, Boris Ostrovsky wrote:
Information printed under verbose_request is clearly used for debugging
only. Remove it and use dev_dbg() instead.
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Juergen
Information printed under verbose_request is clearly used for debugging
only. Remove it and use dev_dbg() instead.
Signed-off-by: Boris Ostrovsky
---
drivers/pci/xen-pcifront.c | 27 +-
drivers/xen/xen-pciback/conf_space.c| 14
drivers/xe
flight 150423 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-build fail in 150410 REGR. vs. 150294
Tests which are faili
A recalculation NPT fault doesn't always require additional handling
in hvm_hap_nested_page_fault(), moreover in general case if there is no
explicit handling done there - the fault is wrongly considered fatal.
Instead of trying to be opportunistic - use safer approach and handle
P2M recalculation
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
---
hw/core/qdev-properties.c | 21 +++--
1 file
Convert all size-related properties in BlockConf to 32bit. This will
accommodate bigger block sizes (in a followup patch). This also allows
to make them all accept size suffixes, either via DEFINE_PROP_BLOCKSIZE
or via DEFINE_PROP_SIZE32.
Also, since min_io_size is exposed to the guest by scsi a
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessarily tight, and we've seen bigger block sizes
handy at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
Add getter for size32, and use it for blocksize, too.
In its human-readable branch, it reports approximate size in
human-readable units next to the exact byte value, like the getter for
64bit size does.
Adjust the expected test output accordingly.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Bl
BlockConf includes several properties counted in bytes.
Enhance their handling in some aspects, specifically
- accept common size suffixes (k, m)
- perform consistency checks on the values
- lift the upper limit on physical_block_size and logical_block_size
Also fix the accessor for opt_io_size
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
Revi
Introduce size32 property type which handles size suffixes (k, m, g)
just like size property, but is uint32_t rather than uint64_t. It's
going to be useful for properties that are byte sizes but are inherently
32bit, like BlkConf.opt_io_size or .discard_granularity (they are
switched to this new p
It appears convenient to be able to specify physical_block_size and
logical_block_size using common size suffixes.
Teach the blocksize property setter to interpret them. Also express the
upper and lower limits in the respective units.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
---
hw/
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
To ensure these requirements are met, ad
On Thu, May 28, 2020 at 04:45:19PM -0500, Eric Blake wrote:
> On 5/28/20 4:39 PM, Roman Kagan wrote:
> > Introduce size32 property type which handles size suffixes (k, m) just
> > like size property, but is uint32_t rather than uint64_t.
>
> Does it handle 'g' as well? (even though the set of vali
On 5/28/20 4:39 PM, Roman Kagan wrote:
Add getter for size32, and use it for blocksize, too.
In its human-readable branch, it reports approximate size in
human-readable units next to the exact byte value, like the getter for
64bit size does.
Adjust the expected test output accordingly.
Signed-
On 5/28/20 4:39 PM, Roman Kagan wrote:
Convert all size-related properties in BlockConf to 32bit. This will
allow to accomodate bigger block sizes (in a followup patch).
s/allow to accomodate/accommodate/
This also allows to make them all accept size suffixes, either via
DEFINE_PROP_BLOCKSIZ
On 5/28/20 4:39 PM, Roman Kagan wrote:
It appears convenient to be able to specify physical_block_size and
logical_block_size using common size suffixes.
Teach the blocksize property setter to interpret them. Also express the
upper and lower limits in the respective units.
Signed-off-by: Roman
On 5/28/20 4:39 PM, Roman Kagan wrote:
Introduce size32 property type which handles size suffixes (k, m) just
like size property, but is uint32_t rather than uint64_t.
Does it handle 'g' as well? (even though the set of valid 32-bit sizes
with a g suffix is rather small ;)
It's going to
be
Add getter for size32, and use it for blocksize, too.
In its human-readable branch, it reports approximate size in
human-readable units next to the exact byte value, like the getter for
64bit size does.
Adjust the expected test output accordingly.
Signed-off-by: Roman Kagan
---
v6 -> v7:
- spli
It appears convenient to be able to specify physical_block_size and
logical_block_size using common size suffixes.
Teach the blocksize property setter to interpret them. Also express the
upper and lower limits in the respective units.
Signed-off-by: Roman Kagan
---
v6 -> v7:
- split out into se
Logical and physical block sizes in QEMU are limited to 32 KiB.
This appears unnecessarily tight, and we've seen bigger block sizes
handy at times.
Lift the limitation up to 2 MiB which appears to be good enough for
everybody, and matches the qcow2 cluster size limit.
Signed-off-by: Roman Kagan
The width of opt_io_size in virtio_blk_config is 32bit. However, it's
written with virtio_stw_p; this may result in value truncation, and on
big-endian systems with legacy virtio in completely bogus readings in
the guest.
Use the appropriate accessor to store it.
Signed-off-by: Roman Kagan
Revi
Introduce size32 property type which handles size suffixes (k, m) just
like size property, but is uint32_t rather than uint64_t. It's going to
be useful for properties that are byte sizes but are inherently 32bit,
like BlkConf.opt_io_size or .discard_granularity (they are switched to
this new prop
Convert all size-related properties in BlockConf to 32bit. This will
allow to accomodate bigger block sizes (in a followup patch).
This also allows to make them all accept size suffixes, either via
DEFINE_PROP_BLOCKSIZE or via DEFINE_PROP_SIZE32.
Also, since min_io_size is exposed to the guest by
Several block device properties related to blocksize configuration must
be in certain relationship WRT each other: physical block must be no
smaller than logical block; min_io_size, opt_io_size, and
discard_granularity must be a multiple of a logical block.
To ensure these requirements are met, ad
Make it easier (more visible) to maintain the limits on the blocksize
properties in sync with the respective description, by using macros both
in the code and in the description.
Signed-off-by: Roman Kagan
Reviewed-by: Eric Blake
---
v4 -> v5:
- split out into separate patch [Philippe]
hw/core
BlockConf includes several properties counted in bytes.
Enhance their handling in some aspects, specifically
- accept common size suffixes (k, m)
- perform consistency checks on the values
- lift the upper limit on physical_block_size and logical_block_size
Also fix the accessor for opt_io_size
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/tOOKE72zwIKOiT05qumgI9ey/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document.
When adding and removing CPUs to/from a pool, we can end up in a
situation where some runqueues have a lot of CPUs, while other have only
a couple of them. Even if the scheduler (namely, the load balancer)
should be capable of dealing with such a situation, it is something that
is better avoided.
In case we want to make some live changes to the configuration
of (typically) the scheduler of a cpupool, we need things to be
quiet in that pool.
Not necessarily like with stop machine, but we at least need
to make sure that no domains are neither running not sitting
in the runqueues of the sched
If we need to know within which pool a particular scheduler
is working, we can do that by querying the cpupool pointer
of any of the sched_resource-s (i.e., ~ any of the CPUs)
assigned to the scheduler itself.
Basically, we pick any sched_resource that we know uses that
scheduler, and we check its
During boot, we use num_online_cpus() as an indication of how
many CPUs will end up in cpupool 0. We then decide (basing also
on the value of the boot time parameter opt_max_cpus_runqueue)
the actual number of CPUs that we want in each runqueue, in such
a way that the runqueue themselves are as bal
As it will be useful in later changes. While there, fix
the doc-comment.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Juergen Gross
---
Changes from v1:
* new patch
---
xen/common/sched/credit2.c | 35 +++
1 file chan
Hello!
Here's v2 of this series... a bit late, but technically still in time
for code-freeze, although I understand this is quite tight! :-P
Anyway, In Credit2, the CPUs are assigned to runqueues according to the
host topology. For instance, if we want per-socket runqueues (which is
the default),
Just move the big if() condition in an inline function.
No functional change intended.
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
Cc: Juergen Gross
---
xen/common/sched/credit2.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/xen/
In Credit2 CPUs (can) share runqueues, depending on the topology. For
instance, with per-socket runqueues (the default) all the CPUs that are
part of the same socket share a runqueue.
On platform with a huge number of CPUs per socket, that could be a
problem. An example is AMD EPYC2 servers, where
flight 150420 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150420/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 7 xen-boot fail in 150406 pass in 150420
test-armhf-armhf-xl-rtds 16
Hi,
On 28/05/2020 18:19, Bertrand Marquis wrote:
+
+return 0;
+}
+
int domain_kill(struct domain *d)
{
int rc = 0;
@@ -727,7 +788,10 @@ int domain_kill(struct domain *d)
if ( cpupool_move_domain(d, cpupool0) )
return -ERESTART;
for_each_vcpu ( d, v )
+
Hi Bertrand,
Thank you for the patch.
On 28/05/2020 16:25, Bertrand Marquis wrote:
At the moment on Arm, a Linux guest running with KTPI enabled will
cause the following error when a context switch happens in user mode:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
Th
On 28/05/2020 11:25, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> Introduce CONFIG_HAS_AS_CET to determine whether CET instructions are
>> supported in the assembler, and CONFIG_XEN_SHSTK as the main build option.
>>
>> Introduce cet={no-,}shstk to for a user to select whether
A gentle ping on this whole patch series.
Thanks,
Anchal
Hello,
This series fixes PM hibernation for hvm guests running on xen hypervisor.
The running guest could now be hibernated and resumed successfully at a
later time. The fixes for PM hibernation are added to block and
n
On 28/05/2020 10:50, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> UD faults never had any diagnostics printed, and the others were
>> inconsistent.
>>
>> Don't use dprintk() because identifying traps.c is actively unhelpful in the
>> message, as it is the location of the fixup
> On 28 May 2020, at 17:53, Roger Pau Monné wrote:
>
> On Thu, May 28, 2020 at 04:25:31PM +0100, Bertrand Marquis wrote:
>> At the moment on Arm, a Linux guest running with KTPI enabled will
>> cause the following error when a context switch happens in user mode:
>> (XEN) p2m.c:1890: d1v0: Fail
flight 150438 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150438/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Thu, May 28, 2020 at 04:25:31PM +0100, Bertrand Marquis wrote:
> At the moment on Arm, a Linux guest running with KTPI enabled will
> cause the following error when a context switch happens in user mode:
> (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
>
> This patch is
On 27.05.2020 21:18, Andrew Cooper wrote:
> @@ -400,6 +400,18 @@ unsigned long get_stack_trace_bottom(unsigned long sp)
> }
> }
>
> +static unsigned long get_shstk_bottom(unsigned long sp)
> +{
> +switch ( get_stack_page(sp) )
> +{
> +#ifdef CONFIG_XEN_SHSTK
> +case 0: return R
On Thu, May 28, 2020 at 02:07:38PM +0100, Andrew Cooper wrote:
> domain_crash() should always have a message which emitted even in release
> builds, so something more useful than this is presented.
>
> (XEN) domain_crash called from io.c:171
> (XEN) domain_crash called from io.c:171
> (XEN)
Paul Durrant writes ("[PATCH v2] libxl: stop libxl_domain_info() consuming
massive amounts of stack"):
> From: Paul Durrant
>
> Currently an array of 1024 xc_domaininfo_t is declared on stack. That alone
> consumes ~112k. Since libxl_domain_info() creates a new gc this patch simply
> uses it to
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader
workaround"):
> On 28/05/2020 15:53, Ian Jackson wrote:
> > It's Complicated. There are several options, but the usual ones are:
> >
> > 1. pygrub: Install some version of grub, which generates
> > /boot/grub.cfg
Jason Andryuk writes ("Re: [OSSTEST PATCH 01/38] ts-logs-capture: Cope if xl
shutdown leaves domain running for a bit"):
> My understanding is shutdown happens first when the guest stops and
> destruction happens afterward when all the resources are cleaned up.
> So your race is that the domain sh
flight 150414 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150414/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 150394
Tests which did not succeed
On Tue, May 19, 2020 at 3:03 PM Ian Jackson wrote:
>
> This seems mostly to affect buster but it could in principle affect
> earlier releases too I think.
>
> In principle it would be nice to fix this bug, and to have a proper
> test for it, but a reliable test is hard and an unreliable one is not
The following patch implements a solution to the bug occuring on Arm
with Linux with KPTI enabled during a context switch from user mode:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
This is an answer to the discussion started here:
https://lists.xenproject.org/archives/
At the moment on Arm, a Linux guest running with KTPI enabled will
cause the following error when a context switch happens in user mode:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
This patch is modifying runstate handling to map the area given by the
guest inside Xen d
From: Paul Durrant
Currently an array of 1024 xc_domaininfo_t is declared on stack. That alone
consumes ~112k. Since libxl_domain_info() creates a new gc this patch simply
uses it to allocate the array instead.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
T
Hi,
On 28/05/2020 15:53, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader
workaround"):
On 20/05/2020 15:57, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader
workaround"):
On 19/05/2020 20:02
> -Original Message-
> From: Ian Jackson
> Sent: 28 May 2020 15:57
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Wei
> Liu ; Anthony
> Perard
> Subject: Re: [PATCH] libxl: stop libxl_domain_info() consuming massive
> amounts of stack
>
> Paul Durrant writes (
Paul Durrant writes ("[PATCH] libxl: stop libxl_domain_info() consuming massive
amounts of stack"):
> From: Paul Durrant
>
> Currently an array of 1024 xc_domaininfo_t is declared on stack. That alone
> consumes ~112k.
Wow.
> Since libxl_domain_info() creates a new gc this patch simply
> uses
On Wed, 2020-05-27 at 08:17 +0200, Jan Beulich wrote:
> On 27.05.2020 00:00, Dario Faggioli wrote:
> >
> > Cache oriented runqueue organization will be the subject of another
> > patch series, and that's why I kept them out. However, that's a
> > rather
> > special case with a lot in common to SMT
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader
workaround"):
> On 20/05/2020 15:57, Ian Jackson wrote:
> > Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest
> > bootloader workaround"):
> >> On 19/05/2020 20:02, Ian Jackson wrote:
> >>>
Hello,
A couple of build fixes for Clang/LLVM. First patch was already sent,
patches #2 and #3 are new as a result of recent commits.
Thanks, Roger.
Roger Pau Monne (3):
x86/mm: do not attempt to convert _PAGE_GNTTAB to a boolean
build32: don't discard .shstrtab in linker script
clang: don
LLVM linker doesn't support discarding .shstrtab, and complains with:
ld -melf_i386_fbsd -N -T build32.lds -o reloc.lnk reloc.o
ld: error: discarding .shstrtab section is not allowed
Add an explicit .shstrtab section to the linker script after the text
section in order to make LLVM LD happy.
Sig
On 27.05.2020 21:18, Andrew Cooper wrote:
> We need to unwind up to the supervisor token. See the comment for details.
>
> The use of UNLIKELY_END_SECTION in this case highlights that it isn't safe
> when it isn't the final statement of an asm(). Adjust all declarations with a
> newline.
That's
Clang doesn't support attribute error, and the possible equivalents
like diagnose_if don't seem to work well in this case as they trigger
when when the function is not called (just by being used by the
APPEND_CALL macro).
Define nocall to a noop on clang until a proper solution can be found.
Sign
Clang 10 complains with:
mm.c:1239:10: error: converting the result of '<<' to a boolean always
evaluates to true
[-Werror,-Wtautological-constant-compare]
if ( _PAGE_GNTTAB && (l1e_get_flags(l1e) & _PAGE_GNTTAB) &&
^
xen/include/asm/x86_64/page.h:161:25: note: expanded from ma
> -Original Message-
> From: Jan Beulich
> Sent: 28 May 2020 10:42
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Durrant, Paul ;
> Ian Jackson
> ; Wei Liu ; Andrew Cooper
> ; George
> Dunlap ; Julien Grall ; Stefano
> Stabellini
>
> Subject: RE: [EXTERNAL] [PATCH v6 4/5] co
On 28.05.2020 15:22, Andrew Cooper wrote:
> On 28/05/2020 13:03, Jan Beulich wrote:
>> On 27.05.2020 21:18, Andrew Cooper wrote:
>>> @@ -940,7 +944,8 @@ autogen_stubs: /* Automatically generated stubs. */
>>> entrypoint 1b
>>>
>>> /* Reserved exceptions, heading towards do_reser
On 28/05/2020 13:03, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> For now, any #CP exception or shadow stack #PF indicate a bug in Xen, but
>> attempt to recover from #CP if taken in guest context.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
> with one more
flight 150433 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Ian,
On 20/05/2020 15:57, Ian Jackson wrote:
Julien Grall writes ("Re: [OSSTEST PATCH 22/38] buster: Extend guest bootloader
workaround"):
On 19/05/2020 20:02, Ian Jackson wrote:
CC: Julien Grall
CC: Stefano Stabellini
Signed-off-by: Ian Jackson
Acked-by: Julien Grall
Thanks.
domain_crash() should always have a message which emitted even in release
builds, so something more useful than this is presented.
(XEN) domain_crash called from io.c:171
(XEN) domain_crash called from io.c:171
(XEN) domain_crash called from io.c:171
...
Signed-off-by: Andrew Cooper
---
On 27.05.2020 21:18, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -769,6 +769,30 @@ void load_system_tables(void)
> tss->rsp1 = 0x8600ul;
> tss->rsp2 = 0x8600ul;
>
> + /* Set up the shadow stack IST. */
> +
On 27.05.2020 21:18, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -365,20 +365,15 @@ static void show_guest_stack(struct vcpu *v, const
> struct cpu_user_regs *regs)
> /*
> * Notes for get_stack_trace_bottom() and get_stack_dump_bottom()
> *
> - * Stack
On Tue, May 19, 2020 at 11:27:50PM +, Anchal Agarwal wrote:
> From: Munehisa Kamata
>
> S4 power transition states are much different than xen
> suspend/resume. Former is visible to the guest and frontend drivers should
> be aware of the state transitions and should be able to take appropriat
On 27.05.2020 21:18, Andrew Cooper wrote:
> For now, any #CP exception or shadow stack #PF indicate a bug in Xen, but
> attempt to recover from #CP if taken in guest context.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
with one more question and a suggestion:
> @@ -1445,8 +1447,1
From: Paul Durrant
Currently an array of 1024 xc_domaininfo_t is declared on stack. That alone
consumes ~112k. Since libxl_domain_info() creates a new gc this patch simply
uses it to allocate the array instead.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Anthony PERARD
T
flight 150419 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150419/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
> On May 27, 2020, at 12:29 PM, Wei Liu wrote:
>
> On Wed, May 27, 2020 at 11:43:16AM +0100, Anthony PERARD wrote:
>> On Tue, May 26, 2020 at 11:16:10PM +0100, George Dunlap wrote:
>>> This fixes the following build error in hvmloader:
>>>
>>> usr/include/gnu/stubs.h:7:11: fatal error: gnu/stu
flight 150413 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150413/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 150390
Tests which did not
Those are based on the upstream images and are run on an amd64 dom0.
The runvar difference is:
+test-amd64-amd64-qemuu-freebsd11-amd64 all_host_di_version 2020-02-10
+test-amd64-amd64-qemuu-freebsd12-amd64 all_host_di_version 2020-02-10
+test-amd64-amd64-qemuu-freebsd11-amd64 all_host_suite s
Hello,
The following series adds FreeBSD 11 and 12 guests tests to osstest.
ATM this is only tested on amd64, since the i386 versions had a bug.
The result can be seen at:
http://logs.test-lab.xenproject.org/osstest/logs/150428/
Note this flight has been generated without using the freebsd-{11,
Slightly adjust the code to generate the freebsd10 jobs in order to
avoid exiting early from the function if the dom0 arch is different
than i386. No functional change expected, the freebsd10 jobs are still
limited to run on an i386 dom0. No runvar diff created as part of this
change.
This is a pr
On 27.05.2020 21:18, Andrew Cooper wrote:
> Introduce CONFIG_HAS_AS_CET to determine whether CET instructions are
> supported in the assembler, and CONFIG_XEN_SHSTK as the main build option.
>
> Introduce cet={no-,}shstk to for a user to select whether or not to use shadow
> stacks at runtime, and
On 27.05.2020 21:18, Andrew Cooper wrote:
> UD faults never had any diagnostics printed, and the others were inconsistent.
>
> Don't use dprintk() because identifying traps.c is actively unhelpful in the
> message, as it is the location of the fixup, not the fault. Use the new
> vec_name() infras
On 27.05.2020 21:18, Andrew Cooper wrote:
> For one, they render the vector in a different base.
>
> Introduce X86_EXC_* constants and vec_name() to refer to exceptions by their
> mnemonic, which starts bringing the code/diagnostics in line with the Intel
> and AMD manuals.
>
> Provide constants
On 27.05.2020 19:34, Paul Durrant wrote:
> @@ -1649,6 +1650,75 @@ int continue_hypercall_on_cpu(
> return 0;
> }
>
> +static int save_shared_info(const struct domain *d, struct domain_context *c,
> +bool dry_run)
> +{
> +struct domain_shared_info_context ctxt
On Wed, 2020-05-27 at 08:22 +0200, Jan Beulich wrote:
> On 26.05.2020 23:18, Dario Faggioli wrote:
> >
> > It looks like we need a way to rebalance the runqueues, which
> > should be
> > doable... But despite having spent a couple of days trying to come
> > up
> > with something decent, that I cou
On Wed, 2020-05-27 at 06:26 +0200, Jürgen Groß wrote:
> On 27.05.20 00:00, Dario Faggioli wrote:
> >
> > Understood. Problem is that, here in the scheduling code, I don't
> > see
> > an easy way to tell when we have finished bringing up CPUs... And
> > it's
> > probably not worth looking too hard
Hi Paul,
On 27/05/2020 18:34, Paul Durrant wrote:
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: The domain may or may not be using the embedded vcpu_info array so
ultimately separate context records will be added for vcpu_info when
On Mon, May 25, 2020 at 06:00:08AM -0700, Tamas K Lengyel wrote:
> When running shallow forks, ie. VM forks without device models (QEMU), it may
> be undesirable for Xen to inject interrupts. When creating such forks from
> Windows VMs we have observed the kernel trying to process interrupts
> imme
> -Original Message-
> From: Jürgen Groß
> Sent: 28 May 2020 09:59
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Stefano Stabellini' ; 'Julien Grall'
> ; 'Wei Liu'
> ; 'Andrew Cooper' ; 'Ian Jackson'
> ;
> 'George Dunlap' ; 'Jan Beulich'
> Subject: Re: [PATCH v2] docs: updat
On 28.05.20 10:53, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Behalf Of Juergen
Gross
Sent: 28 May 2020 09:22
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ; Stefano Stabellini
; Julien Grall
; Wei Liu ; Andrew Cooper
; Ian Jackson
; George Dunlap ; Jan Beulich
On 28.05.20 10:34, Julien Grall wrote:
Hi Juergen,
On 28/05/2020 09:22, Juergen Gross wrote:
-| Field | Description |
-|-|-|
-| `conn-id` | A non-zero number used to identify this |
-
> -Original Message-
> From: Xen-devel On Behalf Of Juergen
> Gross
> Sent: 28 May 2020 09:22
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Stefano Stabellini
> ; Julien Grall
> ; Wei Liu ; Andrew Cooper
> ; Ian Jackson
> ; George Dunlap ; Jan
> Beulich
> Subject: [PATCH
> From: Jan Beulich
> Sent: Monday, May 25, 2020 11:04 PM
>
> For lbr_tsx_fixup_check() simply name a few more specific erratum
> numbers.
>
> For bdf93_fixup_check(), however, more models are affected. Oddly enough
> despite being the same model and stepping, the erratum is listed for
> Xeon E3
You may search dma_map* in drivers/gpu/drm/i915, and then print mapped
addresses to see any match in VT-d reported faulting addresses. For example,
__setup_page_dma might be one example that you want to check.
From: buy computer
Sent: Monday, May 25, 2020 1:18 PM
To: Tian, Kevin ; xen-devel@lis
Hi Juergen,
On 28/05/2020 09:22, Juergen Gross wrote:
-| Field | Description |
-|-|-|
-| `conn-id` | A non-zero number used to identify this |
-| | connection in subsequent
Update connection record details: make flags common for sockets and
domains, and add pending incoming data.
Signed-off-by: Juergen Gross
---
V2:
- added out-resp-len to connection record
---
docs/designs/xenstore-migration.md | 71 +-
1 file changed, 40 insertions(+),
> -Original Message-
> From: Roman Kagan
> Sent: 27 May 2020 13:45
> To: qemu-de...@nongnu.org
> Cc: Kevin Wolf ; xen-devel@lists.xenproject.org; Gerd
> Hoffmann ;
> Daniel P. Berrangé ; Paolo Bonzini
> ; Anthony Perard
> ; Laurent Vivier ; Max Reitz
> ; qemu-
> bl...@nongnu.org; Philip
99 matches
Mail list logo
