Hi, Dmitry!
I would appreciate your comments on the below
On 05/31/2017 12:06 PM, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 05/30/2017 07:37 PM, Dmitry Torokhov wrote:
On Tue, May 30, 2017 at 03:50:20PM +0300, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 05/30/2017 08:51 AM, Dmitry Tor
Change the third parameter to be the required struct xen_dm_op_buf *
instead of a generic void * (which blindly accepts any pointer).
Signed-off-by: Sergey Dyasli
---
v1 --> v2:
- Replaced "#include " with
forward declaration of struct xen_dm_op_buf
arch/x86/include/asm/xen/hypercall.h | 4 ++
On 17-06-07 09:31:02, Yi Sun wrote:
> On 17-06-06 02:38:27, Jan Beulich wrote:
> > >>> On 06.06.17 at 10:13, wrote:
> > > On 17-06-06 01:45:11, Jan Beulich wrote:
> > >> >>> On 02.06.17 at 09:26, wrote:
> > >> > On 17-05-31 03:37:48, Jan Beulich wrote:
> > >> >> >>> On 03.05.17 at 10:44, wrote:
> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 06 June 2017 18:41
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: xen-devel (xen-de...@lists.xenproject.org) de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
>
>
>>> On 06.06.17 at 19:00, wrote:
> FWIW, one of machines in our test farm choked on this very patch. I
> don't remember details now but essentially it turned out that syslinux
> (we are pxe-booting) could not handle changes in ELF sections layout
> (the way syslinux calculated how to load the bina
> -Original Message-
> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: 06 June 2017 18:00
> To: Paul Durrant ; 'Jan Beulich'
>
> Cc: xen-devel (xen-de...@lists.xenproject.org) de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to b
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 June 2017 09:07
> To: Boris Ostrovsky
> Cc: Paul Durrant ; xen-devel (xen-
> de...@lists.xenproject.org)
> Subject: Re: [Xen-devel] debian stretch dom0 + xen 4.9 fails to boot
>
> >>> On 06.06.17 at 19:00, wr
>>> On 06.06.17 at 21:19, wrote:
> On Tue, 6 Jun 2017, Jan Beulich wrote:
>> >>> On 06.06.17 at 16:00, wrote:
>> > Looking at the serial logs for that and comparing them with 10009,
>> > it's not terribly easy to see what's going on because the kernel
>> > versions are different and so produce di
flight 71523 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71523/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like
71462
test-amd64-i
>>> On 07.06.17 at 03:31, wrote:
> On 17-06-06 02:38:27, Jan Beulich wrote:
>> >>> On 06.06.17 at 10:13, wrote:
>> > On 17-06-06 01:45:11, Jan Beulich wrote:
>> >> >>> On 02.06.17 at 09:26, wrote:
>> >> > On 17-05-31 03:37:48, Jan Beulich wrote:
>> >> >> >>> On 03.05.17 at 10:44, wrote:
>> >> >
** Delivery incomplete **
There was a temporary problem delivering your message to
curtiskwo...@gmail.com. Gmail will retry for 46 more hours. You'll be notified
if the delivery fails permanently.
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2Y
flight 110047 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110047/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 9 debian-install fail REGR. vs. 110027
test-amd64-i386-xl
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 07 June 2017 09:10
> To: 'Jan Beulich' ; Boris Ostrovsky
>
> Cc: xen-devel (xen-de...@lists.xenproject.org) de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] debian str
** Delivery incomplete **
There was a temporary problem delivering your message to
curtiskwo...@gmail.com. Gmail will retry for 46 more hours. You'll be notified
if the delivery fails permanently.
Reporting-MTA: dns; googlemail.com
Received-From-MTA: dns; FWD-737QHYSMHVAYQAUCAOIQBDAAGAQLMA2Y
>>> On 07.06.17 at 10:07, wrote:
>> -Original Message-
>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>> Sent: 06 June 2017 18:00
>> To: Paul Durrant ; 'Jan Beulich'
>>
>> Cc: xen-devel (xen-de...@lists.xenproject.org) > de...@lists.xenproject.org>
>> Subject: Re: [Xen-deve
>>> On 26.05.17 at 13:14, wrote:
> --- a/xen/include/asm-x86/page.h
> +++ b/xen/include/asm-x86/page.h
> @@ -375,6 +375,14 @@ perms_strictly_increased(uint32_t old_flags, uint32_t
> new_flags)
>
> #define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
>
> +static inline void invalidate_ic
flight 110068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 110043
Tests which
"Jan Beulich" writes:
On 26.05.17 at 13:14, wrote:
>> --- a/xen/include/asm-x86/page.h
>> +++ b/xen/include/asm-x86/page.h
>> @@ -375,6 +375,14 @@ perms_strictly_increased(uint32_t old_flags, uint32_t
>> new_flags)
>>
>> #define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
>>
>>
On 17-06-07 02:14:26, Jan Beulich wrote:
> >>> On 07.06.17 at 03:31, wrote:
> > On 17-06-06 02:38:27, Jan Beulich wrote:
> >> >>> On 06.06.17 at 10:13, wrote:
> >> > On 17-06-06 01:45:11, Jan Beulich wrote:
> >> >> >>> On 02.06.17 at 09:26, wrote:
> >> >> > On 17-05-31 03:37:48, Jan Beulich wrot
On 07/06/17 10:27, Jan Beulich wrote:
On 07.06.17 at 10:07, wrote:
>>> -Original Message-
>>> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>>> Sent: 06 June 2017 18:00
>>> To: Paul Durrant ; 'Jan Beulich'
>>>
>>> Cc: xen-devel (xen-de...@lists.xenproject.org) >> de...@l
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 07 June 2017 10:03
> To: Jan Beulich ; Paul Durrant
>
> Cc: Julien Grall (julien.gr...@arm.com) ; xen-devel
> (xen-de...@lists.xenproject.org) ; 'Boris
> Ostrovsky'
> Subject: Re: [Xen-devel] debian stretch dom0 +
On 07/06/2017 10:05, Paul Durrant wrote:
>> -Original Message-
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 07 June 2017 10:03
>> To: Jan Beulich ; Paul Durrant
>>
>> Cc: Julien Grall (julien.gr...@arm.com) ; xen-devel
>> (xen-de...@lists.xenproject.org) ; 'Boris
>> Ostrovsky'
On 31/05/17 15:03, Julien Grall wrote:
> Commit 5995a68 "xen/privcmd: Add support for Linux 64KB page granularity" did
> not go far enough to support 64KB in mmap_batch_fn.
>
> The variable 'nr' is the number of 4KB chunk to map. However, when Linux
> is using 64KB page granularity the array of pa
Am Freitag, 19. Mai 2017, 06:41:36 schrieb Jan Beulich:
> >>> On 19.05.17 at 11:52, wrote:
> > I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
> > yes I know - very old ;-), but the affected code hasn't much changed.
>
> Well, at the very least I'd expect you to base you
Commit edff605421 introduces an empty invalidate_icache() function in
page.h for x86 but mistakenly places it outside the !__ASSEMBLY__
block. This causes build failure on x86.
Address this by moving the function definition to within the existing
!__ASSEMBLY__ block.
Fixes: edff605421 ("Avoid exc
Stefano Stabellini writes:
> On Tue, 6 Jun 2017, Julien Grall wrote:
>> On 26/05/17 12:14, Punit Agrawal wrote:
>> > Hi,
>>
>> Hi,
>>
>> It looks like this patch series has been fully acked. Can someone apply it?
>
> Done. It was appropriately marked in my inbox, but I was somehow
> reluctant t
From the context calling pi_desc_init(), we can conclude the current
implementation of VT-d PI depends on CPU-side PI. If we disable APICv
but enable VT-d PI explicitly in xen boot command line, we would get
an assertion failure.
This patch disables VT-d PI when APICv is disabled and adds some
rel
flight 110056 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110056/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9c94cc2ca270c2a9121c485281792c178281ac7d
baseline version:
ovmf 7b5d848dbfc3abe8b8c60
>>> On 06.06.17 at 19:52, wrote:
> On Wed, May 31, 2017 at 01:25:26AM -0600, Jan Beulich wrote:
>> Eliminate the for_each_vcpu() loop and the associated local variables,
>> don't override the save handler's return code, and correct formatting.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/co
On 07/06/17 09:20, Sergey Dyasli wrote:
> Change the third parameter to be the required struct xen_dm_op_buf *
> instead of a generic void * (which blindly accepts any pointer).
>
> Signed-off-by: Sergey Dyasli
Reviewed-by: Juergen Gross
Thanks,
Juergen
_
>>> On 07.06.17 at 11:28, wrote:
> Am Freitag, 19. Mai 2017, 06:41:36 schrieb Jan Beulich:
>> >>> On 19.05.17 at 11:52, wrote:
>> > I'am struggling with a hypervisor panic. The hypervisor version is 4.4.3,
>> > yes I know - very old ;-), but the affected code hasn't much changed.
>>
>> Well, at
On Wed, Jun 07, 2017 at 04:07:02AM -0600, Jan Beulich wrote:
> >>> On 06.06.17 at 19:52, wrote:
> > On Wed, May 31, 2017 at 01:25:26AM -0600, Jan Beulich wrote:
> >> Eliminate the for_each_vcpu() loop and the associated local variables,
> >> don't override the save handler's return code, and corre
On 06/06/17 20:41, Boris Ostrovsky wrote:
There is a single call site for rebind_irq_to_cpu() so why not call
xen_rebind_evtchn_to_cpu() directly?
Fair enough, I will change it.
+ raw_spin_lock_irqsave(&desc->lock, flags);
Is there a reason why you are using raw_ version?
desc->l
On 06/06/17 21:58, Boris Ostrovsky wrote:
Oh well, so much for my request to move it. So you are going to make it
global to the file.
Sorry about build breakage. I will move
DEFINE_PER_CPU(bind_last_selected_cpu) above
evtchn_bind_interdom_next_vcpu().
-Anoob.
> -Original Message-
[snip]
> >>
> >> TBH: I really can't see what is wrong with that patch. The only change
> >> which should be able to break something seems to be the reduction of
> the
> >> wakeup stack size to 3kB, but this shouldn't affect booting the system
> >> at all...
> >>
> > Ye
>>> On 07.06.17 at 11:34, wrote:
> This commit fixes the build breakage in staging for me. I'm not sure
> whether staging gets rebased so sending this as a separate commit.
No, we don't re-base. If anything (e.g. when a fix doesn't
arrive pretty quickly or needs more thought) we revert.
Jan
__
>>> On 07.06.17 at 12:29, wrote:
> On Wed, Jun 07, 2017 at 04:07:02AM -0600, Jan Beulich wrote:
>> >>> On 06.06.17 at 19:52, wrote:
>> > On Wed, May 31, 2017 at 01:25:26AM -0600, Jan Beulich wrote:
>> >> if ( !ctxt.data )
>> >> return -ENOMEM;
>> >>
>> >> -if ( hvm_sr_handlers
Hi,
On 06/06/17 19:46, Stefano Stabellini wrote:
> On Tue, 6 Jun 2017, Andre Przywara wrote:
>> Maybe we should consider to merge this one for 4.9 still,
>> as currently enabling the ITS in .config and running it on an ITS
>> machine will fail to boot Dom0.
>
> Here, you are talking about this pa
On 05/06/17 16:58, Lars Kurth wrote:
Hi all,
Hi Lars,
removed xen-announce
I created the following docs
Thank you for doing this.
https://wiki.xenproject.org/wiki/Category:Xen_4.9
If anyone created any 4.9 specific docs, feel free to add to the page or
let me know: I added links to gen
Hi,
On 01/06/17 19:43, Andrew Cooper wrote:
On 01/06/17 18:34, Dario Faggioli wrote:
These should all be static inlines in a header file. This will avoid
forcing the compiler to insert a bunch of empty functions and have to
call them, and it allows you to modify the x86 Makefile to be
andrewco
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 07 June 2017 11:37
> To: Andrew Cooper ; 'Juergen Gross'
> ; Jan Beulich
> Cc: xen-devel (xen-de...@lists.xenproject.org) de...@lists.xenproject.org>; Julien Grall (julien.g
flight 110050 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110050/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
test-amd64-i386-xl-qe
flight 110077 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110077/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 3d2010f9ffeacc8836811420460e15f2c1233695
baseline version:
xen d8ee
Hi Dario,
On 01/06/17 18:34, Dario Faggioli wrote:
Trace when interrupts are disabled and (re)enabled.
Basically, we replace the IRQ disabling and enabling
functions with helpers that does the same, but also
output the proper trace record.
For putting in the record something that will let
us id
On 06/06/17 11:19, Andre Przywara wrote:
Hi,
On 30/05/17 12:38, Julien Grall wrote:
Hi Andre,
On 26/05/17 18:35, Andre Przywara wrote:
For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, tea
On 26/05/17 12:14, Punit Agrawal wrote:
> diff --git a/xen/common/memory.c b/xen/common/memory.c
> index 52879e7438..34d2dda8b4 100644
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -152,16 +152,26 @@ static void populate_physmap(struct memop_args *a)
> ma
On 07/06/17 12:19, Andrew Cooper wrote:
On 26/05/17 12:14, Punit Agrawal wrote:
@@ -211,7 +221,6 @@ static void populate_physmap(struct memop_args *a)
}
mfn = gpfn;
-page = mfn_to_page(mfn);
What is the purpose of this hunk?
It is not menti
flight 110074 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110074/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-buildfail REGR. vs. 110043
Tests which
Julien Grall writes:
> On 07/06/17 12:19, Andrew Cooper wrote:
>> On 26/05/17 12:14, Punit Agrawal wrote:
>>> @@ -211,7 +221,6 @@ static void populate_physmap(struct memop_args *a)
>>> }
>>>
>>> mfn = gpfn;
>>> -page = mfn_to_page(mfn);
>>
>> What
A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
interrupts,in a short period of time. All these evtchn:qemu-dm are bound
to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
In one configuration, irqbalance runs every 10 seconds, which means
irqbalance do
>>> On 07.06.17 at 12:36, wrote:
>> -Original Message-
> [snip]
>> >>
>> >> TBH: I really can't see what is wrong with that patch. The only change
>> >> which should be able to break something seems to be the reduction of
>> the
>> >> wakeup stack size to 3kB, but this shouldn't affect bo
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 June 2017 12:50
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel (xen-
> de...@lists.xenproject.org) ; 'Boris
> Ostrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel]
On 07/06/17 13:06, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
>> Paul Durrant
>> Sent: 07 June 2017 11:37
>> To: Andrew Cooper ; 'Juergen Gross'
>> ; Jan Beulich
>> Cc: xen-devel (xen-de...@lists.xenproject.org) > de..
>>> On 07.06.17 at 13:55, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 June 2017 12:50
>> 2) Provide the E820 map of that box.
>> I'm suspecting the BIOS might use an EBDA without recording it in
>> the low BIOS data area. If it's reported in E820 that would then
>> likely be
> -Original Message-
> From: Juergen Gross [mailto:jgr...@suse.com]
> Sent: 07 June 2017 12:57
> To: Paul Durrant ; Andrew Cooper
> ; Jan Beulich
> Cc: xen-devel (xen-de...@lists.xenproject.org) de...@lists.xenproject.org>; Julien Grall (julien.gr...@arm.com)
> ; 'Boris Ostrovsky'
> Subj
Commit 726b737574 makes an unrelated change deleting a line setting the
page from mfn. Although the page variable is not used, it is an
unrelated change. The setting of the page variable was introduced to
match the else part of is_domain_direct_mapped() in populate_physmap().
Re-introduce the miss
On 07/06/17 14:02, Paul Durrant wrote:
>> -Original Message-
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 07 June 2017 12:57
>> To: Paul Durrant ; Andrew Cooper
>> ; Jan Beulich
>> Cc: xen-devel (xen-de...@lists.xenproject.org) > de...@lists.xenproject.org>; Julien Grall (julie
>>> On 07.06.17 at 14:04, wrote:
> Commit 726b737574 makes an unrelated change deleting a line setting the
> page from mfn. Although the page variable is not used, it is an
> unrelated change. The setting of the page variable was introduced to
> match the else part of is_domain_direct_mapped() in
flight 110054 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110054/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 guest-start fail REGR. vs. 109975
test-amd64-amd64-
On 07/06/17 13:13, Jan Beulich wrote:
On 07.06.17 at 14:04, wrote:
Commit 726b737574 makes an unrelated change deleting a line setting the
page from mfn. Although the page variable is not used, it is an
unrelated change. The setting of the page variable was introduced to
match the else part o
>>> On 07.06.17 at 14:02, wrote:
>> From: Juergen Gross [mailto:jgr...@suse.com]
>> Sent: 07 June 2017 12:57
>>
>> On 07/06/17 13:06, Paul Durrant wrote:
>> > It appears that it is just the code that needs to go at the end. The
>> > following
>> patch is sufficient to avoid the problem. This may
On Tue, Jun 06, 2017 at 09:48:37PM -0400, Boris Ostrovsky wrote:
> On 06/06/2017 09:39 AM, Max Vozeler wrote:
> >there is a problem booting recent kernels on some Xen domUs hosted by
> >provider JiffyBox.
> >
> >The kernel seems to crash just after logging
> >[0.038700] SMP alternatives: switch
This run is configured for baseline tests only.
flight 71524 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71524/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-libvirt 5 libvirt-buildfai
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 June 2017 13:19
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel (xen-
> de...@lists.xenproject.org) ; 'Boris
> Ostrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel]
>>> On 07.06.17 at 11:29, wrote:
> @@ -2266,8 +2267,10 @@ int __init intel_vtd_setup(void)
> * We cannot use posted interrupt if X86_FEATURE_CX16 is
> * not supported, since we count on this feature to
> * atomically update 16-byte IRTE in posted format.
> + *
>>> On 07.06.17 at 14:26, wrote:
> I'm currently trying to figure out what the code in head.S
> just ahead of trampoline_setup is trying to do.
That's where we determine where to put the trampoline, by looking
at base memory size, EBDA location, and the MB provided low
memory size. Insane values
On Friday, 19 May 2017 1:28:46 AM AEST Juergen Gross wrote:
> Destroying a Xen guest domain while it was doing I/Os via xen-blkback
> leaked several resources, including references of the guest's memory
> pages.
>
> This patch series addresses those leaks by correcting usage of
> reference counts
>>> On 06.06.17 at 18:01, wrote:
> It is not suitable for Xen's use (being xapic and x2apic compatible), and the
> comment doesn't inspire much confidence in its correctness.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
___
Xen-devel mai
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 07 June 2017 13:00
> To: Paul Durrant
> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
> Cooper ; xen-devel(xen-
> de...@lists.xenproject.org) ;
> 'BorisOstrovsky' ; Juergen Gross
>
> Subject: RE: [Xen-devel] de
>>> On 06.06.17 at 18:01, wrote:
> It is unconditionally selected, and all 64bit processors have local APICs.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-de
>>> On 06.06.17 at 18:01, wrote:
> It is unconditionally selected, and compiling out IO-APIC support is not a
> useful think to do these days.
thing?
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lis
On 07/06/17 13:49, Jan Beulich wrote:
On 06.06.17 at 18:01, wrote:
>> It is unconditionally selected, and compiling out IO-APIC support is not a
>> useful think to do these days.
> thing?
Yes - I already noticed and fixed.
>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
Than
>>> On 07.06.17 at 14:46, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 07 June 2017 13:00
>> To: Paul Durrant
>> Cc: Julien Grall (julien.gr...@arm.com) ; Andrew
>> Cooper ; xen-devel(xen-
>> de...@lists.xenproject.org) ;
>> 'BorisOstrovsky' ; Jue
The amount of namespace resolution is unnecessrily large, as all code deals in
terms of struct segment_register. This removes the .fields part of all
references, and alters .bytes for .raw.
No functional change. For some reason I can't identify, the changes to
{rm,vm86}_{cs,ds}_attr causes GCC t
Signed-off-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libvchan/Makefile | 2 +-
tools/libxc/Makefile| 2 +-
tools/libxl/Makefile| 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/libvchan/Makefile b/tools/libvchan/Makefile
index 5b631cb1ab..70c92bda15 100644
--
>>> On 02.06.17 at 15:58, wrote:
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -164,6 +164,25 @@ static void pt_irq_time_out(void *data)
>
> spin_lock(&irq_map->dom->event_lock);
>
> +if ( irq_map->flags & HVM_IRQ_DPCI_IDENTITY_GSI )
> +{
> +
>>> On 01.06.17 at 13:49, wrote:
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -158,6 +158,52 @@ static int vioapic_read(
> return X86EMUL_OKAY;
> }
>
> +static int vioapic_hwdom_map_gsi(unsigned int gsi, unsigned int trig,
> + u
>>> On 07.06.17 at 15:04, wrote:
> RFC, because I'd also like to float the idea of making this adjustment as
> well:
>
> diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h
> b/xen/arch/x86/x86_emulate/x86_emulate.h
> index 3355c01..53a5480 100644
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
On Wed, Jun 07, 2017 at 10:36:58PM +1000, Steven Haigh wrote:
> On Friday, 19 May 2017 1:28:46 AM AEST Juergen Gross wrote:
> > Destroying a Xen guest domain while it was doing I/Os via xen-blkback
> > leaked several resources, including references of the guest's memory
> > pages.
> >
> > This pat
1: sanitize DOMCTL_gethvmcontext_partial handling
2: clean up hvm_save_one()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Have the caller indicate its buffer size, provide a means to query the
needed size, don't ignore the upper halves of type code and instance,
and don't copy partial data.
Signed-off-by: Jan Beulich
Acked-by: Wei Liu
---
v2: Re-base.
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@
Eliminate the for_each_vcpu() loop and the associated local variables,
don't override the save handler's return code, and correct formatting.
Signed-off-by: Jan Beulich
---
v2: Update ctxt.size instead of the global array's field.
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -79,36
On Wed, Jun 07, 2017 at 07:56:33AM -0600, Jan Beulich wrote:
> Eliminate the for_each_vcpu() loop and the associated local variables,
> don't override the save handler's return code, and correct formatting.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
1: use VMCB accessors
2: infer type in VMCB_ACCESSORS()
3: clean up svm_vmcb_dump()
4: clean up svm_vmcb_isvalid()
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Just saw the message:
[0.005227] mce: CPU supports 2 MCE banks
in the boot log of a pv domU (Linux 4.11). I really have problems to see
the value of MCE handling being active in this case. Shouldn't we switch
it off?
Juergen
___
Xen-devel mailing
This is particularly relevant for the SET form, to ensure proper clean
bits tracking (albeit in the case here it's benign as CPL and other
segment register attributes share a clean bit).
Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
--- unstable.orig/xen/arch/x86/hvm/svm/svm.c2017-0
Prevent accidental mistakes by not requiring explicit types to be
specified in the macro invocations.
Signed-off-by: Jan Beulich
---
v2: Drop commented out accessors instead of adjusting them.
--- unstable.orig/xen/include/asm-x86/hvm/svm/vmcb.h2017-06-01
14:30:23.0 +0200
+++ unstab
On 06/07/2017 04:07 AM, Jan Beulich wrote:
On 06.06.17 at 19:00, wrote:
>> FWIW, one of machines in our test farm choked on this very patch. I
>> don't remember details now but essentially it turned out that syslinux
>> (we are pxe-booting) could not handle changes in ELF sections layout
>> (
- constify parameter
- use accessors
- drop stray casts
- adjust formatting
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -26,60 +26,52 @@ static void svm_dump_sel(const char *nam
name, s->sel, s->attr.bytes, s->limit, s->ba
- correct CR3, CR4, and EFER checks
- delete bogus nested paging check
- add vcpu parameter (to include in log messages) and constify vmcb one
- use bool/true/false
- use accessors
- adjust formatting
Signed-off-by: Jan Beulich
---
v2: Constrain CR3 checks to the case when CR0.PG is set. Change w
On Wednesday, 7 June 2017 11:52:34 PM AEST Konrad Rzeszutek Wilk wrote:
> On Wed, Jun 07, 2017 at 10:36:58PM +1000, Steven Haigh wrote:
> > On Friday, 19 May 2017 1:28:46 AM AEST Juergen Gross wrote:
> > > Destroying a Xen guest domain while it was doing I/Os via xen-blkback
> > > leaked several re
>>> On 07.06.17 at 16:00, wrote:
> Just saw the message:
>
> [0.005227] mce: CPU supports 2 MCE banks
>
> in the boot log of a pv domU (Linux 4.11). I really have problems to see
> the value of MCE handling being active in this case. Shouldn't we switch
> it off?
What's wrong with letting a
flight 110083 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110083/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 12 mig
On Thu, Jun 01, 2017 at 07:33:33PM +0200, Dario Faggioli wrote:
> Hello,
>
> While chasing and dealing with bugs, over this last period, I've found myself
> augmenting Xen with quite a few new tracing capabilities, especially focusing
> on:
> - IRQ being disabled and (re)enabled (in addition to t
Wei Liu writes ("[PATCH] tools: bump some library version numbers to 4.10"):
> Signed-off-by: Wei Liu
Acked-by: Ian Jackson
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 07/06/17 16:10, Jan Beulich wrote:
On 07.06.17 at 16:00, wrote:
>> Just saw the message:
>>
>> [0.005227] mce: CPU supports 2 MCE banks
>>
>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>> the value of MCE handling being active in this case. Shouldn't we sw
>>> On 07.06.17 at 16:23, wrote:
> On 07/06/17 16:10, Jan Beulich wrote:
> On 07.06.17 at 16:00, wrote:
>>> Just saw the message:
>>>
>>> [0.005227] mce: CPU supports 2 MCE banks
>>>
>>> in the boot log of a pv domU (Linux 4.11). I really have problems to see
>>> the value of MCE handling
On 06/07/2017 07:46 AM, Anoob Soman wrote:
> A HVM domian booting generates around 200K (evtchn:qemu-dm xen-dyn)
> interrupts,in a short period of time. All these evtchn:qemu-dm are bound
> to VCPU 0, until irqbalance sees these IRQ and moves it to a different VCPU.
> In one configuration, irqbalan
>>> On 01.06.17 at 19:33, wrote:
> In fact, right now, we read it at every iteration of the loop.
> The reason it's done like this is how context switch was handled
> on IA64 (see commit ae9bfcdc, "[XEN] Various softirq cleanups" [1]).
>
> However:
> 1) we don't have IA64 any longer, and all the
>>> On 01.06.17 at 19:33, wrote:
> In fact, when calling __trace_var() directly, we can
> assume that tb_init_done has been checked to be true,
> and the if is hence redundant.
The "assume" here worries me: What if there's a single place
somewhere that a grep can't easily find where no check is
p
1 - 100 of 183 matches
Mail list logo
