Move sched*c and cpupool.c to a new directory common/sched.
Signed-off-by: Juergen Gross
---
MAINTAINERS| 8 +--
xen/common/Kconfig | 66 +-
xen/common/Makefile| 8 +--
Instead of having an own percpu-variable for private data per cpu the
generic scheduler interface for that purpose should be used.
Signed-off-by: Juergen Gross
---
xen/common/sched/sched_null.c | 89 +--
1 file changed, 60 insertions(+), 29 deletions(-)
With the idle scheduler now taking care of all cpus not in any cpupool
the special cases in the other schedulers for no cpupool associated
can be removed.
Signed-off-by: Juergen Gross
---
xen/common/sched/sched_credit.c | 7 ++-
xen/common/sched/sched_credit2.c | 30
Make use of the const qualifier more often in scheduling code.
Signed-off-by: Juergen Gross
---
xen/common/sched/cpupool.c| 2 +-
xen/common/sched/sched_arinc653.c | 4 +--
xen/common/sched/sched_credit.c | 44 +
xen/common/sched/sched_credit2.c | 52
Move all scheduler related hypervisor code to xen/common/sched/ and
do a lot of cleanups.
Juergen Gross (9):
xen/sched: move schedulers and cpupool coding to dedicated directory
xen/sched: make sched-if.h really scheduler private
xen/sched: cleanup sched.h
xen/sched: remove special cases
sched_tick_suspend() and sched_tick_resume() only call rcu related
functions, so eliminate them and do the rcu_idle_timer*() calling in
rcu_idle_[enter|exit]().
Signed-off-by: Juergen Gross
---
xen/arch/arm/domain.c | 6 +++---
xen/arch/x86/acpi/cpu_idle.c | 15 ---
Scheduling code has several places using int or bool_t instead of bool.
Switch those.
Signed-off-by: Juergen Gross
---
xen/common/sched/cpupool.c| 10 +-
xen/common/sched/sched-if.h | 2 +-
xen/common/sched/sched_arinc653.c | 8
xen/common/sched/sched_credit.c
In sched_rt there are three instances of cpumasks allocated on the
stack. Replace them by using cpumask_scratch.
Signed-off-by: Juergen Gross
---
xen/common/sched/sched_rt.c | 56 ++---
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git
There are some items in include/xen/sched.h which can be moved to
sched-if.h as they are scheduler private.
Signed-off-by: Juergen Gross
---
xen/common/sched/sched-if.h | 13 +
xen/common/sched/schedule.c | 2 +-
xen/include/xen/sched.h | 17 -
3 files changed,
include/xen/sched-if.h should be private to scheduler code, so move it
to common/sched/sched-if.h and move the remaining use cases to
cpupool.c and schedule.c.
Signed-off-by: Juergen Gross
---
xen/arch/x86/dom0_build.c| 5 +-
xen/common/domain.c |
On Tue, Dec 17, 2019 at 6:56 PM Roman Shaposhnik wrote:
>
> On Tue, Dec 17, 2019 at 5:51 PM Stefano Stabellini
> wrote:
> >
> > On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> > > On Tue, Dec 17, 2019 at 11:26 AM Stefano Stabellini
> > > wrote:
> > > >
> > > > On Tue, 17 Dec 2019, Roman
From: Paul Durrant
Date: Tue, 17 Dec 2019 13:32:18 +
> Removing the 'hotplug-status' node in netback_remove() is wrong; the script
> may not have completed. Only remove the node once the watch has fired and
> has been unregistered.
>
> Signed-off-by: Paul Durrant
Applied.
From: Paul Durrant
Date: Tue, 17 Dec 2019 13:32:17 +
> ...as the comment above the function states.
>
> The switch to Initialising at the start of the function is somewhat bogus
> as the toolstack will have set that initial state anyway. To behave
> correctly, a backend should switch to
From: Paul Durrant
Date: Tue, 17 Dec 2019 13:32:16 +
> ...of xenbus.c
>
> This is a cosmetic function re-ordering to reduce churn in a subsequent
> patch. Some style fix-up was done to make checkpatch.pl happier.
>
> No functional change.
>
> Signed-off-by: Paul Durrant
Applied.
flight 144905 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144905/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-xtf-amd64-amd64-1 72 xtf/test-hvm64-xsa-308 fail blocked in 144850
test-xtf-amd64-amd64-3 72
flight 144918 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144918/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 69ebe8280672589d8f5826f74c0fa92c103c8042
baseline version:
ovmf
When using DRAKVUF (or another system using altp2m with shadow pages similar
to what is described in
https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m),
after a breakpoint is hit the system switches to the default
unrestricted altp2m view with singlestep enabled. When the
On Tue, Dec 17, 2019 at 03:10:16PM +0100, Vitaly Kuznetsov wrote:
> Boqun Feng writes:
>
> > Similar to x86, add a new vclock_mode VCLOCK_HVCLOCK, and reuse the
> > hv_read_tsc_page() for userspace to read tsc page clocksource.
> >
> > Signed-off-by: Boqun Feng (Microsoft)
> > ---
> >
On Wed, Dec 11, 2019 at 12:41 AM Jan Beulich wrote:
>
> On 11.12.2019 09:16, Jürgen Groß wrote:
> > On 11.12.19 08:28, Jan Beulich wrote:
> >> Jürgen, Boris,
> >>
> >> I've noticed
> >>
> >> <6>clocksource: Switched to clocksource tsc
> >>
> >> as the final clocksource related boot message in a
On Tue, Dec 17, 2019 at 5:51 PM Stefano Stabellini
wrote:
>
> On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> > On Tue, Dec 17, 2019 at 11:26 AM Stefano Stabellini
> > wrote:
> > >
> > > On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> > > > On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini
> > >
flight 144914 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144914/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> On Tue, Dec 17, 2019 at 11:26 AM Stefano Stabellini
> wrote:
> >
> > On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> > > On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini
> > > wrote:
> > > >
> > > > On Tue, 17 Dec 2019, Julien Grall wrote:
> > > >
When using `ucode=scan` and if a matching module is found, the microcode
payload is maintained in an xmalloc()'d region. This is unnecessary since
the bootmap would just do. Remove the xmalloc and xfree on the microcode
module scan path.
This commit also does away with the restriction on the
Xen relies on boot modules to perform early microcode updates. This commit adds
another mode, namely "builtin" via the BUILTIN_UCODE config parameter. If set,
the Xen image itself will contain the microcode updates. Upon boot, Xen
inspects its image for microcode blobs and performs the update.
A
Decouple the microcode referencing mechanism when using GRUB to that
when using EFI. This allows us to avoid the "unspecified effect" of
using ` | scan` along xen.efi. With that, Xen can explicitly
ignore those named options when using EFI. As an added benefit,
we get a straightfoward parsing of
The main goal of this patch series is to add support for builtin microcode.
Towards that end, the series starts with a few improvements for the
documentation and parsing of the ucode= Xen command line parameter that
controls early loading of microcode (Patches 1--3), and follows with the
main
The buffer holding the microcode bits should be marked as const.
Signed-off-by: Eslam Elnikety
---
xen/arch/x86/microcode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index c878fc71ff..4616fa9d2e 100644
---
Newer distros like CentOS 8 do not have brctl available. As such, we
can't use it to configure networking anymore.
This patch will fall back to 'ip' or 'bridge' commands if brctl is not
available in the working PATH.
This would be a likely backport candidate to any version expected to be
built
flight 144912 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144912/
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 13.12.19 14:40, Andrew Cooper wrote:
On 09/12/2019 21:49, Eslam Elnikety wrote:
+
+extern const char __builtin_intel_ucode_start[],
__builtin_intel_ucode_end[];
+extern const char __builtin_amd_ucode_start[],
__builtin_amd_ucode_end[];
+#endif
+
/* By default, ucode loading is done in NMI
On Tue, Dec 17, 2019 at 11:26 AM Stefano Stabellini
wrote:
>
> On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> > On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini
> > wrote:
> > >
> > > On Tue, 17 Dec 2019, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 17/12/2019 04:39, Roman Shaposhnik
On 17/12/2019 22:41, Eslam Elnikety wrote:
> On 13.12.19 14:57, Andrew Cooper wrote:
>> On 12/12/2019 22:13, Eslam Elnikety wrote:
> Second, there is often need to couple a Xen build with a minimum
> microcode patch level. Having the microcode built within the Xen
> image
> itself
On 13.12.19 14:57, Andrew Cooper wrote:
On 12/12/2019 22:13, Eslam Elnikety wrote:
Second, there is often need to couple a Xen build with a minimum
microcode patch level. Having the microcode built within the Xen image
itself is a streamlined, natural way of achieving that.
Okay, I can accept
flight 144910 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144910/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
flight 144906 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144906/
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
gnttab_request_version() always sets the gnttab_interface variable
and the assertions to check for empty gnttab_interface is unnecessary.
The patch eliminates multiple such assertions.
Signed-off-by: Aditya Pakki
---
v1: Eliminate more BUG_ON calls, as suggested by Juergen Gross.
---
On 17/12/2019 12:38, Roger Pau Monné wrote:
>> @@ -46,25 +14,9 @@ void restore_rest_processor_state(void)
>> /* Restore full CR4 (inc MCE) now that the IDT is in place. */
>> write_cr4(mmu_cr4_features);
>>
>> -/* Recover syscall MSRs */
>> -wrmsrl(MSR_LSTAR, saved_lstar);
>> -
flight 144891 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144891/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 14 guest-saverestore fail REGR. vs. 144861
xc_dom_p2m() and dom->p2m_host[] implement a linear transform for translated
domains, but waste a substantial chunk of RAM doing so.
ARM literally never reads dom->p2m_host[] (because of the xc_dom_translated()
short circuit in xc_dom_p2m()). Drop it all.
x86 HVM does use dom->p2m_host[] for
Vastly drop xl's memory usage for HVM (x86 and ARM) guest construction.
See
https://lore.kernel.org/xen-devel/1562159202-11316-1-git-send-email-...@amazon.de/T/#u
for the origins of this work, but ultimately I think this is a far cleaner
solution to the problem.
Andrew Cooper (4):
In-guest p2m's are a concept specific to x86 PV guests. alloc_p2m_list() is
the only hook which initialises dom->p2m_guest, making
xc_dom_update_guest_p2m() a nop for non-PV guests.
Move p2m_guest into xc_dom_image_x86 and adjust alloc_p2m_list() to match.
Drop xc_dom_update_guest_p2m()
Currently, the setup_pgtable() hook is optional, but alloc_pgtable() hook is
not. Both are specific to x86 PV guests, and stubbed in various ways by the
dombuilders for translated guests (x86 HVM, ARM).
Make alloc_pgtables() optional, and drop all the stubs for translated guest
types.
No change
The two xc_dom_params structures for PV pagetables are never modified and can
live in .rodata. Reduce their scope to the alloc_pgtable_*() functions which
construct xc_dom_image_x86 appropriately.
Rename {alloc,setup}_pgtables() to {alloc,setup}_pgtables_pv() to highlight
that they are PV only,
On Tue, 17 Dec 2019, Roman Shaposhnik wrote:
> On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini
> wrote:
> >
> > On Tue, 17 Dec 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 17/12/2019 04:39, Roman Shaposhnik wrote:
> > > > On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini
> > > >
flight 144903 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On Tue, Dec 17, 2019 at 10:30 AM Stefano Stabellini
wrote:
>
> On Tue, 17 Dec 2019, Julien Grall wrote:
> > Hi,
> >
> > On 17/12/2019 04:39, Roman Shaposhnik wrote:
> > > On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini
> > > wrote:
> > > > On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> > > >
Hi Julien,
On Tue, Dec 17, 2019 at 3:30 AM Julien Grall wrote:
>
> Hi,
>
> On 17/12/2019 04:39, Roman Shaposhnik wrote:
> > On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini
> > wrote:
> >> On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> >> If I sum all the memory sizes together I get
On Tue, 17 Dec 2019, Julien Grall wrote:
> Hi,
>
> On 17/12/2019 04:39, Roman Shaposhnik wrote:
> > On Mon, Dec 16, 2019 at 6:55 PM Stefano Stabellini
> > wrote:
> > > On Mon, 16 Dec 2019, Roman Shaposhnik wrote:
> > > If I sum all the memory sizes together I get 0x3ddfd000 which is 990M.
> > >
On Tue, 17 Dec 2019, Andrei Cherechesu wrote:
> > On Mon, 16 Dec 2019, Julien Grall wrote:
> > > On 16/12/2019 23:05, Stefano Stabellini wrote:
> > > > On Mon, 16 Dec 2019, Julien Grall wrote:
> > > > > On 16/12/2019 18:02, Andrei Cherechesu wrote:
> > > > > But even with this patch, RAM in DomU
flight 144887 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 144850
Tests which did
flight 144900 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144900/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
> On Dec 17, 2019, at 9:08 AM, Sergey Dyasli wrote:
>
> This series allows to boot and run Xen PV kernels (Dom0 and DomU) with
> CONFIG_KASAN=y. It has been used internally for some time now with good
> results for finding memory corruption issues in Dom0 kernel.
>
> Only Outline
flight 144898 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144898/
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
Hi Andrei,
On 17/12/2019 17:20, Andrei Cherechesu wrote:
On Mon, 16 Dec 2019, Julien Grall wrote:
On 16/12/2019 23:05, Stefano Stabellini wrote:
On Mon, 16 Dec 2019, Julien Grall wrote:
On 16/12/2019 18:02, Andrei Cherechesu wrote:
But even with this patch, RAM in DomU is not direct mapped
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> A previous commit that removed Context.CheckOpen revealed
> an ineffectual assignent to err in Context.Cpupoolinfo, as
> there is no error return type.
>
> Since it appears that the intent is to return an error here,
> add an
On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Remove the exported global context variable, 'Ctx.' Generally, it is
> better to not export global variables for use through a Go package.
> However, there are some exceptions that can be found in the standard
> library.
>
>
On Tue, 17 Dec 2019 18:10:19 +0100 "Jürgen Groß" wrote:
> On 17.12.19 17:24, SeongJae Park wrote:
> > On Tue, 17 Dec 2019 17:13:42 +0100 "Jürgen Groß" wrote:
> >
> >> On 17.12.19 17:07, SeongJae Park wrote:
> >>> From: SeongJae Park
> >>>
> >>> 'reclaim_memory' callback can race with a driver
> On Mon, 16 Dec 2019, Julien Grall wrote:
> > On 16/12/2019 23:05, Stefano Stabellini wrote:
> > > On Mon, 16 Dec 2019, Julien Grall wrote:
> > > > On 16/12/2019 18:02, Andrei Cherechesu wrote:
> > > > But even with this patch, RAM in DomU is not direct mapped (i.e Guest
> > > > Physical
> > > >
On 17.12.19 17:24, SeongJae Park wrote:
On Tue, 17 Dec 2019 17:13:42 +0100 "Jürgen Groß" wrote:
On 17.12.19 17:07, SeongJae Park wrote:
From: SeongJae Park
'reclaim_memory' callback can race with a driver code as this callback
will be called from any memory pressure detected context. To
On 17.12.2019 16:12, Alexandru Stefan ISAILA wrote:
> @@ -4711,6 +4712,20 @@ static int do_altp2m_op(
> }
> break;
>
> +case HVMOP_altp2m_set_suppress_ve_multi:
> +if ( a.u.suppress_ve_multi.pad1 ||
> + a.u.suppress_ve_multi.first_error_code ||
> +
On 17.12.2019 16:12, Alexandru Stefan ISAILA wrote:
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -367,10 +367,11 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn,
> uint32_t nr,
> if ( altp2m_idx )
> {
> if ( altp2m_idx >= MAX_ALTP2M ||
>
Hi,
On 17/12/2019 16:37, Jan Beulich wrote:
I'm sorry for the non-threaded reply, but my mail client has
mixed up this mail with another one, so I have nothing to
properly reply to. With one stylistic issue taken care of
(blanks around the binary operator / )
Reviewed-by: Jan Beulich
The
flight 144895 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/144895/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144637
build-amd64
On 17.12.2019 17:33, Andrew Cooper wrote:
> On 17/12/2019 16:17, Jan Beulich wrote:
>> On 13.12.2019 20:04, Andrew Cooper wrote:
>>> Andrew Cooper (6):
>>> x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel()
>>> x86/suspend: Don't bother saving %cr3, %ss or flags
>>>
I'm sorry for the non-threaded reply, but my mail client has
mixed up this mail with another one, so I have nothing to
properly reply to. With one stylistic issue taken care of
(blanks around the binary operator / )
Reviewed-by: Jan Beulich
The change would be easy enough to do while committing,
On 17/12/2019 16:17, Jan Beulich wrote:
> On 13.12.2019 20:04, Andrew Cooper wrote:
>> Andrew Cooper (6):
>> x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel()
>> x86/suspend: Don't bother saving %cr3, %ss or flags
>> x86/suspend: Don't save unnecessary GPRs
>>
Hi,
On 04/12/2019 09:27, Andre Przywara wrote:
On Tue, 3 Dec 2019 16:52:45 +
Julien Grall wrote:
Hi,
On 03/12/2019 14:38, Andre Przywara wrote:
On Tue, 3 Dec 2019 11:39:58 +
Julien Grall wrote:
Hi,
(+Andre)
Hi,
@Andre, IIRC you originally added the support for sunxi in
From: SeongJae Park
I though it would be better to review separated patches, but seems it
was my mistake. As Juergen asked, merged them again and post here.
Also, dropped Roger's reviewed-by.
Thanks,
SeongJae Park
>8 ---
On Tue, 17 Dec 2019 17:13:42 +0100 "Jürgen Groß" wrote:
> On 17.12.19 17:07, SeongJae Park wrote:
> > From: SeongJae Park
> >
> > 'reclaim_memory' callback can race with a driver code as this callback
> > will be called from any memory pressure detected context. To deal with
> > the case,
Hi Hongyan,
On 17/12/2019 14:33, Hongyan Xia wrote:
The existing code assumes that the first mfn passed to the boot
allocator is mapped, which creates problems when, e.g., we do not have
a direct map, and may create other bootstrapping problems in the
future. Make it static. The size is kept
On 13.12.2019 20:04, Andrew Cooper wrote:
> Andrew Cooper (6):
> x86/suspend: Clarify and improve the behaviour of do_suspend_lowlevel()
> x86/suspend: Don't bother saving %cr3, %ss or flags
> x86/suspend: Don't save unnecessary GPRs
> x86/suspend: Restore cr4 later during resume
>
On Tue, 17 Dec 2019 09:30:32 +0100 SeongJae Park wrote:
> On Tue, 17 Dec 2019 09:16:47 +0100 "Jürgen Groß" wrote:
>
> > On 17.12.19 08:59, SeongJae Park wrote:
> > > On Tue, 17 Dec 2019 07:23:12 +0100 "Jürgen Groß" wrote:
> > >
> > >> On 16.12.19 20:48, SeongJae Park wrote:
> > >>> On on, 16
On 17.12.19 17:07, SeongJae Park wrote:
From: SeongJae Park
The 'reclaim_memory()' callback of blkback could race with
'xen_blkbk_probe()' and 'xen_blkbk_remove()'. In the case, incompletely
linked 'backend_info' and 'blkif' might be exposed to the callback, thus
result in bad results
On 17.12.19 17:07, SeongJae Park wrote:
From: SeongJae Park
'reclaim_memory' callback can race with a driver code as this callback
will be called from any memory pressure detected context. To deal with
the case, this commit adds a spinlock in the 'xenbus_device'. Whenever
'reclaim_memory'
From: SeongJae Park
The number of empty lines between functions in the xenbus.c is
inconsistent. This trivial style cleanup commit fixes the file to
consistently place only one empty line.
Acked-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/xenbus.c | 7
From: SeongJae Park
A few of static variables in blkback have 'xen_blkif_' prefix, though it
is unnecessary for static variables. This commit removes such prefixes.
Reviewed-by: Roger Pau Monné
Signed-off-by: SeongJae Park
---
drivers/block/xen-blkback/blkback.c | 37
From: SeongJae Park
The 'reclaim_memory()' callback of blkback could race with
'xen_blkbk_probe()' and 'xen_blkbk_remove()'. In the case, incompletely
linked 'backend_info' and 'blkif' might be exposed to the callback, thus
result in bad results including NULL dereference. This commit fixes
From: SeongJae Park
Each `blkif` has a free pages pool for the grant mapping. The size of
the pool starts from zero and is increased on demand while processing
the I/O requests. If current I/O requests handling is finished or 100
milliseconds has passed since last I/O requests handling, it
From: SeongJae Park
'reclaim_memory' callback can race with a driver code as this callback
will be called from any memory pressure detected context. To deal with
the case, this commit adds a spinlock in the 'xenbus_device'. Whenever
'reclaim_memory' callback is called, the lock of the device
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
utilization patterns.
From: SeongJae Park
Granting pages consumes backend system memory. In systems configured
with insufficient spare memory for those pages, it can cause a memory
pressure situation. However, finding the optimal amount of the spare
memory is challenging for large systems having dynamic resource
Andrew, Tamas thank you very much. I will improve the patch.
December 17, 2019 3:13:42 PM UTC, Andrew Cooper
пишет:
>On 17/12/2019 15:10, Tamas K Lengyel wrote:
>> On Tue, Dec 17, 2019 at 8:08 AM Tamas K Lengyel
>wrote:
>>> On Tue, Dec 17, 2019 at 7:48 AM Andrew Cooper
> wrote:
On
On Wed, Dec 18, 2019 at 02:44:51AM +1100, Steven Haigh wrote:
> Ok, if its going to be 4 spaces for each file, I can batch convert & tidy
> stuff up...
>
> The file I changed had both types, so I went with my own preference :)
>
> If it might be a better approach, I'll sort out the majority of
Hide the following information that can help identify the running Xen
binary version:
XENVER_extraversion
XENVER_compile_info
XENVER_capabilities
XENVER_changeset
XENVER_commandline
XENVER_build_id
Return a more customer friendly empty string instead of ""
which would be
Ok, if its going to be 4 spaces for each file, I can batch convert &
tidy stuff up...
The file I changed had both types, so I went with my own preference :)
If it might be a better approach, I'll sort out the majority of scripts
in that directory - and do no function changes and post a series
On Tue, Dec 17, 2019 at 01:32:17PM +, Paul Durrant wrote:
> ...as the comment above the function states.
>
> The switch to Initialising at the start of the function is somewhat bogus
> as the toolstack will have set that initial state anyway. To behave
> correctly, a backend should switch to
On Tue, Dec 17, 2019 at 01:32:16PM +, Paul Durrant wrote:
> ...of xenbus.c
>
> This is a cosmetic function re-ordering to reduce churn in a subsequent
> patch. Some style fix-up was done to make checkpatch.pl happier.
>
> No functional change.
>
> Signed-off-by: Paul Durrant
Acked-by: Wei
On Tue, Dec 17, 2019 at 01:32:18PM +, Paul Durrant wrote:
> Removing the 'hotplug-status' node in netback_remove() is wrong; the script
> may not have completed. Only remove the node once the watch has fired and
> has been unregistered.
>
> Signed-off-by: Paul Durrant
Acked-by: Wei Liu
On Tue, Dec 17, 2019 at 8:12 AM Alexandru Stefan ISAILA
wrote:
>
> This patch aims to sanitize indexes, potentially guest provided
> values, for altp2m_eptp[] and altp2m_p2m[] arrays.
>
> Signed-off-by: Alexandru Isaila
LGTM, thanks!
Acked-by: Tamas K Lengyel
> -Original Message-
> From: Xen-devel On Behalf Of
> Sergey Dyasli
> Sent: 17 December 2019 14:08
> To: xen-de...@lists.xen.org; kasan-...@googlegroups.com; linux-
> ker...@vger.kernel.org
> Cc: Juergen Gross ; Sergey Dyasli
> ; Stefano Stabellini ;
> George Dunlap ; Ross Lagerwall
> ;
At this moment the default_access param from xc_altp2m_create_view is
not used.
This patch assigns default_access to p2m->default_access at the time of
initializing a new altp2m view.
Signed-off-by: Alexandru Isaila
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
CC:
On 17/12/2019 15:10, Tamas K Lengyel wrote:
> On Tue, Dec 17, 2019 at 8:08 AM Tamas K Lengyel wrote:
>> On Tue, Dec 17, 2019 at 7:48 AM Andrew Cooper
>> wrote:
>>> On 17/12/2019 14:40, Sergey Kovalev wrote:
On break point event eight context switches occures.
With fast single
Signed-off-by: Alexandru Isaila
---
CC: Jun Nakajima
CC: Kevin Tian
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau Monné"
---
xen/arch/x86/mm/p2m-ept.c | 6 --
xen/arch/x86/mm/p2m.c | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff
By default the sve bits are not set.
This patch adds a new hypercall, xc_altp2m_set_supress_ve_multi(),
to set a range of sve bits.
The core function, p2m_set_suppress_ve_multi(), does not brake in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for
This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.
Signed-off-by: Alexandru Isaila
---
CC: Razvan Cojocaru
CC: Tamas K Lengyel
CC: Petre Pircalabu
CC: George Dunlap
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC: "Roger Pau
On Tue, Dec 17, 2019 at 8:08 AM Tamas K Lengyel wrote:
>
> On Tue, Dec 17, 2019 at 7:48 AM Andrew Cooper
> wrote:
> >
> > On 17/12/2019 14:40, Sergey Kovalev wrote:
> > > On break point event eight context switches occures.
> > >
> > > With fast single step it is possible to shorten path for
On Tue, Dec 17, 2019 at 12:26:24PM +, Andrew Cooper wrote:
> On 17/12/2019 12:18, Roger Pau Monné wrote:
> > On Tue, Dec 17, 2019 at 12:06:01PM +, Andrew Cooper wrote:
> >> On 17/12/2019 11:52, Roger Pau Monné wrote:
> >>> On Fri, Dec 13, 2019 at 07:04:32PM +, Andrew Cooper wrote:
>
On Tue, Dec 17, 2019 at 7:48 AM Andrew Cooper wrote:
>
> On 17/12/2019 14:40, Sergey Kovalev wrote:
> > On break point event eight context switches occures.
> >
> > With fast single step it is possible to shorten path for two context
> > switches
> > and gain 35% spead-up.
> >
> > Was tested on
On 17.12.2019 17:48, Andrew Cooper wrote:
On 17/12/2019 14:40, Sergey Kovalev wrote:
On break point event eight context switches occures.
With fast single step it is possible to shorten path for two context
switches
and gain 35% spead-up.
Was tested on Debian branch of Xen 4.12. See at:
On Tue, Dec 17, 2019 at 6:16 AM George Dunlap wrote:
>
> On 12/10/19 3:47 PM, Nick Rosbrook wrote:
> > From: Nick Rosbrook
> >
> > Signed-off-by: Nick Rosbrook
> > ---
> > tools/golang/xenlight/gengotypes.py | 39 +++-
> > tools/golang/xenlight/helpers.gen.go | 300
1 - 100 of 152 matches
Mail list logo
