> -Original Message-
>
> > Linux PCI subsytem has an option resource_alignment that can be
> > applied to either a single device or all devices. Booting with
> > pci=resource_aligment=4096 will align each device to a page. Do you
> > think pciback should force resource_alignment=4096 for
flight 146079 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146079/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 6 xen-buildfail REGR. vs. 145145
build-i386-pre
On 14.01.2020 20:31, Andrew Cooper wrote:
> On 14/01/2020 16:45, Jan Beulich wrote:
>> On 13.01.2020 18:50, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -668,6 +668,20 @@ trampoline_setup:
>>> add %esi,sym_fs(__page_tables_start)-8(,
On 19/12/2019 16:14, Jürgen Groß wrote:
> On 19.12.19 13:45, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> We recently did another quick test of core scheduling mode, and the following
>> failures were found:
>>
>> 1. live-patch apply failures:
>>
>> (XEN) [ 1058.751974] livepatch: lp_1_1: Timed o
flight 146095 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146095/
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
On 14.01.2020 18:27, Andrew Cooper wrote:
> On 14/01/2020 17:02, Jan Beulich wrote:
>> On 13.01.2020 18:50, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/boot/head.S
>>> +++ b/xen/arch/x86/boot/head.S
>>> @@ -687,14 +687,19 @@ trampoline_setup:
>>> * handling/walking), and identity map Xen
On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> If ITSC is not available on CPU (e.g if running nested as PV shim)
> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
> all AMD and some old Intel processors. In which case TSC would need to
> be restored on CPU
flight 146090 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146090/
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
test-amd64-amd64-xl-qemuu
On Fri, Dec 20, 2019 at 05:26:34PM +0100, Jan Beulich wrote:
> On 17.07.2019 08:47, Jan Beulich wrote:
> > With non-empty CONFIG_DOM0_MEM clang5 produces
> >
> > dom0_build.c:344:24: error: use of logical '&&' with constant operand
> > [-Werror,-Wconstant-logical-operand]
> > if ( !dom0_mem_
On 12/27/19 5:06 PM, Andrew Cooper wrote:
> On 02/12/2019 08:22, Andy Smith wrote:
>> Hi,
>>
>> I've been looking into live patching for the first time.
>
> CC'ing livepatch maintainers.
>
>>
>> Starting with a 4.12.1 build:
>>
>> $ cd ~/dev
>> $ ls -l
>> total 8
>> drwxr-xr-x 3 andy andy 4096 Oc
On Wed, Jan 15, 2020 at 10:56:37AM +0100, Roger Pau Monné wrote:
> On Fri, Dec 20, 2019 at 05:26:34PM +0100, Jan Beulich wrote:
> > On 17.07.2019 08:47, Jan Beulich wrote:
> > > With non-empty CONFIG_DOM0_MEM clang5 produces
> > >
> > > dom0_build.c:344:24: error: use of logical '&&' with constant
flight 146108 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146108/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen b4194711ffaffa5e63d986338fb8d4020fa6bad1
baseline version:
xen 8842
On 15.01.2020 11:00, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 10:56:37AM +0100, Roger Pau Monné wrote:
>> On Fri, Dec 20, 2019 at 05:26:34PM +0100, Jan Beulich wrote:
>>> On 17.07.2019 08:47, Jan Beulich wrote:
With non-empty CONFIG_DOM0_MEM clang5 produces
dom0_build.c:344:2
On 15.01.2020 10:40, Jan Beulich wrote:
> On 14.01.2020 18:27, Andrew Cooper wrote:
>> On 14/01/2020 17:02, Jan Beulich wrote:
>>> Even when that remaining issue got addressed, I think it would be better
>>> to keep it, altering the bound to GB(1).
>>
>> A 1G check wouldn't be correct.
>>
>> We've
Hi Stefano,
On 14/01/2020 23:31, Stefano Stabellini wrote:
When booting via EFI, the EFI memory map has information about memory
regions and their type. Improve the check for the type and attribute of
each memory region to figure out whether it is usable memory or not.
This patch brings the chec
On 15/01/2020 07:40, David Woodhouse wrote:
On Tue, 2020-01-14 at 16:29 +, Julien Grall wrote:
That's the point in appending an IND_WRITE64 operation to the kimage
stream. The actual write is done in the last gasp of kexec_reloc()
after Xen#1 is quiescent, on the way into purgatory.
I wa
While it has been me to introduce this, the use of | there has become
(and perhaps was from the very beginning) misleading. Rather than
avoiding the right side of it when linking the xen.efi intermediate file
at a different base address, make the expression cope with that case,
thus verifying place
On Tue, Jan 14, 2020 at 08:35:45PM +, Andrew Cooper wrote:
> Xen inherited its list infrastructure from Linux. One area where has fallen
> behind is that of prefetching, which as it turns out is a performance penalty
> in most cases.
>
> Prefetch of NULL on x86 is now widely measured to have
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
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -29
On 1/13/20 9:21 PM, Lars Kurth wrote:
>
>
> On 13/01/2020, 19:54, "George Dunlap" wrote:
>
>
> > On Dec 30, 2019, at 7:32 PM, Lars Kurth
> wrote:
> >
> > From: Lars Kurth
> >
> > This guide covers the bulk on Best Practice related to code review
> > It primari
Hi Juergen,
On 08/01/2020 15:20, Sergey Dyasli wrote:
> It is incorrect to call pmd_populate_kernel() multiple times for the
> same page table. Xen notices it during kasan_populate_early_shadow():
>
> (XEN) mm.c:3222:d155v0 mfn 3704b already pinned
>
> This happens for kasan_early_shadow_pte w
On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
> Add a simple proxy for tunneling socket connection over vchan. This is
> based on existing vchan-node* applications, but extended with socket
> support. vchan-socket-proxy serves both as a client and as a server,
> depending on parameters. It
On 09/01/2020 10:33, Vlastimil Babka wrote:
> On 1/8/20 4:21 PM, Sergey Dyasli wrote:
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
>> allocations are aligned to the next power of 2 of the size does not
>> hold.
>
> Hmm, really? They should afte
On 14/01/2020 21:39, Jorge Pereira wrote:
Hi Guys,
Hello,
I’m currently using XEN in order to run side-by-side a DOM-0 with a
DOM-U guest. My use-case scenario requires in the DOM-U direct access to
some dma-capable devices such ethernet and some GPUs.
Since our target platform (i.MX8M
On 15.01.20 11:54, Sergey Dyasli wrote:
Hi Juergen,
On 08/01/2020 15:20, Sergey Dyasli wrote:
It is incorrect to call pmd_populate_kernel() multiple times for the
same page table. Xen notices it during kasan_populate_early_shadow():
(XEN) mm.c:3222:d155v0 mfn 3704b already pinned
This ha
Hello,
For the last days I've been trying to figure out how to properly
perform flushes of guest TLBs from the hypervisor. We currently
provide a hypercall to HVM guests (HVMOP_flush_tlbs). The hypercall
however pauses all vCPUs that require a flush and then call
paging_update_cr3, which is highly
On 14.01.2020 21:35, Andrew Cooper wrote:
> Xen inherited its list infrastructure from Linux. One area where has fallen
> behind is that of prefetching, which as it turns out is a performance penalty
> in most cases.
>
> Prefetch of NULL on x86 is now widely measured to have glacial performance
>
On 15/01/2020 10:39, Roger Pau Monné wrote:
> On Tue, Jan 14, 2020 at 08:35:45PM +, Andrew Cooper wrote:
>> Xen inherited its list infrastructure from Linux. One area where has fallen
>> behind is that of prefetching, which as it turns out is a performance penalty
>> in most cases.
>>
>> Prefe
On 14.01.2020 20:36, Igor Druzhinin wrote:
> If ITSC is not available on CPU (e.g if running nested as PV shim)
> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
> all AMD and some old Intel processors. In which case TSC would need to
> be restored on CPU from platform time by
On 15.01.2020 10:47, Roger Pau Monné wrote:
> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
>>
>> void cstate_restore_tsc(void)
>> {
>> +struct cpu_time *t = &t
On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
> On 15.01.2020 10:47, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> >> --- a/xen/arch/x86/time.c
> >> +++ b/xen/arch/x86/time.c
> >> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
> >>
On 15/01/2020, 10:47, "George Dunlap" wrote:
On 1/13/20 9:21 PM, Lars Kurth wrote:
>
>
> On 13/01/2020, 19:54, "George Dunlap" wrote:
>
>
> > On Dec 30, 2019, at 7:32 PM, Lars Kurth
wrote:
> >
> > From: Lars Kurth
> >
>
On 15/01/2020 11:40, Jan Beulich wrote:
> On 15.01.2020 10:47, Roger Pau Monné wrote:
>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
>>>
>>> void cstate_restore
On 15/01/2020 11:32, Jan Beulich wrote:
> On 14.01.2020 20:36, Igor Druzhinin wrote:
>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>> all AMD and some old Intel processors. In which case TSC would need
On 15/01/2020 12:25, Igor Druzhinin wrote:
> On 15/01/2020 11:40, Jan Beulich wrote:
>> On 15.01.2020 10:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -955,10 +955,16 @@ u64 stime2
On 15/01/2020 09:47, Roger Pau Monné wrote:
> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>> all AMD and some old Intel processors. In w
On 15.01.2020 13:28, Igor Druzhinin wrote:
> On 15/01/2020 11:32, Jan Beulich wrote:
>> On 14.01.2020 20:36, Igor Druzhinin wrote:
>>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>>> all AMD and some ol
On 15/01/2020 11:17, Jan Beulich wrote:
> On 14.01.2020 21:35, Andrew Cooper wrote:
>> Xen inherited its list infrastructure from Linux. One area where has fallen
>> behind is that of prefetching, which as it turns out is a performance penalty
>> in most cases.
>>
>> Prefetch of NULL on x86 is now
On 15.01.2020 13:31, Igor Druzhinin wrote:
> On 15/01/2020 12:25, Igor Druzhinin wrote:
>> On 15/01/2020 11:40, Jan Beulich wrote:
>>> On 15.01.2020 10:47, Roger Pau Monné wrote:
On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arc
On 15/01/2020 12:39, Jan Beulich wrote:
> On 15.01.2020 13:28, Igor Druzhinin wrote:
>> On 15/01/2020 11:32, Jan Beulich wrote:
>>> On 14.01.2020 20:36, Igor Druzhinin wrote:
If ITSC is not available on CPU (e.g if running nested as PV shim)
then X86_FEATURE_NONSTOP_TSC is not advertised
On 15.01.2020 12:53, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
>> On 15.01.2020 10:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -955,10
CRTC state properties should be computed in atomic_check(). Do so for
the no_vblank field.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
i
In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
For drivers that have neither an enable_vblank() callback nor a check()
callback, the simple-KMS helpers enable VBLANK generation by default. This
simplif
In drm_atomic_helper_fake_vblank(), the DRM core sends out VBLANK
events if struct drm_crtc_state.no_vblank is enabled. Replace cirrus'
VBLANK events with the DRM core's functionality.
v2:
* set struct_drm_crtc_state.no_vblank in cirrus_pipe_check()
Signed-off-by: Thomas Zimmermann
---
Drivers for CRTC hardware without support for VBLANK interrupts can set
struct drm_crtc_state.no_vblank and let DRM's atomic commit helpers
generate the VBLANK events automatically. Document this in order to make
it official.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_atomic_helper
(Resending because I did not cc dri-devel properly.)
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over several drivers.
Ast already uses the functionality a
On 14/01/2020 16:25, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/x86_64/page.h
>> +++ b/xen/include/asm-x86/x86_64/page.h
>> @@ -172,18 +172,11 @@ static inline intpte_t put_pte_flags(unsigned int x)
>> #define PAGE_HYPERVISOR_RX (__PAGE_HYPERVISOR_RX | _PAGE_GLOBAL)
>> #define PAGE
On 15.01.2020 13:47, Igor Druzhinin wrote:
> On 15/01/2020 12:39, Jan Beulich wrote:
>> On 15.01.2020 13:28, Igor Druzhinin wrote:
>>> On 15/01/2020 11:32, Jan Beulich wrote:
On 14.01.2020 20:36, Igor Druzhinin wrote:
> If ITSC is not available on CPU (e.g if running nested as PV shim)
>>>
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
---
drivers/net/xen-netback/hash.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-net
Hi,
On 15-01-2020 13:52, Thomas Zimmermann wrote:
(Resending because I did not cc dri-devel properly.)
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over s
On 15.01.2020 13:53, Andrew Cooper wrote:
> On 14/01/2020 16:25, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/x86_64/page.h
>>> +++ b/xen/include/asm-x86/x86_64/page.h
>>> @@ -172,18 +172,11 @@ static inline intpte_t put_pte_flags(unsigned int x)
>>> #define PAGE_HYPERVISOR_RX (__PAGE_HYP
On Wed, Jan 15, 2020 at 12:36:08PM +, Igor Druzhinin wrote:
> On 15/01/2020 09:47, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> >> If ITSC is not available on CPU (e.g if running nested as PV shim)
> >> then X86_FEATURE_NONSTOP_TSC is not advertis
On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
> On 15.01.2020 12:53, Roger Pau Monné wrote:
> > On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
> >> On 15.01.2020 10:47, Roger Pau Monné wrote:
> >>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> -
Thanks for the patch.
There is a typo in the subject line. It should say xen-netback, not
xen-netbank.
On Wed, Jan 15, 2020 at 06:11:28PM +0530, madhuparnabhowmi...@gmail.com wrote:
> From: Madhuparna Bhowmik
>
> list_for_each_entry_rcu has built-in RCU and lock checking.
> Pass cond argument t
On Wed, Jan 15, 2020 at 7:26 PM Wei Liu wrote:
> Thanks for the patch.
>
> There is a typo in the subject line. It should say xen-netback, not
> xen-netbank.
>
> Hi,
I am sorry about this, I will send this patch again.
> On Wed, Jan 15, 2020 at 06:11:28PM +0530, madhuparnabhowmi...@gmail.com
>
Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
C code has nevertheless caused several bugs I should have known better about,
and contributed to review confusion.
There are exactly 4 uses of these constants in asm code (and one is shortly
going to disappear).
Instea
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
---
drivers/net/xen-netback/hash.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netback
On 15/01/2020 10:26, Jan Beulich wrote:
> While it has been me to introduce this, the use of | there has become
> (and perhaps was from the very beginning) misleading. Rather than
> avoiding the right side of it when linking the xen.efi intermediate file
> at a different base address, make the expr
On 15/01/2020 13:23, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 12:36:08PM +, Igor Druzhinin wrote:
>> On 15/01/2020 09:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
If ITSC is not available on CPU (e.g if running nested as PV shim)
>>
On 15/01/2020 12:54, Jan Beulich wrote:
> On 15.01.2020 13:47, Igor Druzhinin wrote:
>> On 15/01/2020 12:39, Jan Beulich wrote:
>>> On 15.01.2020 13:28, Igor Druzhinin wrote:
On 15/01/2020 11:32, Jan Beulich wrote:
> On 14.01.2020 20:36, Igor Druzhinin wrote:
>> If ITSC is not availabl
On Wed, Jan 15, 2020 at 07:36:38PM +0530, Madhuparna Bhowmik wrote:
[...]
>
> > The surrounding code makes it pretty clear that the lock is already held
> > by the time list_for_each_entry_rcu is called, yet the checking involved
> > in lockdep_is_held is not trivial, so I'm afraid I don't conside
On Wed, Jan 15, 2020 at 07:48:40PM +0530, madhuparnabhowmi...@gmail.com wrote:
> 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
You seem to have dropped the second h
On 14/01/2020 16:05, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 05/12] tools/migration: Drop IHDR_VERSION
> constant from libxc and python"):
>> Migration v3 is in the process of being introduced, meaning that the code has
>> to cope with both versions. Use an explicit 2 for now.
>>
>> Fo
On 14/01/2020 16:08, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 10/12] docs/migration: Specify
> X86_{CPUID,MSR}_POLICY records"):
>> These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
>> hypercall.
> We had an extensive IRL discussion recently about the compatibility
>
On Wed, Jan 15, 2020 at 8:34 PM Wei Liu wrote:
> On Wed, Jan 15, 2020 at 07:36:38PM +0530, Madhuparna Bhowmik wrote:
> [...]
> >
> > > The surrounding code makes it pretty clear that the lock is already
> held
> > > by the time list_for_each_entry_rcu is called, yet the checking
> involved
> > >
On Wed, Jan 15, 2020 at 8:35 PM Wei Liu wrote:
> On Wed, Jan 15, 2020 at 07:48:40PM +0530, madhuparnabhowmi...@gmail.com
> wrote:
> > 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
On 14/01/2020 16:12, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 10/12] docs/migration: Specify
> X86_{CPUID,MSR}_POLICY records"):
>> The migration stream is split into records with no playload (markers
>> with external control flow meaning), and data records, which have a payload.
> I
On 14/01/2020 17:21, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 12/12] libxc/save: Write X86_{CPUID,MSR}_DATA
> records"):
>> With all other plumbing in place, obtain the CPU Policy from Xen and
>> write it into the migration stream.
> This looks good to me but:
>
> This patch may need rev
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
---
drivers/net/xen-netback/hash.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-net
On Wed, Jan 15, 2020 at 02:36:24PM +, Andrew Cooper wrote:
> On 15/01/2020 10:26, Jan Beulich wrote:
> > While it has been me to introduce this, the use of | there has become
> > (and perhaps was from the very beginning) misleading. Rather than
> > avoiding the right side of it when linking the
On 14/01/2020 17:27, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 16/20] tools/libxl: Simplify callback handling
> in libxl-save-helper"):
>> The {save,restore}_callback helpers can have their scope reduced vastly,
> This part is OK with me although it would have been nicer to review if
> th
On 15.01.2020 14:44, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
>> What I'm then worried about is too
>> little progress observable by guests. The PV time protocol
>> ought to be fine in this regard (and consumers of raw TSC values
>> are on their own anyw
On 15/01/2020 16:27, Jan Beulich wrote:
> On 15.01.2020 15:36, Andrew Cooper wrote:
>> On 15/01/2020 10:26, Jan Beulich wrote:
>>> While it has been me to introduce this, the use of | there has become
>>> (and perhaps was from the very beginning) misleading. Rather than
>>> avoiding the right side
On 15.01.2020 15:36, Andrew Cooper wrote:
> On 15/01/2020 10:26, Jan Beulich wrote:
>> While it has been me to introduce this, the use of | there has become
>> (and perhaps was from the very beginning) misleading. Rather than
>> avoiding the right side of it when linking the xen.efi intermediate fi
On 15.01.2020 17:29, Andrew Cooper wrote:
> On 15/01/2020 16:27, Jan Beulich wrote:
>> On 15.01.2020 15:36, Andrew Cooper wrote:
>>> On 15/01/2020 10:26, Jan Beulich wrote:
While it has been me to introduce this, the use of | there has become
(and perhaps was from the very beginning) misl
On 15/01/2020 11:09, Jürgen Groß wrote:
> On 15.01.20 11:54, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> On 08/01/2020 15:20, Sergey Dyasli wrote:
>>> It is incorrect to call pmd_populate_kernel() multiple times for the
>>> same page table. Xen notices it during kasan_populate_early_shadow():
>>>
>>>
On 14/01/2020 17:30, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 17/20] tools/libx[cl]: Plumb static_data_done()
> up into libxl"):
>> /* callbacks provided by xc_domain_restore */
>> struct restore_callbacks {
>> +/*
>> + * Called once the STATIC_DATA_END record has been received
Exclude intermidiate files .*.tmp from the linkfarm, those are
generated by %.o:%.c rules in xen/Rules.mk when
CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
Signed-off-by: Anthony PERARD
---
tools/firmware/xen-dir/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/firmware/xen-dir/Makefile b/
On Wed, Jan 15, 2020 at 02:46:29AM +0100, Marek Marczykowski-Górecki wrote:
> QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> MSI(-X) enable flags in the PCI config space. This adds an attribute
> 'allow_interrupt_control' which when set for a PCI device allows writes
> to
dev @distro suggested I post this here ...
I've a recently upgraded Xen & Kernel on
lsb_release -rd
Description:openSUSE Leap 15.1
Release:15.1
Atm, I'm running
Xen 4.13.0_04
server, on EFI hardware + Intel Xeon E3 CPU, with kernel
Now that Kconfig has the capability to run shell command when
generating CONFIG_* we can use it in some cases to test CFLAGS.
CONFIG_INDIRECT_THUNK is a good example that wants to exist both in
Makefile and as a C macro, which Kconfig do. So use Kconfig to
generate CONFIG_INDIRECT_THUNK and have t
The check for $(CC) -fvisibility=hidden is done by both arm and x86,
so the patch also move the check to the common area.
The check doesn't check if $(CC) is gcc, and clang can accept that
option as well, so s/GCC/CC/ is done to the define name.
Signed-off-by: Anthony PERARD
Acked-by: Andrew Coo
This import several files from Linux v5.3
- scripts/Kconfig.include
- scripts/clang-version.sh
- scripts/gcc-version.sh
and several config values from from Linux's init/Kconfig file.
But gcc-version.sh have been modified to return "0" when $CC isn't
GCC, like clang-version.sh do.
Files are cop
This is in preparation of importing Kbuild to build Xen. We won't be
able to include Config.mk so we will need a replacement for the macro
`cc-ifversion'.
This patch imports parts of "scripts/Kbuild.include" from Linux v5.4,
the macro cc-ifversion. It makes use of CONFIG_GCC_VERSION that
Kconfig n
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-kconfig-v3
v3:
- change in patch 2. gcc-version.sh now behave like clang-version.sh.
otherwise, the series should be ready.
v2:
- nit changes in patch 1 and 2.
Cheers,
Kconfig can check if $(CC) is clang or not, if it is
CONFIG_CC_IS_CLANG will be set.
With that patch, the hypervisor can be built using clang by running
`make CC=clang CXX=clang++` without needed to provide an extra clang
parameter.
`make clang=y` still works as Config.mk will set CC and CXX.
Si
On 1/15/20 12:22 PM, Lars Kurth wrote:
> @George, @Ian: let me know whether this is better and addresses your
> concerns
This looks good to me.
One side note:
> The way how a reviewer expresses feedback, has a big impact on how the author
"The way how X happens" isn't grammatically correct; it
On 15/01/2020 16:52, PGNet Dev wrote:
> dev @distro suggested I post this here ...
>
> I've a recently upgraded Xen & Kernel on
>
> lsb_release -rd
> Description:openSUSE Leap 15.1
> Release:15.1
>
> Atm, I'm running
>
> Xen 4.13.0_04
>
> server,
Anthony PERARD writes ("[XEN PATCH] linkfarm: Exclude .*.tmp"):
> Exclude intermidiate files .*.tmp from the linkfarm, those are
> generated by %.o:%.c rules in xen/Rules.mk when
> CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
>
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
flight 146094 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-stop fail REGR. vs. 146058
Tests which did no
hi
On 1/15/20 9:10 AM, Andrew Cooper wrote:
>> Is this a known/fixable issue?
>
> The APIC errors aren't fatal. They need looking into and addressing in
> due course.
>
> The real crash is EFI firmware falling over a NULL pointer which is
> wildly known issue. Fixing it requires following the
On 15/01/2020 17:19, PGNet Dev wrote:
> hi
>
> On 1/15/20 9:10 AM, Andrew Cooper wrote:
>>> Is this a known/fixable issue?
>> The APIC errors aren't fatal. They need looking into and addressing in
>> due course.
>>
>> The real crash is EFI firmware falling over a NULL pointer which is
>> wildly kn
On Wed, Jan 15, 2020 at 09:25:53PM +0530, madhuparnabhowmi...@gmail.com wrote:
> 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
Acked-by: Wei Liu
_
On 1/15/20 9:21 AM, Andrew Cooper wrote:
> That is the command line for dom0 which is a VM. You need the Xen
> hypervisor command line.
thx. done.
> You'll need to edit xen-4.13.0_04-lp151.688.cfg which will be somewhere
> on the ESP (wherever that is mounted in an openSUSE system).
verifying,
I should have added more people to this change. The issue without this fix is
that entries such as
L: xen-devel
break get_maintainer.pl and thus add_maintainers.pl
Lars
On 10/01/2020, 21:19, "Lars Kurth" wrote:
From: Lars Kurth
Prior to this change e-mail addresses of the for
On Fri, 10 Jan 2020 22:41:49 +0300
Vladimir Sementsov-Ogievskiy wrote:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
> can't see this a
This logic was inherited from x86 (which was updated several times since).
Unlike x86 (at the time) however, while NULL isn't mapped in ARM, 0xf000
is, making this actively dangerous.
Drop the logic entirely, and leave 'current' as NULL during early boot.
Signed-off-by: Andrew Cooper
---
CC:
The BUG_ON() is confusing to follow. The (!is_idle_domain(d) || vcpu_id) part
is a vestigial remnant of architectures poisioning idle_vcpu[0] with non-NULL
pointers.
Now that idle_vcpu[0] is NULL on all architectures, and d->max_vcpus specified
before vcpu_create() is called, we can properly rang
Hi,
On 15/01/2020 18:43, Andrew Cooper wrote:
This logic was inherited from x86 (which was updated several times since).
Unlike x86 (at the time) however, while NULL isn't mapped in ARM, 0xf000
is, making this actively dangerous.
Drop the logic entirely, and leave 'current' as NULL during e
The code has devating from the prevailing style in many ways. Adjust spacing,
indentation, position of operators, layout of multiline comments, removal of
superfluous comments, constness, trailing commas, and use of unqualified
'unsigned'.
No functional change.
Signed-off-by: Andrew Cooper
---
1 - 100 of 114 matches
Mail list logo
