> -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;
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
> 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
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
>
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
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 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
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 |
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 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
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
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 ;
> -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
> -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:
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
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()
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
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
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
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
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
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
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 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,
> 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:
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
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 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. */
> +
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
---
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.
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
> 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:
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
> -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
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
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
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
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
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
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
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
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:
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
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)
> -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]
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
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
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
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.
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.
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:
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
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.
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:
> >>>
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
> >
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
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
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
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
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
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
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
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,
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
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:
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:
-
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.
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
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
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
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
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
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
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,
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]
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
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
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
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
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.
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
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
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 )
+
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
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
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
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
---
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,
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
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
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
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
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
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 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
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
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
99 matches
Mail list logo
