> On 19. Sep 2019, at 18:06, Ross Lagerwall wrote:
>
> On 9/16/19 11:59 AM, Pawel Wieczorkiewicz wrote:
>> This is the initial implementation of the expectations enhancement
>> to improve inline asm hotpatching.
>> Expectations are designed as optional feature, since the main use of
>> them is
On 20.09.2019 19:15, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH] tools/ocaml: Build fix following libxl
> API changes"):
>> On Fri, Sep 20, 2019 at 05:19:02PM +0100, Anthony PERARD wrote:
>>> The following libxl API became asynchronous and gained an additional
>>> `ao_how' parameter:
On 21.09.2019 01:14, Sarah Newman wrote:
> With nestedhvm=1, the L2 HVM guest is either hanging (Xen 4.8) or crashing
> (Xen 4.12.1) the L1 Xen hypervisor with recent versions of Linux. We
> isolated the commit to:
>
> commit 093ae8f9a86a974c920b613860f1f7fd5bbd70ab
> Author: Borislav Petkov
>
flight 141632 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141632/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-amd64 11 guest-start fail REGR. vs. 140282
test-amd64-i386-f
On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
>> On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
>>> Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
>>> bypassing pciback. While pciback is stil
flight 141689 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141689/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
On 20.08.2019 22:36, Andreas Kinzler wrote:
> On 20.08.2019 20:12, Andrew Cooper wrote:
>>> Xen version 4.10.2. dom0 kernel 4.13.16. The BIOS version is unchanged
>>> from 2700X (working) to 3700X (crashing).
>> So you've done a Zen v1 => Zen v2 CPU upgrade and an existing system?
>
> With "existi
On Wed, Sep 18, 2019 at 02:16:13PM -0700, Joe Jin wrote:
>On 9/16/19 11:48 PM, Jan Beulich wrote:
>> On 17.09.2019 00:20, Joe Jin wrote:
>>> On 9/16/19 1:01 AM, Jan Beulich wrote:
On 13.09.2019 18:38, Joe Jin wrote:
> On 9/13/19 12:14 AM, Jan Beulich wrote:
>> On 12.09.2019 20:03, Joe
On 20.09.2019 15:54, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0x8008 counterpart
On 9/19/19 8:26 PM, Ben Hutchings wrote:
On Mon, 2019-08-19 at 18:58 +0100, Vlastimil Babka wrote:
[...]
Hi, I'm sending this stable-only patch for consideration because it's probably
unrealistic to backport the 4.13 switch to generic GUP. I can look at 4.4 and
3.16 if accepted. The RCU page tab
On 20.09.2019 18:20, Jan Beulich wrote:
> On 20.09.2019 16:59, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 20.09.2019 17:22, Jan Beulich wrote:
>>> On 20.09.2019 14:16, Alexandru Stefan ISAILA wrote:
In order to have __hvm_copy() issue ~X86EMUL_RETRY a new return type,
HVMTRANS_need_retr
Hi Volodymyr,
On 18/09/2019 19:50, Volodymyr Babchuk wrote:
We want to limit number of calls to lookup_and_pin_guest_ram_addr()
per one request. There are two ways to do this: either preempt
translate_noncontig() or limit size of one shared buffer size.
It is quite hard to preempt translate_non
Hi Volodymyr,
On 18/09/2019 19:50, Volodymyr Babchuk wrote:
We can check for hypercall_preempt_check() in the loop inside
optee_relinquish_resources() to increase hypervisor responsiveness in
case if preemption is required.
Signed-off-by: Volodymyr Babchuk
Acked-by: Julien Grall
Cheers,
Hi Volodymyr,
On 18/09/2019 19:50, Volodymyr Babchuk wrote:
We want to limit number of shared buffers that guest can register in
OP-TEE. Every such buffer consumes XEN resources and we don't want
guest to exhaust XEN. So we choose arbitrary limit for shared buffers.
Signed-off-by: Volodymyr Bab
On 23.09.2019 11:00, Alexandru Stefan ISAILA wrote:
> Ok, just to make sure this is what is needed and limit the patch
> versions, rep_movs / rep_stos should have a switch like this:
>
> switch ( rc )
> {
> case HVMTRANS_okay:
> return X86EMUL_OKAY;
>
> -Original Message-
> From: John Snow
> Sent: 20 September 2019 22:11
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> qemu-de...@nongnu.org;
> qemu-bl...@nongnu.org
> Cc: Kevin Wolf ; Stefano Stabellini
> ; Max Reitz
> ; Anthony Perard ; Mark Syms
>
> Subject: Re: [Qemu-block]
On 16.09.19 17:44, Jan Beulich wrote:
On 16.09.2019 16:50, Andrew Cooper wrote:
After a complicated investigation, it turns out that c/s 2529c850ea48
broke xc_vcpu_getinfo().
The bug looks as if it is in vcpu_runstate_get(), which doesn't account
for XEN_RUNSTATE_UPDATE and calculating a wildly
Hi,
On 18/09/2019 19:51, Volodymyr Babchuk wrote:
+/* Handles return from Xen-issued RPC */
+static void handle_xen_rpc_return(struct optee_domain *ctx,
+ struct cpu_user_regs *regs,
+ struct optee_std_call *call,
+
Hi Volodymyr,
On 18/09/2019 19:51, Volodymyr Babchuk wrote:
OP-TEE mediator now is "Tech Preview" state, and we want to update
it's description in Kconfig accordingly.
Signed-off-by: Volodymyr Babchuk
---
Note to commiter: this patch depends on first 4 patches in the series.
---
xen/arch/a
Hi,
On 18/09/2019 19:51, Volodymyr Babchuk wrote:
With the latest patches to the mediator, it can be considered
as Technological Preview feature.
Signed-off-by: Volodymyr Babchuk
With one change below:
Acked-by: Julien Grall
---
Note for commiter:
Obviously this patch should be merged
On 23.09.2019 11:42, Jürgen Groß wrote:
> On 16.09.19 17:44, Jan Beulich wrote:
>> On 16.09.2019 16:50, Andrew Cooper wrote:
>>> After a complicated investigation, it turns out that c/s 2529c850ea48
>>> broke xc_vcpu_getinfo().
>>>
>>> The bug looks as if it is in vcpu_runstate_get(), which doesn't
On 23.09.19 11:51, Jan Beulich wrote:
On 23.09.2019 11:42, Jürgen Groß wrote:
On 16.09.19 17:44, Jan Beulich wrote:
On 16.09.2019 16:50, Andrew Cooper wrote:
After a complicated investigation, it turns out that c/s 2529c850ea48
broke xc_vcpu_getinfo().
The bug looks as if it is in vcpu_runsta
ASM_CALL_CONSTRAINT is defined there.
No functional change.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/guest/hypercall.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/include/asm-x86/guest/hypercall.h
b/xen/include/asm-x86/guest/hypercall.h
index d548816b30..c9deca6ffc 100644
-
The only user is Xen specific code in PV shim. We can therefore export
the variable directly.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/xen/xen.c| 7 +--
xen/arch/x86/pv/shim.c | 2 +-
xen/include/asm-x86/guest/xen.h | 2 +-
3 files changed, 3 insertions(+), 8 deletions(-)
Hi all
In case you're wondering, I can already run a fully fledged Xen system on
Hyper-V with emulated disk and network.
This is the very first stage for porting Xen to run on Hyper-V with all the
goodies Hyper-V has to offer. With this series, Xen can successfully detect
Hyper-V and prints out
We need indication whether it has succeeded or not.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hypervisor.c | 5 -
xen/arch/x86/guest/xen/xen.c| 7 ---
xen/include/asm-x86/guest/xen.h | 4 ++--
3 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/guest/hype
The only implementation there is Xen.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/Makefile| 2 +
xen/arch/x86/guest/hypervisor.c| 112 +
xen/arch/x86/guest/xen/xen.c | 81 +-
xen/include/asm-x86/gue
We will add Hyper-V specific implementations in the future.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/xen/xen.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/x
We use the same code structure as we did for Xen code.
As starters, detect Hyper-V in probe_hyperv. More complex
functionality will be added later.
Signed-off-by: Wei Liu
---
xen/arch/x86/Kconfig | 9 +
xen/arch/x86/guest/Makefile| 1 +
xen/arch/x86/guest/hyperv/Make
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index dec60d0301..bbcc5a503d 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -789,6 +789,17 @@ void __init noreturn __start_
Xen is able to run as a guest on Xen. We plan to make it able to run
on Hyper-V as well.
Introduce CONFIG_GUEST which is set to true if either running on Xen
or Hyper-V is desired. Restructure code hierarchy for new code to
come.
No functional change intended.
Signed-off-by: Wei Liu
---
xen/ar
On 23.09.2019 11:56, Jürgen Groß wrote:
> On 23.09.19 11:51, Jan Beulich wrote:
>> On 23.09.2019 11:42, Jürgen Groß wrote:
>>> On 16.09.19 17:44, Jan Beulich wrote:
On 16.09.2019 16:50, Andrew Cooper wrote:
> After a complicated investigation, it turns out that c/s 2529c850ea48
> broke
Jan Beulich writes ("Re: [Xen-devel] [PATCH] tools/ocaml: Build fix following
libxl API changes"):
> According to osstest results accumulated over the weekend and the
> state of the tree, did you perhaps commit the change but forgot
> to actually push it?
Gah, apparently so. Now done.
Ian.
___
On 23.09.19 12:12, Jan Beulich wrote:
On 23.09.2019 11:56, Jürgen Groß wrote:
On 23.09.19 11:51, Jan Beulich wrote:
On 23.09.2019 11:42, Jürgen Groß wrote:
On 16.09.19 17:44, Jan Beulich wrote:
On 16.09.2019 16:50, Andrew Cooper wrote:
After a complicated investigation, it turns out that c/s
flight 141698 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141698/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 141253
build-amd64
On 18/09/2019 19:50, Volodymyr Babchuk wrote:
Hello,
Hi,
This is the second version for maturing the OP-TEE mediator.
Changes also can be pulled from [2].
Changes from v1:
- Added patch that updates SUPPORT.md
- Instead of removing "experimental" status I changed it to "Tech Preview"
On Fri, Sep 20, 2019 at 03:54:12PM +0200, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0
On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> > On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> >> On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> >>> Allow device model running in stubdomain to enab
> -Original Message-
> From: Xen-devel On Behalf Of Wei Liu
> Sent: 23 September 2019 11:09
> To: Xen Development List
> Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> ;
> Michael Kelley ; Jan Beulich ;
> Roger Pau Monne
>
> Subject: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
flight 141640 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 141505
Tests which did not
On Mon, Sep 23, 2019 at 10:48:45AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of Wei
> > Liu
> > Sent: 23 September 2019 11:09
> > To: Xen Development List
> > Cc: Wei Liu ; Wei Liu ; Andrew Cooper
> > ;
> > Michael Kelley ; Jan Beulich ;
> > Roger
On Wed, Sep 18, 2019 at 12:57:02PM +0100, Paul Durrant wrote:
> When a frontend gracefully disconnects from an offline backend, it will
> set its own state to XenbusStateClosed. The code in xen-block.c correctly
> deals with this and sets the backend into XenbusStateClosed. Unfortunately
> it is po
A/D bit writes (on page walks) can be considered benign by an introspection
agent, so receiving vm_events for them is a pessimization. We try here to
optimize by filtering these events out.
Currently, we are fully emulating the instruction at RIP when the hardware sees
an EPT fault with npfec.kind
On 23.09.2019 12:47, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
>> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
>>> Anyway, if you all agree that pciback should be the way to go, I can go
>>> that route too. In practice, it would be
> -Original Message-
> From: Wei Liu
> Sent: 23 September 2019 12:27
> To: Paul Durrant
> Cc: 'Wei Liu' ; Xen Development List
> ; Wei Liu
> ; Andrew Cooper ; Michael
> Kelley
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
On Mon, Sep 23, 2019 at 02:05:58PM +0200, Jan Beulich wrote:
> On 23.09.2019 12:47, Marek Marczykowski-Górecki wrote:
> > On Mon, Sep 23, 2019 at 09:58:27AM +0200, Jan Beulich wrote:
> >> On 20.09.2019 18:02, Marek Marczykowski-Górecki wrote:
> >>> Anyway, if you all agree that pciback should be
On 16.09.19 18:24, Jan Beulich wrote:
Hi, Jan.
+ROUNDUP_SIZE(tmp_size);
+
+if ( tmp_size <= curr_size && ((unsigned long)ptr & (align - 1)) == 0 )
+return ptr; /* the size and alignment fit in already allocated space */
You also don't seem to ever update ptr in case yo
On Mon, Sep 23, 2019 at 12:11:26PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 23 September 2019 12:27
> > To: Paul Durrant
> > Cc: 'Wei Liu' ; Xen Development List
> > ; Wei Liu
> > ; Andrew Cooper ; Michael
> > Kelley
> > ; Jan Beulich ; Roger Pau Mon
On 23.09.2019 14:25, Marek Marczykowski-Górecki wrote:
> What about this: HVM guest can already do all of this when qemu is
> running in dom0. So, allowing those actions when qemu is running in
> stubdomain should not introduce _additional_ risks.
Well, in a way - yes. But I don't think it's righ
> -Original Message-
> From: Alexandru Stefan ISAILA
> Sent: 23 September 2019 13:06
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; w...@xen.org; Roger Pau Monne
> ; Razvan COJOCARU
> ; ta...@tklengyel.com; Alexandru Stefan ISAILA
> ;
> Pet
On Mon, Sep 23, 2019 at 03:02:49PM +0200, Jan Beulich wrote:
> On 23.09.2019 14:25, Marek Marczykowski-Górecki wrote:
> > What about this: HVM guest can already do all of this when qemu is
> > running in dom0. So, allowing those actions when qemu is running in
> > stubdomain should not introduce _
The compatibility function mistakenly called itself.
Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index ba48e7e900d3..3421e5aa986
On 23.09.2019 14:50, Oleksandr wrote:
> Does the diff below is close to what you meant?
Almost.
> @@ -598,10 +621,70 @@ void *_xzalloc(unsigned long size, unsigned long align)
> return p ? memset(p, 0, size) : p;
> }
>
> -void xfree(void *p)
> +void *_xrealloc(void *ptr, unsigned long si
And a bit more thought.
On Mon, Sep 23, 2019 at 01:54:31PM +0100, Wei Liu wrote:
[...]
> > >
> > > Per TLFS, eVMCS should be used by L1 Xen.
> >
> > Yes, I guess it only needs to be used by L1, but Windows is using an
> > increasing number of VMs for various purposes so I think making it
> > sta
On Mon, Sep 23, 2019 at 02:26:52PM +0100, Anthony PERARD wrote:
> The compatibility function mistakenly called itself.
>
> Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
> Signed-off-by: Anthony PERARD
Acked-by: Wei Liu
___
Xen-devel mailing list
Xe
Ping? I think this is the only remaining patch in this series that still needs
an ack.
Paul
> -Original Message-
> From: Paul Durrant
> Sent: 18 September 2019 11:47
> To: xen-devel@lists.xenproject.org
> Cc: Ian Jackson ; Paul Durrant
> ; Christian Lindig
> ; David Scott
> Subject:
Wei Liu writes ("Re: [PATCH] libxl: Fix build when LIBXL_API_VERSION is set"):
> On Mon, Sep 23, 2019 at 02:26:52PM +0100, Anthony PERARD wrote:
> > The compatibility function mistakenly called itself.
> >
> > Fixes: 95627b87c3159928458ee586e8c5c593bdd248d8
> > Signed-off-by: Anthony PERARD
>
>
On 23.09.19 16:31, Jan Beulich wrote:
Hi, Jan
+
+ if ( ptr == NULL || ptr == ZERO_BLOCK_PTR )
+ return _xmalloc(size, align);
+
+ ASSERT((align & (align - 1)) == 0);
+ if ( align < MEM_ALIGN )
+ align = MEM_ALIGN;
+
+ tmp_size = size + align - MEM_ALIGN;
+
+ if (
> On 23 Sep 2019, at 14:39, Paul Durrant wrote:
>
> Ping? I think this is the only remaining patch in this series that still
> needs an ack.
Acked-by: Christian Lindig
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
On 23.09.2019 14:05, Alexandru Stefan ISAILA wrote:
> @@ -599,8 +600,15 @@ static void *hvmemul_map_linear_addr(
> err = NULL;
> goto out;
>
> -case HVMTRANS_gfn_paged_out:
> +case HVMTRANS_need_retry:
> +/*
> + * hvm_translate_get
> -Original Message-
> From: Wei Liu
> Sent: 23 September 2019 14:34
> To: Paul Durrant
> Cc: 'Wei Liu' ; Xen Development List
> ; Wei Liu
> ; Andrew Cooper ; Michael
> Kelley
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
On 23.09.2019 16:43, Jan Beulich wrote:
> On 23.09.2019 14:05, Alexandru Stefan ISAILA wrote:
>> @@ -599,8 +600,15 @@ static void *hvmemul_map_linear_addr(
>> err = NULL;
>> goto out;
>>
>> -case HVMTRANS_gfn_paged_out:
>> +case HVMTRANS_need_retry:
On 23.09.2019 16:05, Paul Durrant wrote:
>> -Original Message-
>> From: Alexandru Stefan ISAILA
>> Sent: 23 September 2019 13:06
>> To: xen-devel@lists.xenproject.org
>> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
>> ; w...@xen.org; Roger Pau Monne
>> ; Razvan COJOCARU
>> ; ta..
On 15/07/2019 16:00, Jan Beulich wrote:
> Nothing guarantees that the original frame's stack pointer points at
> readable memory. Avoid a (likely nested) crash by attaching exception
> recovery to the read (making it a single read at the same time). Don't
> even invoke _show_trace() in case of a no
On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
> Rather than doing this every time we set up interrupts for a device
> anew (and then in several places) fill this invariant field right after
> allocating struct pci_dev.
>
> Signed-off-by: Jan Beulich
LGTM:
Reviewed-by: Roger Pau M
On Mon, Sep 23, 2019 at 01:47:14PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 23 September 2019 14:34
> > To: Paul Durrant
> > Cc: 'Wei Liu' ; Xen Development List
> > ; Wei Liu
> > ; Andrew Cooper ; Michael
> > Kelley
> > ; Jan Beulich ; Roger Pau Mon
flight 141708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141708/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 141253
Tests which
> -Original Message-
> From: Wei Liu
> Sent: 23 September 2019 15:21
> To: Paul Durrant
> Cc: 'Wei Liu' ; Xen Development List
> ; Wei Liu
> ; Andrew Cooper ; Michael
> Kelley
> ; Jan Beulich ; Roger Pau Monne
>
> Subject: Re: [Xen-devel] [PATCH for-next RFC 0/8] Port Xen to Hyper-V
>
On 23.09.2019 16:22, Roger Pau Monné wrote:
> On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
>> Rather than doing this every time we set up interrupts for a device
>> anew (and then in several places) fill this invariant field right after
>> allocating struct pci_dev.
>>
>> Signed-of
On Mon, Sep 23, 2019 at 02:39:10PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu
> > Sent: 23 September 2019 15:21
> > To: Paul Durrant
> > Cc: 'Wei Liu' ; Xen Development List
> > ; Wei Liu
> > ; Andrew Cooper ; Michael
> > Kelley
> > ; Jan Beulich ; Roger Pau Mon
cpp[BytePerPlane] can't describe the 10bit data format correctly,
So we use bpp[BitPerPlane] to instead cpp.
Signed-off-by: Sandy Huang
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/drive
On Wed, Sep 18, 2019 at 12:57:44PM +0100, Paul Durrant wrote:
> From: Mark Syms
>
> Some toolstack implementations will set the frontend xenstore
> keys to Initialising which will then trigger the in guest PV
> drivers to begin initialising and some implementations will
> then set their state to
flight 141650 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/141650/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail REGR. vs. 141519
Tests which are faili
On 23.09.2019 16:20, Andrew Cooper wrote:
> On 15/07/2019 16:00, Jan Beulich wrote:
>> Nothing guarantees that the original frame's stack pointer points at
>> readable memory. Avoid a (likely nested) crash by attaching exception
>> recovery to the read (making it a single read at the same time). Do
On Fri, Sep 20, 2019 at 06:02:50PM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Sep 20, 2019 at 12:10:09PM +0200, Jan Beulich wrote:
> > On 14.09.2019 17:37, Marek Marczykowski-Górecki wrote:
> > > Allow device model running in stubdomain to enable/disable INTx/MSI(-X),
> > > bypassing pciba
On Mon, Sep 23, 2019 at 04:41:01PM +0200, Jan Beulich wrote:
> On 23.09.2019 16:22, Roger Pau Monné wrote:
> > On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
> >> Rather than doing this every time we set up interrupts for a device
> >> anew (and then in several places) fill this inva
On 14.09.2019 10:52, Juergen Gross wrote:
> Today the vcpu runstate of a new scheduled vcpu is always set to
> "running" even if at that time vcpu_runnable() is already returning
> false due to a race (e.g. with pausing the vcpu).
I can see this part, ...
> With core scheduling this can no longer
On 23.09.2019 17:18, Roger Pau Monné wrote:
> On Mon, Sep 23, 2019 at 04:41:01PM +0200, Jan Beulich wrote:
>> On 23.09.2019 16:22, Roger Pau Monné wrote:
>>> On Thu, Sep 19, 2019 at 03:22:54PM +0200, Jan Beulich wrote:
Rather than doing this every time we set up interrupts for a device
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:22
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 1/8] AMD/IOMMU: don't blindly allocate
> interrupt remapping tables
>
>
On 9/23/19 3:05 PM, Alexandru Stefan ISAILA wrote:
> A/D bit writes (on page walks) can be considered benign by an introspection
> agent, so receiving vm_events for them is a pessimization. We try here to
> optimize by filtering these events out.
> Currently, we are fully emulating the instruction
On 14.09.2019 10:52, Juergen Gross wrote:
> @@ -266,15 +267,16 @@ static inline void vcpu_runstate_change(
> static inline void sched_unit_runstate_change(struct sched_unit *unit,
> bool running, s_time_t new_entry_time)
> {
> -struct vcpu *v = unit->vcpu_list;
> +struct vcpu *v;
>
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:22
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 2/8] AMD/IOMMU: make phantom functions share
> interrupt remapping table
On 14.09.2019 10:52, Juergen Gross wrote:
> cpupool_domain_cpumask() is used by scheduling to select cpus or to
> iterate over cpus. In order to support scheduling units spanning
> multiple cpus let cpupool_domain_cpumask() return a cpumask with only
> one bit set per scheduling resource.
I guess
On 9/23/19 1:31 AM, Chao Gao wrote:
> On Wed, Sep 18, 2019 at 02:16:13PM -0700, Joe Jin wrote:
>> On 9/16/19 11:48 PM, Jan Beulich wrote:
>>> On 17.09.2019 00:20, Joe Jin wrote:
On 9/16/19 1:01 AM, Jan Beulich wrote:
> On 13.09.2019 18:38, Joe Jin wrote:
>> On 9/13/19 12:14 AM, Jan Beu
On 14.09.2019 10:52, Juergen Gross wrote:
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -36,26 +36,35 @@ static DEFINE_SPINLOCK(cpupool_lock);
>
> DEFINE_PER_CPU(struct cpupool *, cpupool);
>
> +static void free_cpupool_struct(struct cpupool *c)
> +{
> +if ( c )
> +{
>
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Wei Liu ;
> Suravee Suthikulpanit
> ; Roger Pau Monne
> Subject: [Xen-devel] [PATCH v6 3/8] x86/PCI: read maximum MSI vector count
On 23.09.2019 17:57, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 19 September 2019 14:23
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Wei Liu ;
>> Suravee Suthikulpanit
>> ; Roger Pau Monne
>> Subject: [Xen-devel] [PA
On 23/09/2019 16:12, Jan Beulich wrote:
> On 23.09.2019 16:20, Andrew Cooper wrote:
>> On 15/07/2019 16:00, Jan Beulich wrote:
>>> Nothing guarantees that the original frame's stack pointer points at
>>> readable memory. Avoid a (likely nested) crash by attaching exception
>>> recovery to the read
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:23
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 4/8] AMD/IOMMU: replace INTREMAP_ENTRIES
>
> Prepare for the number of e
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:24
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 5/8] AMD/IOMMU: restrict interrupt remapping
> table sizes
>
> There's
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:24
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 6/8] AMD/IOMMU: tidy struct ivrs_mappings
>
> Move the device flags fiel
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:25
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 7/8] AMD/IOMMU: allocate one device table per
> PCI segment
>
> Having
On 15/07/2019 16:01, Jan Beulich wrote:
> Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
> often for relatively simple leaf functions. (To give a specific example,
> the case I've run into this with is _pci_hide_device() and gcc 8.
> Interestingly the even more simple neig
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 19 September 2019 14:25
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Suravee Suthikulpanit
>
> Subject: [Xen-devel] [PATCH v6 8/8] AMD/IOMMU: pre-fill all DTEs right after
> table allocation
>
> Ma
On 20/09/2019 14:54, Jan Beulich wrote:
> Recent AMD processors may report up to 128 logical processors in CPUID
> leaf 1. Doubling this value produces 0 (which OSes sincerely dislike),
> as the respective field is only 8 bits wide. Suppress doubling the value
> (and its leaf 0x8008 counterpart
On 9/23/19 5:38 AM, Paul Durrant wrote:
>> -Original Message-
>> From: John Snow
>> Sent: 20 September 2019 22:11
>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>> qemu-de...@nongnu.org;
>> qemu-bl...@nongnu.org
>> Cc: Kevin Wolf ; Stefano Stabellini
>> ; Max Reitz
>> ; Anthony
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
include/qapi/error.h | 22 ++
util/error.c | 6 +++---
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/include/qapi/error.h b/include/qapi/error.h
index f6f4fa0fac..551385aa91 100644
--- a/include/qapi/er
Don't shadow Error *err: it's a bad thing. This patch also simplifies
following Error propagation conversion.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
net/net.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/net.c b/net/net.c
index 84aa6d8d00..5fc72511c1 100
Here is introduced ERRP_FUNCTION_BEGIN macro, to be used at start of
any function with errp parameter.
It has three goals:
1. Fix issue with error_fatal & error_append_hint: user can't see these
hints, because exit() happens in error_setg earlier than hint is
appended. [Reported by Greg Kurz]
2.
Error **errp is almost always OUT-argument: it's assumed to be NULL, or
pointer to NULL-initialized pointer, or pointer to error_abort or
error_fatal, for callee to report error.
But very few functions (most of the are error API) instead get Error
**errp as IN-argument: it's assumed to be set, and
1 - 100 of 129 matches
Mail list logo
