On 16.01.2020 18:11, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 15, 2020 at 12:02:42PM +0100, Jan Beulich wrote:
>> On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
>>> .gitignore | 1 +-
>>
>> I guess this is why various non-tool-stack maintainers have
>> bee
On 17.01.2020 04:40, Wei Xu wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1620,6 +1620,61 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL)
> DT_DEVICE_END
>
> #endif /* HAS_DEVICE_TREE */
> +
> +#ifdef CONFIG_ACPI
> +#include
> +
> +static int __i
On 16.01.2020 19:54, Andrew Cooper wrote:
> On 14/01/2020 16:12, Jan Beulich wrote:
>> On 14.01.2020 17:00, Jürgen Groß wrote:
>>> On 14.01.20 16:47, Jan Beulich wrote:
On 09.01.2020 14:48, Juergen Gross wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -81,6 +81,12 @
On 10.01.2020 18:12, Jan Beulich wrote:
> On 08.01.2020 15:08, Alexandru Stefan ISAILA wrote:
>> Changes since V6:
>> - Remove stray spaces
>> - Use ARRAY_SIZE(d->arch.altp2m_p2m) insead of MAX_ALTP2M.
>
> I'm not utterly confused:
>
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/
On 17.01.20 09:39, Jan Beulich wrote:
On 16.01.2020 19:54, Andrew Cooper wrote:
On 14/01/2020 16:12, Jan Beulich wrote:
On 14.01.2020 17:00, Jürgen Groß wrote:
On 14.01.20 16:47, Jan Beulich wrote:
On 09.01.2020 14:48, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -
On 16.01.2020 21:28, Andrew Cooper wrote:
> On 13/01/2020 16:46, Jan Beulich wrote:
>> On 13.01.2020 17:02, Andrew Cooper wrote:
>>> (Waiting for a
>>> keypress on StdIn however does work, which is how I eventually diagnosed
>>> that it was an output problem.) Skipping this logic allows debuggin
Hi Julien,
On 2020/1/7 23:12, Julien Grall wrote:
On 07/01/2020 12:55, Wei Xu wrote:
Hi Julien,
As only one entity should manage the UART (i.e Xen or Dom0), we
today assume this will be managed by Xen. Xen should expose a
partial virtual UART (only a few registers are emulating) to dom0 in
> -Original Message-
> From: Ian Jackson
> Sent: 16 January 2020 19:43
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Anthony Perard ;
> George Dunlap ; Jan Beulich ;
> jandr...@gmail.com; Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ; Wei
> Liu
On 16.01.2020 17:24, Tamas K Lengyel wrote:
> On Thu, Jan 16, 2020 at 8:47 AM Jan Beulich wrote:
>>
>> On 08.01.2020 18:13, Tamas K Lengyel wrote:
>>> Tamas K Lengyel (18):
>>> x86/hvm: introduce hvm_copy_context_and_params
>>> xen/x86: Make hap_get_allocation accessible
>>> x86/mem_sharing:
On 16.01.2020 17:12, Tamas K Lengyel wrote:
> On Thu, Jan 16, 2020 at 9:07 AM Jan Beulich wrote:
>>
>> On 08.01.2020 18:14, Tamas K Lengyel wrote:
>>> Signed-off-by: Tamas K Lengyel
>>> ---
>>> xen/arch/x86/mm/mem_sharing.c | 42 +--
>>> 1 file changed, 21 inserti
> -Original Message-
> From: Ian Jackson
> Sent: 16 January 2020 19:28
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
>
> Subject: Re: [PATCH v3 3/6] libxl: add infrastructure to track and query
> 'retired' domids
>
> Thanks. I think this is the algo
> -Original Message-
> From: Ian Jackson
> Sent: 16 January 2020 19:36
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> jandr...@gmail.co
Move __prepare_ICR{2}, apic_wait_icr_idle and
__default_send_IPI_shortcut to the top of the file, since they will be
used by send_IPI_mask in future changes.
While there, take the opportunity to remove the leading underscores,
drop the inline attribute, drop the default prefix from the shorthand
h
Hello,
The following series adds support for sending IPIs using the ALLBUT
shorthand. Patch #1 is code movement while patch #2 adds the actual
usage of the shorthand.
Thanks, Roger.
Roger Pau Monne (2):
x86/smp: move and clean APIC helpers
x86/smp: use APIC ALLBUT destination shorthand when
If the IPI destination mask matches the mask of online CPUs use the
APIC ALLBUT destination shorthand in order to send an IPI to all CPUs
on the system except the current one. This can only be safely used
when no CPU hotplug or unplug operations are taking place, no
offline CPUs or those have been
From: madhuparnabhowmi...@gmail.com
Date: Wed, 15 Jan 2020 21:25:53 +0530
> From: Madhuparna Bhowmik
>
> list_for_each_entry_rcu has built-in RCU and lock checking.
> Pass cond argument to list_for_each_entry_rcu.
>
> Signed-off-by: Madhuparna Bhowmik
Applied to net-next.
___
flight 146171 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146171/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR.
vs. 145145
Regr
On 17.01.2020 10:52, Roger Pau Monne wrote:
> Move __prepare_ICR{2}, apic_wait_icr_idle and
> __default_send_IPI_shortcut to the top of the file, since they will be
> used by send_IPI_mask in future changes.
>
> While there, take the opportunity to remove the leading underscores,
> drop the inline
This is part of upgrading our build system and import more of Linux's
one.
In Linux, subdir-y in Makefiles is only used to descend into
subdirectory when there are no object to build, Xen doesn't have that
and all subdir have object to be included in the final binary.
To allow the new syntax, the
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-v2
series is based on "[XEN PATCH v3 0/6] xen: Kconfig update with few extra"
v2:
Rather than taking Kbuild and making it work with Xen, the v2 takes the opposite
appro
From: Anthony PERARD
The use of MAX_PHYS_IRQS have been removed in cf5e6f2d3441 ("x86:
eliminate hard-coded NR_IRQS"), so remove the left over CFLAGS.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 4
1 file changed, 4 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index fcdafd0
From: Anthony PERARD
Most of the code executed by Rules.mk isn't necessary for the clean
target, especially not the CFLAGS. This make running make clean much
faster.
This extract the code into a different Makefile. It doesn't want to
include Config.mk either so variables DEPS_RM and DEPS_INCLUDE
Those targets make use of $(all_sources) which depends on TARGET_ARCH,
so we just need to set TARGET_ARCH earlier and once.
XEN_TARGET_ARCH isn't expected to change during the build, so
TARGET_SUBARCH and TARGET_ARCH aren't going to change either. Set them
once and for all in the Xen root Makefile
livepatch/Makefile seems to only be used via Rules.mk, which already
includes Config.mk, avoid the second include.
Signed-off-by: Anthony PERARD
---
xen/test/livepatch/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 82
It is unnecessary to make _tests via Rules.mk because the target
use Rules.mk as well.
Signed-off-by: Anthony PERARD
---
xen/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index 0e589de7755e..5d72d82be260 100644
--- a/xen/Makefile
From: Anthony PERARD
Collect all the clean targets as we are going to modify it shortly.
Also, this is inspired by Linux's Kbuild.
"Kbuild.include" isn't included by "Makefile", but the "_clean" target
is only used by Rules.mk which include Kbuild.include.
Signed-off-by: Anthony PERARD
---
xe
It isn't necessary to include Config.mk here because this Makefile is
only used by xen/Rules.mk which already includes Config.mk.
Signed-off-by: Anthony PERARD
---
xen/include/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/Makefile b/xen/include/Makefile
index fde0ca01
We are going to generate the CFLAGS early from "xen/Makefile" instead
of in "Rules.mk", but we need to include "config/auto.conf", so
include it in "Makefile".
Before including "config/auto.conf" we check which make target a user
is calling, as some targets don't need "auto.conf". For targets that
On 16.01.2020 18:00, Juergen Gross wrote:
> Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
> tried to fix a regression with running on rather ancient Xen versions.
> Unfortunately the fix was based on the assumption that xend would
> just use another Xenstore node, but in reali
On 17.01.2020 11:53, Anthony PERARD wrote:
> From: Anthony PERARD
>
> The use of MAX_PHYS_IRQS have been removed in cf5e6f2d3441 ("x86:
> eliminate hard-coded NR_IRQS"), so remove the left over CFLAGS.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
___
On 1/13/20 5:08 PM, Ian Jackson wrote:
> This is only for deregistration. We are going to add another variable
> for new events, with different semantics, and this overly-general name
> will become confusing.
>
> Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
__
On 1/13/20 5:08 PM, Ian Jackson wrote:
> We are going to use this a bit more widely. Make the name more
> general.
>
> Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenp
On 1/13/20 5:08 PM, Ian Jackson wrote:
> This is a very common exit pattern. We are going to want to change
> this pattern. So we should make it into a macro of its own.
>
> No functional change.
>
> Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
_
When placing memory BARs with sizes smaller than 4K multiple memory
BARs can end up mapped to the same guest physical address, and thus
won't work correctly.
Round up all memory BAR sizes to be at least 4K, so that they are
naturally aligned to a page size and thus don't end up sharing a page.
Als
Instead of generating the CFLAGS in Rules.mk everytime we enter a new
subdirectory, we are going to generate most of them a single time, and
export the result in the environment so that Rules.mk can use it. The
only flags left to generates are the one that depends on the targets,
but the variable
From: Anthony PERARD
We would like to calculate CFLAGS once and before calling Rules.mk,
so the variable CFLAGS needs to have the same value across the whole
build. Thus we need a new variable where some flags can change
depending on the target name.
Both the dependency and __OBJECT_FILE__ are s
On 16.01.2020 17:00, Igor Druzhinin wrote:
> Due to AMD and Hygon being unable to selectively trap CR4 bit modifications
> running 32-bit PV guest inside PV shim comes with significant performance
> hit. Moreover, for SMEP in particular every time CR4.SMEP changes on context
> switch to/from 32-bit
On Fri, Jan 17, 2020 at 10:12:14AM +0100, Jan Beulich wrote:
> Please note that my previous mail was _to_ George, with you only
> _cc_-ed. Hence the question was to George, not you. (It is a
> common issue which I keep mentioning on meetings that the
> distinction of To and Cc is often not being ho
We are going to want $(CFLAGS) to be static and never change during
the build, so introduce new variables that can be use to change the
flags of a single target or of a whole directory.
Those two variables are taken from Kbuild, in Linux v5.4.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk
On Thu, Jan 16, 2020 at 06:45:27PM +, Ian Jackson wrote:
> xl is maintained in practice by the libxl maintainers. The effect is
> simply to grant maintainership to Anthony.
>
> CC: Wei Liu
> CC: Anthony PERARD
> Signed-off-by: Ian Jackson
Acked-by: Anthony PERARD
--
Anthony PERARD
___
Durrant, Paul writes ("RE: [PATCH v3 3/6] libxl: add infrastructure to track
and query 'retired' domids"):
> [Ian;]
> > I'm not sure why you bother with fgets into a buffer, when you could
> > just use fscanf rather than sscanf. Your code doesn't need to take
> > much care about weird syntax whic
On 17.01.20 12:01, Jan Beulich wrote:
On 16.01.2020 18:00, Juergen Gross wrote:
Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
tried to fix a regression with running on rather ancient Xen versions.
Unfortunately the fix was based on the assumption that xend would
just use an
Durrant, Paul writes ("RE: [PATCH v3 4/6] libxl: allow creation of domains with
a specified or random domid"):
> [Ian:]
> > I think there are only two possible solutions:
> >
> > - Check the domain's entry in the recent list *after* creating
> > the domain in Xen. This involves accepting t
On 17.01.2020 12:31, Jürgen Groß wrote:
> On 17.01.20 12:01, Jan Beulich wrote:
>> On 16.01.2020 18:00, Juergen Gross wrote:
>>> Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
>>> tried to fix a regression with running on rather ancient Xen versions.
>>> Unfortunately the fix w
On 17.01.20 12:36, Jan Beulich wrote:
On 17.01.2020 12:31, Jürgen Groß wrote:
On 17.01.20 12:01, Jan Beulich wrote:
On 16.01.2020 18:00, Juergen Gross wrote:
Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
tried to fix a regression with running on rather ancient Xen version
On 1/13/20 5:08 PM, Ian Jackson wrote:
> Track in userland whether the poller pipe is nonempty. This saves us
> writing many many bytes to the pipe if nothing ever reads them.
>
> This is going to be relevant in a moment, where we are going to create
> a situation where this will happen quite a l
> -Original Message-
> From: Ian Jackson
> Sent: 17 January 2020 12:36
> To: Durrant, Paul
> Cc: xen-devel@lists.xenproject.org; Wei Liu ; Anthony Perard
> ; Andrew Cooper ;
> George Dunlap ; Jan Beulich ;
> Julien Grall ; Konrad Rzeszutek Wilk
> ; Stefano Stabellini ;
> jandr...@gmail.co
On 1/13/20 5:08 PM, Ian Jackson wrote:
> We are going to want to call this in the following situation:
>
> * We have just set up an ao, which is to call back - so a
>non-synchronous one. It ought not to call the application
>back right away, so no egc.
>
> * There is a libxl thread blo
On 1/13/20 5:08 PM, Ian Jackson wrote:
> No functional change.
>
> Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 1/13/20 5:08 PM, Ian Jackson wrote:
> If a timer event callback causes this poller to be woken (not very
> unlikely) we would go round the poll loop twice rather than once.
>
> Do the poller pipe emptying at the end; this is slightly more
> efficient because it can't cause any callbacks, so it
From: Ross Lagerwall
Otherwise it produces lots of false positives when a guest starts using
PV I/O devices.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- no changes
RFC --> v1:
- Slightly clarified the commit message
---
drivers/xen/grant-table.c | 5 -
1 f
This enables to use Outline instrumentation for Xen PV kernels.
KASAN_INLINE and KASAN_VMALLOC options currently lead to boot crashes
and hence disabled.
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Fix compilation without CONFIG_XEN_PV
- Use macros for KASAN_SHADOW_START
RFC --> v1:
- New fun
It is incorrect to call pmd_populate_kernel() multiple times for the
same page table from inside Xen PV domains. Xen notices it during
kasan_populate_early_shadow():
(XEN) mm.c:3222:d155v0 mfn 3704b already pinned
This happens for kasan_early_shadow_pte when USE_SPLIT_PTE_PTLOCKS is
enabled.
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 instrumentation is supported at the moment.
Sergey Dyasli (2):
kasan: introduc
From: Ross Lagerwall
When KASAN (or SLUB_DEBUG) is turned on, there is a higher chance that
non-power-of-two allocations are not aligned to the next power of 2 of
the size. Therefore, handle grant copies that cross page boundaries.
Signed-off-by: Ross Lagerwall
Signed-off-by: Sergey Dyasli
---
On 1/10/20 1:41 PM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Sparse commit message; it might be nice (for future 'git log'
greppability) to at least mention the names of the functions being added.
+/*
+ * Functions to clean Error **errp: call c
No functional changes.
Requested-by: Jan Beulich
Signed-off-by: Alexandru Isaila
Reviewed-by: Jan Beulich
---
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/
This patch aims to sanitize indexes, potentially guest provided
values, for altp2m_eptp[] and altp2m_p2m[] arrays.
Requested-by: Jan Beulich
Signed-off-by: Alexandru Isaila
Acked-by: Tamas K Lengyel
---
CC: Razvan Cojocaru
CC: Tamas K Lengyel
CC: Petre Pircalabu
CC: George Dunlap
CC: Jan Be
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 break in case
of a error and it is doing a best effort for setting the bits in the
given range. A check for co
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
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Wei Liu
CC:
On 1/13/20 5:08 PM, Ian Jackson wrote:
> If the application calls libxl with ao_how==0 and also makes calls
> like _occurred, libxl will sometimes get stuck.
>
> The bug happens as follows (for example):
>
> Thread A
>libxl_do_thing(,ao_how==0)
>libxl_do_thing starts, sets up so
On 1/13/20 5:08 PM, Ian Jackson wrote:
> If the application uses libxl_osevent_beforepoll, a similar hang is
> possible to the one described and fixed in
>libxl: event: Fix hang when mixing blocking and eventy calls
> Application behaviour would have to be fairly unusual, but it
> doesn't seem
On Sat, Jan 04, 2020 at 10:24:37PM +1000, Andrew wrote:
> Hi Anthony,
>
>
> I have been trying to keep an eye on the mailing list, but I might have
> missed it. Do you mind if I ask if you had any luck with the below (and/or
> if there is a subject line or content I should be keeping an eye on to
On 1/13/20 5:08 PM, Ian Jackson wrote:
> The meat here, including a description of the bug, is in:
> libxl: event: Fix hang when mixing blocking and eventy calls
>
> Re v1 I wrote:
> I suggest we try to convince ourselves of its correctness
> via a second round of code review.
>
> I put thi
George Dunlap writes ("Re: [PATCH v2 07/10] libxl: event: poller pipe
optimisation"):
> On 1/13/20 5:08 PM, Ian Jackson wrote:
> > squash! libxl: event: poller pipe optimisation
>
> Stray "squash" detrius.
Oops.
> Other than that:
>
> Reviewed-by: George Dunlap
Thanks, fixed.
Ian.
George Dunlap writes ("Re: [PATCH v2 05/10] libxl: event: Make
libxl__poller_wakeup take a gc, not an egc"):
> On 1/13/20 5:08 PM, Ian Jackson wrote:
> > We are going to want to call this in the following situation:
> >
> > * We have just set up an ao, which is to call back - so a
> >non-syn
On 1/17/20 1:46 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 05/10] libxl: event: Make
> libxl__poller_wakeup take a gc, not an egc"):
>> On 1/13/20 5:08 PM, Ian Jackson wrote:
>>> We are going to want to call this in the following situation:
>>>
>>> * We have just set up an ao,
Commit 3aa6c19d2f38be ("xen/balloon: Support xend-based toolstack")
tried to fix a regression with running on rather ancient Xen versions.
Unfortunately the fix was based on the assumption that xend would
just use another Xenstore node, but in reality only some downstream
versions of xend are doing
On 1/10/20 1:41 PM, Vladimir Sementsov-Ogievskiy wrote:
Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
functions with errp OUT parameter.
s/with/with an/
It has three goals:
1. Fix issue with error_fatal & error_prepend/error_append_hint: user
maybe s/&/and/ so it do
On Fri, Jan 17, 2020 at 4:15 AM Anthony PERARD
wrote:
>
> On Fri, Jan 17, 2020 at 10:12:14AM +0100, Jan Beulich wrote:
> > Please note that my previous mail was _to_ George, with you only
> > _cc_-ed. Hence the question was to George, not you. (It is a
> > common issue which I keep mentioning on m
On 1/10/20 1:41 PM, Vladimir Sementsov-Ogievskiy wrote:
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
Rather light on the commit message. If nothing else, a comment about
typical command-line usage would be helpful (yes, it's in the patch
body, but sometimes I just refer to git log).
di
George Dunlap writes ("Re: [PATCH v2 10/10] libxl: event: Move poller pipe
emptying to the end of afterpoll"):
> On 1/13/20 5:08 PM, Ian Jackson wrote:
> > If a timer event callback causes this poller to be woken (not very
> > unlikely) we would go round the poll loop twice rather than once.
> >
> > Provided this is v4 now of the series and no issues
> > were raised so far for these particular patches they can be merged
> > with your Reviewed-by.
>
> I don't think so, under the current (sufficiently) common
> understanding of the rules. See George's proposal to change to a
> model like wha
On 17.01.2020 14:31, Alexandru Stefan ISAILA wrote:
> 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 break in case
> of a error and it is doing a best
On 1/17/20 2:24 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 10/10] libxl: event: Move poller pipe
> emptying to the end of afterpoll"):
>> On 1/13/20 5:08 PM, Ian Jackson wrote:
>>> If a timer event callback causes this poller to be woken (not very
>>> unlikely) we would go round
Ian Jackson writes ("Re: [PATCH v2 10/10] libxl: event: Move poller pipe
emptying to the end of afterpoll"):
> TBH I still think this patch tidies the code up a bit.
Given you tested it with this change, and I think it makes it a bit
tidier and no less correct, I would like to keep it.
I rewrote
On 1/17/20 2:33 PM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH v2 10/10] libxl: event: Move poller pipe
> emptying to the end of afterpoll"):
>> TBH I still think this patch tidies the code up a bit.
>
> Given you tested it with this change, and I think it makes it a bit
> tidier and no
Today the Xen blkfront driver allocates memory for one struct
blkfront_ring_info for each communication ring. This structure is
statically sized for the maximum supported configuration resulting
in a size of more than 90 kB.
As the main size contributor is one array inside the struct, the
memory a
Track in userland whether the poller pipe is nonempty. This saves us
writing many many bytes to the pipe if nothing ever reads them.
This is going to be relevant in a moment, where we are going to create
a situation where this will happen quite a lot.
Signed-off-by: Ian Jackson
Reviewed-by: Geo
The meat here, including a description of the bug, is in:
libxl: event: Fix hang when mixing blocking and eventy calls
This is all now Reviewed-by and Tested-by George, so it is ready to be
committed. But I will be away for a bit soon and reverting something
of this form is probably undesirable
This seems neater. It doesn't have any significant effect because:
The poller fd wouldn't be emptied by time_occurs. It would only be
woken by time_occurs as a result of an ao completing, or by
libxl__egc_ao_cleanup_1_baton. But ...1_baton won't be called in
between (for one thing, this would v
We are going to want to call this in the following situation:
* We have just set up an ao, which is to call back - so a
non-synchronous one. It ought not to call the application
back right away, so no egc.
* There is a libxl thread blocking somewhere but it is using
using an out of da
We are going to use this a bit more widely. Make the name more
general.
Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
Tested-by: George Dunlap
---
tools/libxl/libxl.c | 4 ++--
tools/libxl/libxl_event.c| 8
tools/libxl/libxl_internal.h | 6 +++---
3 files changed
This is a very common exit pattern. We are going to want to change
this pattern. So we should make it into a macro of its own.
No functional change.
Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
Tested-by: George Dunlap
---
tools/libxl/libxl_event.c| 18 ++
tools
If the application uses libxl_osevent_beforepoll, a similar hang is
possible to the one described and fixed in
libxl: event: Fix hang when mixing blocking and eventy calls
Application behaviour would have to be fairly unusual, but it
doesn't seem sensible to just leave this latent bug.
We fix t
This is only for deregistration. We are going to add another variable
for new events, with different semantics, and this overly-general name
will become confusing.
Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
Tested-by: George Dunlap
---
tools/libxl/libxl_event.c| 8
too
If the application calls libxl with ao_how==0 and also makes calls
like _occurred, libxl will sometimes get stuck.
The bug happens as follows (for example):
Thread A
libxl_do_thing(,ao_how==0)
libxl_do_thing starts, sets up some callbacks
libxl_do_thing exit path calls AO_I
No functional change.
Signed-off-by: Ian Jackson
Reviewed-by: George Dunlap
Tested-by: George Dunlap
---
v2: Now it takes a gc, not an egc.
---
tools/libxl/libxl_event.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_event.c b/tools
We are going to want to change libxl__poller_wakeup to take a gc.
In theory there is a risk here that it would be called inappropriately
in a future patch but this seems unlikely.
Signed-off-by: Ian Jackson
Tested-by: George Dunlap
Reviewed-by: George Dunlap
---
v2: New patch
---
tools/libxl/
10.01.2020 22:41, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
> CC: Cornelia Huck
> CC: Eric Blake
> CC: Kevin Wolf
> CC: Max Reitz
> CC: Greg Kurz
> CC: Stefan Hajnoczi
> CC: Stefano Stabellini
> CC: Anthony Perard
> CC: Paul Durrant
> CC: "
On 1/17/20 7:58 AM, Sergey Dyasli wrote:
--- a/arch/x86/mm/kasan_init_64.c
+++ b/arch/x86/mm/kasan_init_64.c
@@ -13,6 +13,9 @@
#include
#include
+#include
+#include
+
#include
#include
#include
@@ -332,6 +335,11 @@ void __init kasan_early_init(void)
for (i = 0; pgta
The Intel SDM states:
"When an illegal vector value (0 to 15) is written to a LVT entry and
the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
illegal vector error, without regard to whether the mask bit is set or
whether an interrupt is actually seen on the input."
And that's
On Fri, Jan 17, 2020 at 03:39:55PM +0100, Juergen Gross wrote:
> Today the Xen blkfront driver allocates memory for one struct
> blkfront_ring_info for each communication ring. This structure is
> statically sized for the maximum supported configuration resulting
> in a size of more than 90 kB.
>
On 13.01.2020 17:02, Andrew Cooper wrote:
> First, there is a dependency tracking bug in the build system. Edits to
> xen/arch/x86/efi/efi-boot.h don't cause xen.efi to be regenerated. From
> what I can tell, the file doesn't even get recompiled, because syntax
> errors even go unnoticed.
I've j
On 17/01/2020 15:09, Roger Pau Monne wrote:
> The Intel SDM states:
>
> "When an illegal vector value (0 to 15) is written to a LVT entry and
> the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
> illegal vector error, without regard to whether the mask bit is set or
> whether a
Durrant, Paul writes ("RE: [PATCH v3 4/6] libxl: allow creation of domains with
a specified or random domid"):
> Ok, to cover all bases then it seems like checking the domid after creation
> and then destroying if it is too recent is the better option.
I think so, yes. I think the recent timest
The recorded file, unless overridden by -MQ (or -MT) is that specified
by -o, which doesn't produce correct dependencies and hence will cause
failure to re-build when included files change.
Fixes: 81ecb38b83b0 ("build: provide option to disambiguate symbol names")
Reported-by: Andrew Cooper
Signe
On 17.01.2020 16:09, Roger Pau Monne wrote:
> The Intel SDM states:
>
> "When an illegal vector value (0 to 15) is written to a LVT entry and
> the delivery mode is Fixed (bits 8-11 equal 0), the APIC may signal an
> illegal vector error, without regard to whether the mask bit is set or
> whether
If libxl_ctx_alloc() returns an error, we need to destroy the logger
that we made.
Restructure the Close() method such that it checks for each resource
to be freed and then frees it. This allows Close() to be come
idempotent, as well as to be a useful clean-up to a partially-created
context.
Sig
Signed-off-by: George Dunlap
---
The other option would be to expose the XTL logging levels and let the
caller set them somehow.
CC: Nick Rosbrook
---
tools/golang/xenlight/xenlight.go | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/golang/xenlight/xenlight.go
b/tool
1 - 100 of 155 matches
Mail list logo
