flight 146186 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146186/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 145767
flight 146180 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146180/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs.
144758
Tests
flight 146182 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146182/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 145969
test-armhf-armhf-libvirt-raw 13
On Fri, Jan 17, 2020 at 01:57:43PM -0500, Rich Persaud wrote:
>On Sep 26, 2019, at 06:17, Pasi Kärkkäinen wrote:
>>
>> Hello Stanislav,
>>
>>> On Fri, Sep 13, 2019 at 11:28:20PM +0800, Chao Gao wrote:
On Fri, Sep 13, 2019 at 10:02:24AM +, Spassov, Stanislav wrote:
On Thu, Dec 13,
flight 146209 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146209/
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 12/18/2019 9:24 AM, Julien Grall wrote:
> Hi Jeff,
>
> On 11/12/2019 21:13, Jeff Kubascik wrote:
>> Per the ARMv8 Reference Manual (ARM DDI 0487E.a), section D11.2.4
>> specifies that the values in the TimerValue view of the timers are
>> signed in standard two's complement form. When writing
On 12/18/2019 9:20 AM, Julien Grall wrote:
> Hi Jeff,
>
> On 11/12/2019 21:13, Jeff Kubascik wrote:
>> The physical timer traps apply an offset so that time starts at 0 for
>> the guest. However, this offset is not currently applied to the physical
>> counter. Per the ARMv8 Reference Manual (ARM
On 20/12/2019 09:57, Jan Beulich wrote:
> On 19.12.2019 22:25, Eslam Elnikety wrote:
>> On 18.12.19 13:05, Jan Beulich wrote:
>>> On 18.12.2019 02:32, Eslam Elnikety wrote:
@@ -725,7 +701,7 @@ static int __init microcode_init(void)
*/
if ( ucode_blob.size )
{
For __page_tables_{start,end} and L3 bootmap initialisation, the logic is
unnecesserily complicated owing to its attempt to use the LOOP instruction,
which results in an off-by-8 memory address owing to LOOP's termination
condition.
Rewrite both loops for improved clarity and speed.
Misc notes:
... rather than presuming that 16M will do. On the EFI side, use
l2e_add_flags() to reduce the code-generation overhead of using
l2e_from_paddr() twice.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
v2:
* Drop adjustment to the linker script. There are
The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
total, which is a limit looking to be lifted.
Move l2_xenmap[] into the BSS, and adjust both the BIOS and EFI paths to fill
it in dynamically, based on the final linked size of Xen.
Signed-off-by: Andrew Cooper
---
CC:
The trampoline relocation code uses %fs for accessing Xen, and this comes with
an arbitrary 16M limitation. We could adjust the limit, but the boot code is
a confusing mix of %ds/%esi-based and %fs-based accesses, and the use of %fs
is longer to encode, and incurs an address generation overhead.
The boot/directmap pagetables, high Xen pagetables, and use of BOOT_FS all
come with arbitrary limitations to Xen's total size. Remove these limits.
Testing of the EFI build indicates that there is still an issue lurking
somewhere:
(XEN) [ Xen-4.14-unstable x86_64 debug=y Not tainted
All remaining users of sym_fs() can trivially be switched to using sym_esi()
instead. This is shorter to encode and faster to execute.
This removes the final uses of %fs during boot, which allows us to drop
BOOT_FS from the trampoline GDT, which drops an 16M arbitrary limit on Xen's
compiled
(Renaming the title to avoid confusion)
On 17/01/2020 09:06, Wei Xu wrote:
Hi Julien,
Hi Wei,
On 2020/1/7 23:12, Julien Grall wrote:
Sorry for the late reply!
Don't worry, thank you for looking into the bug!
The PC refers to fdt_num_mem_rsv during init_done.
But the
On 20.12.19 11:34, Jürgen Groß wrote:
On 20.12.19 11:12, Jan Beulich wrote:
On 19.12.2019 23:11, Eslam Elnikety wrote:
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
--- /dev/null
+++ b/xen/arch/x86/microcode/Makefile
@@ -0,0 +1,46 @@
+# Copyright (C) 2019
Hi Jan,
On 15/01/2020 10:44, Jan Beulich wrote:
On 14.01.2020 18:03, Julien Grall wrote:
On 14/01/2020 16:50, Jan Beulich wrote:
On 14.01.2020 17:26, Julien Grall wrote:
On 14/01/2020 16:08, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
--- a/xen/arch/x86/hvm/irq.c
+++
On 20.12.19 11:12, Jan Beulich wrote:
On 19.12.2019 23:11, Eslam Elnikety wrote:
On 18.12.19 13:42, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
--- /dev/null
+++ b/xen/arch/x86/microcode/Makefile
@@ -0,0 +1,46 @@
+# Copyright (C) 2019 Amazon.com, Inc. or its affiliates.
+#
Apologies,
some of the links I added for convenience do not work
> It should be read in the following order
The correct links are
*
http://xenbits.xenproject.org/gitweb/?p=people/larsk/code-of-conduct.git;a=blob;f=code-of-conduct.md;hb=refs/heads/CoC-v5
*
On Aug 26, 2019, at 17:08, Pasi Kärkkäinen wrote:
> Hi,
>
>> On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote:
>>> On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote:
>>> On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote:
On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris
Hi all,
for some time now we have been discussing the Xen Project Code of
Conduct. The most recent set of feedback has been primarily around
minor language issues (US vs UL English, etc.), which indicates to me
that the proposal is ready to be voted on
The final version which addresses all the
flight 146202 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146202/
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
Picking this up again after the break. Apologies for the delay.
On 20.12.19 10:53, Jan Beulich wrote:
On 19.12.2019 22:08, Eslam Elnikety wrote:
On 18.12.19 12:49, Jan Beulich wrote:
On 18.12.2019 02:32, Eslam Elnikety wrote:
Decouple the microcode referencing mechanism when using GRUB to
flight 146178 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146178/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
146121
Tests which did
On Sep 26, 2019, at 06:17, Pasi Kärkkäinen wrote:
>
> Hello Stanislav,
>
>> On Fri, Sep 13, 2019 at 11:28:20PM +0800, Chao Gao wrote:
>>> On Fri, Sep 13, 2019 at 10:02:24AM +, Spassov, Stanislav wrote:
>>> On Thu, Dec 13, 2018 at 07:54, Chao Gao wrote:
On Thu, Dec 13, 2018 at
On Fri, Jan 17, 2020 at 01:44:20PM -0500, Rich Persaud wrote:
> On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki
> wrote:
> > @@ -66,6 +70,7 @@ install: all
> >$(INSTALL_PROG) libxenvchan.so.$(MAJOR).$(MINOR) $(DESTDIR)$(libdir)
> >ln -sf libxenvchan.so.$(MAJOR).$(MINOR)
> >
flight 146176 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146176/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs.
On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki
wrote:
>
> diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
> index 7892750..1c845ca 100644
> --- a/tools/libvchan/Makefile
> +++ b/tools/libvchan/Makefile
> @@ -13,6 +13,7 @@ LIBVCHAN_PIC_OBJS = $(patsubst
On 1/17/20 3:57 PM, George Dunlap wrote:
> This is a sketch of functionality suitable for creating a basic
> domain, with a disk and a vif. DomainConfig, DeviceDisk, and
> DeviceNic types are all created using constructor functions, which
> initialize them with libxl's defaults.
>
>
On 1/17/20 6:13 PM, Nick Rosbrook wrote:
>> // Context represents a libxl_ctx.
>> type Context struct {
>> - ctx*C.libxl_ctx
>> - logger *C.xentoollog_logger_stdiostream
>> + ctx *C.libxl_ctx
>> + logger *C.xentoollog_logger_stdiostream
>> + sigchld
flight 146185 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146185/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
> // Context represents a libxl_ctx.
> type Context struct {
> - ctx*C.libxl_ctx
> - logger *C.xentoollog_logger_stdiostream
> + ctx *C.libxl_ctx
> + logger *C.xentoollog_logger_stdiostream
> + sigchld chan os.Signal
> + sigchldDone chan
There is already an identical comment for
libxl_osevent_register_hooks.
libxl_childproc_setmode's hooks parameter has the same property and
this should be documented.
Reported-by; George Dunlap
Signed-off-by: Ian Jackson
---
tools/libxl/libxl_event.h | 2 ++
1 file changed, 2 insertions(+)
On 1/17/20 4:52 PM, Ian Jackson wrote:
> George Dunlap writes ("[PATCH v3 7/8] golang/xenlight: Notify xenlight of
> SIGCHLD"):
>> libxl forks external processes and waits for them to complete; it
>> therefore needs to be notified when children exit.
>>
>> In absence of instructions to the
On 1/17/20 10:53 AM, Anthony PERARD wrote:
> livepatch/Makefile seems to only be used via Rules.mk, which already
> includes Config.mk, avoid the second include.
>
> Signed-off-by: Anthony PERARD
Reviewed-by: Ross Lagerwall
___
Xen-devel mailing
On Fri, Jan 17, 2020 at 6:31 AM Alexandru Stefan ISAILA
wrote:
>
> 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
>
On Fri, Jan 17, 2020 at 2:23 AM Jan Beulich wrote:
>
> 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 |
George Dunlap writes ("[PATCH v3 7/8] golang/xenlight: Notify xenlight of
SIGCHLD"):
> libxl forks external processes and waits for them to complete; it
> therefore needs to be notified when children exit.
>
> In absence of instructions to the contrary, libxl sets up its own
> SIGCHLD handlers.
Hide the following information that can help identify the running Xen
binary version: XENVER_extraversion, XENVER_compile_info, XENVER_changeset.
This makes harder for malicious guests to fingerprint Xen to identify
exploitable systems.
Add explicit cases for XENVER_commandline and
Signed-off-by: Sergey Dyasli
---
v2 --> v3:
- new patch
CC: Andrew Cooper
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Julien Grall
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC: Daniel De Graaf
CC: Doug Goldstein
---
xen/common/Kconfig | 8
The code is quite a bit easier to read and to reason about this way,
I think.
In ept_set_entry() additionally change the function's return value in
the MAP_FAILED case to -ENOMEM; -ENOENT would be applicable only when
ept_next_entry() was invoked with "read_only" set to true.
In two cases, where
On 17/01/2020 15:44, Jan Beulich wrote:
> 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
On 17.01.2020 17:08, Roger Pau Monné wrote:
> On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
>> 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
On Thu, Jan 16, 2020 at 01:40:39PM +0100, Jan Beulich wrote:
> On 16.01.2020 13:29, Anthony PERARD wrote:
> Indeed, hence also my "as suggested before". I remain unconvinced
> that is it useful to have e.g.
>
> CONFIG_GCC_VERSION=80300
> CONFIG_CLANG_VERSION=0
>
> in xen/.config. This is at best
On 17.01.2020 14:31, Alexandru Stefan ISAILA wrote:
> 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
Reviewed-by: Jan Beulich
On Fri, Jan 17, 2020 at 03:30:44PM +, Andrew Cooper wrote:
> 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
> >
On Fri, Jan 17, 2020 at 04:56:00PM +0100, Jan Beulich wrote:
> 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
On Fri, Jan 17, 2020 at 6:08 AM Roger Pau Monne wrote:
>
> 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
>
On 1/17/20 3:57 PM, George Dunlap wrote:
> The current fromC array code will do the "magic" casting and
> martialling even when num_foo variable is 0. Go crashes when doing
> the cast.
>
> Only do array marshalling if the number of elements is non-zero;
> otherwise, leave the target pointer
This is a sketch of functionality suitable for creating a basic
domain, with a disk and a vif. DomainConfig, DeviceDisk, and
DeviceNic types are all created using constructor functions, which
initialize them with libxl's defaults.
DomainCreateNew takes the config and calls without any updates.
If an error is encountered deep in a complicated data structure, it's
often difficult to tell where the error actually is. Make the error
message from the generated toC() and fromC() structures more
informative by tagging which field being converted encountered the
error. This will have the
libxl forks external processes and waits for them to complete; it
therefore needs to be notified when children exit.
In absence of instructions to the contrary, libxl sets up its own
SIGCHLD handlers.
Golang always unmasks and handles SIGCHLD itself. libxl thankfully
notices this and throws an
Commit 871e51d2d4 changed the sign on the xenlight error types (making
the values negative, same as the C-generated constants), but failed to
flip the sign in the Error() string function. The result is that
ErrorNonspecific.String() prints "libxl error: 1" rather than the
human-readable error
Empty Go strings should be converted to `nil` libxl_cpuid_policy_list;
otherwise libxl_cpuid_parse_config gets confused.
Also, libxl_cpuid_policy_list returns a weird error, not a "normal"
libxl error; if it returns one of these non-standard errors, convert
it to ErrorInval.
Finally, make the
The current fromC array code will do the "magic" casting and
martialling even when num_foo variable is 0. Go crashes when doing
the cast.
Only do array marshalling if the number of elements is non-zero;
otherwise, leave the target pointer empty (nil for Go slices, NULL for
C arrays).
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
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.
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
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
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
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
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
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.
>
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
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;
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:
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
---
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
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
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 ++
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
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
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
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
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
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:
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
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
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
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
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
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
> > 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
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.
> >
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).
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
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
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
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,
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
> >
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.
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
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
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
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:
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
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
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 --
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
1 - 100 of 155 matches
Mail list logo
