> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 16 June 2017 18:34
> To: xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Ian Jackson
> ; Paul Durrant ; Wei Liu
> ; Dario Faggioli
> Subject: [OSSTEST PATCH 3/3] make-flight: Provide Windows 10 and
> Win
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 16 June 2017 18:34
> To: xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Ian Jackson
> ; Wei Liu ; Paul Durrant
>
> Subject: [OSSTEST PATCH 1/3] ts-windows-install: Honour memsize and
> disksize guest ru
> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
> Sent: 16 June 2017 16:57
> To: xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Ian Jackson
> ; Paul Durrant
> Subject: [OSSTEST PATCH] ts-windows-install: Provide guest with 32G of disk
> rather than 10G
>
>
>>> On 19.06.17 at 08:33, wrote:
> On Fri, Jun 16, 2017 at 09:52:11AM -0600, Jan Beulich wrote:
> On 16.06.17 at 08:48, wrote:
>>> The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>>> we would wrongly use 00:00.0 to search VT-d unit.
>>>
>>> To search VT-d unit for a VF, t
>>> On 18.06.17 at 21:19, wrote:
> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
> wrote:
>> On 04/04/17 14:14, Jan Beulich wrote:
>>> We shouldn't hand MFN info back from increase-reservation for
>>> translated domains, just like we don't for populate-physmap and
>>> memory-exchange. For full s
On Mon, Jun 19, 2017 at 01:43:25AM -0600, Jan Beulich wrote:
On 19.06.17 at 08:33, wrote:
>> On Fri, Jun 16, 2017 at 09:52:11AM -0600, Jan Beulich wrote:
>> On 16.06.17 at 08:48, wrote:
The problem is a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
we would wrongly use 00:
Hi,
On 19/06/17 09:15, Jan Beulich wrote:
On 18.06.17 at 21:19, wrote:
On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
wrote:
On 04/04/17 14:14, Jan Beulich wrote:
We shouldn't hand MFN info back from increase-reservation for
translated domains, just like we don't for populate-physmap and
mem
On 19/06/17 09:15, Jan Beulich wrote:
On 18.06.17 at 21:19, wrote:
>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
>> wrote:
>>> On 04/04/17 14:14, Jan Beulich wrote:
We shouldn't hand MFN info back from increase-reservation for
translated domains, just like we don't for populate
Hi Bhupinder,
I think the commit message is a bit misleading.
Actually you *rename* functions and their call sites, and also this
touches the VGIC code, so shouldn't it mention both in the first line of
the commit message? After all this patch really has not much to do with
vpl011.
On 06/06/17 18
On 17/06/17 01:14, Volodymyr Babchuk wrote:
> Hello George,
>
> On 31 May 2017 at 20:02, George Dunlap wrote:
There is no way out: if the stubdom needs events, then we'll have to
expose and context switch the vGIC. If it doesn't, then we can skip the
vGIC. However, we would have a
osstest service owner writes ("[linux-4.9 test] 110535: regressions - FAIL"):
> flight 110535 linux-4.9 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/110535/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-am
Hi,
Does Xen arm64 support hugepages for Dom0 ? If yes how to enable it.
Found wiki page on it :
https://wiki.xenproject.org/wiki/Huge_Page_Support but is not updated.
Thanks
-Manish
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.
On 14/06/17 11:33, Julien Grall wrote:
Hi Andrew,
On 06/12/2017 11:45 AM, Andrew Cooper wrote:
c/s b28044226e1 "x86: make Xen early boot code relocatable" introduces
mov $sym_offs(__image_base__),%esi
to the legacy boot path. However, this is by definition 0, which
means the
boot code
On 13/06/17 13:13, Ian Jackson wrote:
Dario Faggioli writes ("Re: [Xen-devel] [linux-4.9 test] 110371: regressions -
FAIL"):
So, this appears to be something related to linux-4.9 and that
particular board, I guess?
Yes, indeed. This has been broken for some time.
(If this was known and b
flight 71584 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71584/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR.
Hi,
On 14/06/17 18:55, Julien Grall wrote:
Hi Andre,
On 06/14/2017 05:51 PM, Andre Przywara wrote:
When reading the priority value of a virtual interrupt, we were taking
the respective rank lock so far.
However for forwarded interrupts (Dom0 only so far) this may lead to a
deadlock with the fo
Ping
On 06/08/2017 09:45 AM, Oleksandr Andrushchenko wrote:
Hi, Dmitry!
On 06/07/2017 07:56 PM, Dmitry Torokhov wrote:
On Wed, May 31, 2017 at 12:06:56PM +0300, 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,
flight 110550 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110550/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit2 3 host-install(3) broken pass in 110542
test-amd64-i386-xl-qemut-win7
Hi,
On 06/06/17 18:25, Bhupinder Thakur wrote:
> Add emulation code to emulate read/write access to pl011 registers
> and pl011 interrupts:
>
> - Emulate DR read/write by reading and writing from/to the IN
> and OUT ring buffers and raising an event to the backend when
> there is
>>> On 19.06.17 at 11:11, wrote:
> On 19/06/17 09:15, Jan Beulich wrote:
> On 18.06.17 at 21:19, wrote:
>>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
>>> wrote:
On 04/04/17 14:14, Jan Beulich wrote:
> We shouldn't hand MFN info back from increase-reservation for
> translate
osstest service owner writes ("[linux-4.9 test] 110513: regressions - FAIL"):
> flight 110513 linux-4.9 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/110513/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-am
Hi Julien,
I was mistaken in my earlier mail about vpl011 init working if it is
moved to libxl__arch_domain_create(). It is failing because as you
have mentioned vuart_pfn is allocated later in xc_dom_build_image().
Can we delay mapping of this page in Xen until the ring buffer is
actually requir
On Fri, Jun 16, 2017 at 06:56:44PM +0100, Anthony PERARD wrote:
> Changes in V11:
> - plenty of new patches, on top of the original 3 patches that were acked.
> - and an attempt at creating a flight for a stable branch of openstack. But
> there is many git tree to pull the branch from.
And here
On 19/06/17 11:59, Bhupinder Thakur wrote:
Hi Julien,
I was mistaken in my earlier mail about vpl011 init working if it is
moved to libxl__arch_domain_create(). It is failing because as you
have mentioned vuart_pfn is allocated later in xc_dom_build_image().
Can we delay mapping of this page
On Fri, Jun 16, 2017 at 05:36:18PM +0800, Zhongze Liu wrote:
> Hi Jan,
>
>
> 2017-06-16 16:45 GMT+08:00 Jan Beulich :
> On 16.06.17 at 06:55, wrote:
> >> currently there is no wrapper for XENMEM_add_to_physmap_batch in libxc.
> >> add a wrapper to do that.
> >
> > It may help acceptance if
On 15/06/17 12:05, Sergej Proskurin wrote:
The function p2m_mem_access_check_and_get_page in mem_access.c
translates a gva to an ipa by means of the hardware functionality of the
ARM architecture. This is implemented in the function gva_to_ipa. If
mem_access is active, hardware-based gva to ipa
Hello,
Thanks a lot for the detailed explanation. I could understand the working
of operf and opreport.
Unlike operf, ocount counts each occurrence of the monitored event. In such
a case, why ocount also gives varying values of CPU_CLK_UNHALTED even when
the monitored code doesn't get changed. Is
On Mon, Jun 19, 2017 at 11:55:14AM +0100, Ian Jackson wrote:
> osstest service owner writes ("[linux-4.9 test] 110513: regressions - FAIL"):
> > flight 110513 linux-4.9 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/110513/
> >
> > Regressions :-(
> >
> > Tests which did not suc
On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote:
> To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7.
>
> The only patch we have applies cleanly.
>
> Reported-by: Zhongze Liu
> Signed-off-by: Wei Liu
Ping?
___
Xen-devel mailin
On Wed, Jun 14, 2017 at 09:11:48AM +0800, Zhongze Liu wrote:
> GCC 7.1.1 complains that several buffers passed to snprintf() in xenpmd
> and tools/ocmal/xc are too small to hold the largest possible resulting
> string,
> which is calculated by adding up the maximum length of all the substrings.
>
On Mon, Jun 19, 2017 at 12:01:32PM +0100, Julien Grall wrote:
>
>
> On 19/06/17 11:59, Bhupinder Thakur wrote:
> > Hi Julien,
> >
> > I was mistaken in my earlier mail about vpl011 init working if it is
> > moved to libxl__arch_domain_create(). It is failing because as you
> > have mentioned vua
Add test for write_ctrlreg event handling.
Signed-off-by: Petre Pircalabu
---
tools/tests/xen-access/xen-access.c | 53 -
1 file changed, 52 insertions(+), 1 deletion(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
i
Add support for filtering out the write_ctrlreg monitor events if they
are generated only by changing certains bits.
A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg
function in order to mask the event generation if the changed bits are
set.
Signed-off-by: Petre Pircalabu
Acked
This patchset enables masking the reception of write_ctrlreg events depending
on the value of certain bits in that register.
The most representative example is filtering out events when the CR4.PGE
bit is being flipped (global TLB flushes)
---
Changed since v2
* fix coding style
* use ARRAY_S
Hi Sergej,
On 15/06/17 12:05, Sergej Proskurin wrote:
This commit adds functionality to walk the guest's page tables using the
long-descriptor translation table format for both ARMv7 and ARMv8.
Similar to the hardware architecture, the implementation supports
different page granularities (4K, 16
Hello Julien,
thank you for your answer and sorry for the delay.
2017-06-14 14:26 GMT+02:00 Julien Grall :
>
>
> On 06/12/2017 10:34 AM, Florian Jakobsmeier wrote:
>
>> Dear all,
>>
>
> Hello Florian,
>
>
> I don't have much experience with the debug registers, I have CCed some
> folks who may
Julien Grall writes ("Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide
way to ship livepatch tests"):
> I don't see the patches in staging. Do you still plan to have those
> patches in Xen 4.9?
As you'll have seen, they went to staging last week and are now in
xen.git#master. I have just
Wei Liu writes ("Re: [PATCH] ipxe: update to newer commit"):
> On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote:
> > To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7.
> >
> > The only patch we have applies cleanly.
> >
> > Reported-by: Zhongze Liu
> > Signed-off-by: Wei Li
Julien Grall writes ("Re: [Xen-devel] [linux-4.9 test] 110371: regressions -
FAIL"):
> There are now in Linux 4.9 stable branch. Now the testing is blocked
> because of again local migration [1]. The migration test seem less
> reliable than the Arndale these days... is there anything we can do?
On 19/06/17 13:59, Ian Jackson wrote:
> Julien Grall writes ("Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide
> way to ship livepatch tests"):
>> I don't see the patches in staging. Do you still plan to have those
>> patches in Xen 4.9?
> As you'll have seen, they went to staging last week
Hi Wei,
On 19 June 2017 at 17:17, Wei Liu wrote:
> On Mon, Jun 19, 2017 at 12:01:32PM +0100, Julien Grall wrote:
>>
>>
>> On 19/06/17 11:59, Bhupinder Thakur wrote:
>> > Hi Julien,
>> >
>> > I was mistaken in my earlier mail about vpl011 init working if it is
>> > moved to libxl__arch_domain_crea
On Mon, Jun 19, 2017 at 12:27:33PM +0100, Roger Pau Monné wrote:
> On Mon, Jun 19, 2017 at 11:55:14AM +0100, Ian Jackson wrote:
> > osstest service owner writes ("[linux-4.9 test] 110513: regressions -
> > FAIL"):
> > > flight 110513 linux-4.9 real [real]
> > > http://logs.test-lab.xenproject.org/
Thanks Jianfeng for giving new ideas.
There is not much activity on Xen side.
Is there someone working on DPDK+Xen? Any news?
The technical board requested to re-consider Xen support in DPDK.
It will be discussed in the next techboard meeting:
https://annuel.framapad.org/p/r.0c3cc4d1e0112
>>> On 17.06.17 at 11:32, wrote:
> The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls
> take a pointer to an RB node or RB root. They do not change the
> pointed objects, so add a 'const' qualifier in order to make life
> of the users of these functions easier.
>
> Indeed, if I have
branch xen-unstable
xenbranch xen-unstable
job build-i386-pvops
testid kernel-build
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
*** Found and reproduced problem changeset ***
Bug is in tre
Hi Jan,
On Mon, Jun 19, 2017 at 7:19 PM, Jan Beulich wrote:
On 17.06.17 at 11:32, wrote:
>> The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls
>> take a pointer to an RB node or RB root. They do not change the
>> pointed objects, so add a 'const' qualifier in order to make lif
In "xen/test/livepatch: Regularise Makefiles" we reworked
xen/test/Makefile to use a pattern rule. However, there are two
problems with this. Both are related to the way that xen/Rules.mk is
implicitly part of this Makefile because of the way that Makefiles
under xen/ are invoked by their parent
flight 110556 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 5 xen-build fail in 110510 REGR. vs. 110465
Tests which are fa
flight 110567 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110567/
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
Konrad Rzeszutek Wilk writes ("Re: blkback shutdown problem ? (Re: [linux-4.9
test] 110513: regressions - FAIL)"):
> On Mon, Jun 19, 2017 at 12:27:33PM +0100, Roger Pau Monné wrote:
> > This has already been noticed and fixed by Juergen [0], however AFAIK
> > the patches are not yet in Jens/Linus
osstest service owner writes ("[linux-linus bisection] complete
build-i386-pvops"):
> branch xen-unstable
> xenbranch xen-unstable
> job build-i386-pvops
> testid kernel-build
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tree: linuxfirmware git://xenbi
On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall wrote:
> Hi,
>
>
> On 19/06/17 09:15, Jan Beulich wrote:
>
> On 18.06.17 at 21:19, wrote:
>>>
>>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
>>> wrote:
On 04/04/17 14:14, Jan Beulich wrote:
>
> We shouldn't hand MFN info
>>> On 19.06.17 at 16:09, wrote:
> On Mon, Jun 19, 2017 at 7:19 PM, Jan Beulich wrote:
> On 17.06.17 at 11:32, wrote:
>>> The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls
>>> take a pointer to an RB node or RB root. They do not change the
>>> pointed objects, so add a 'const'
On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap wrote:
> On 19/06/17 09:15, Jan Beulich wrote:
> On 18.06.17 at 21:19, wrote:
>>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
>>> wrote:
On 04/04/17 14:14, Jan Beulich wrote:
> We shouldn't hand MFN info back from increase-reservation
On Mon, Jun 19, 2017 at 6:24 AM, Petre Pircalabu
wrote:
> Add test for write_ctrlreg event handling.
>
> Signed-off-by: Petre Pircalabu
Acked-by: Tamas K Lengyel
> ---
> tools/tests/xen-access/xen-access.c | 53
> -
> 1 file changed, 52 insertions(+), 1 de
On 19/06/17 15:39, Tamas K Lengyel wrote:
On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall wrote:
Hi,
On 19/06/17 09:15, Jan Beulich wrote:
On 18.06.17 at 21:19, wrote:
On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
wrote:
On 04/04/17 14:14, Jan Beulich wrote:
We shouldn't hand MFN in
On Mon, Jun 19, 2017 at 03:27:01PM +0100, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: blkback shutdown problem ? (Re: [linux-4.9
> test] 110513: regressions - FAIL)"):
> > On Mon, Jun 19, 2017 at 12:27:33PM +0100, Roger Pau Monné wrote:
> > > This has already been noticed and fixed by
On 19/06/17 15:48, Tamas K Lengyel wrote:
> On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap
> wrote:
>> On 19/06/17 09:15, Jan Beulich wrote:
>> On 18.06.17 at 21:19, wrote:
On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
wrote:
> On 04/04/17 14:14, Jan Beulich wrote:
>> We s
On Mon, Jun 19, 2017 at 03:23:26PM +0100, Ian Jackson wrote:
> In "xen/test/livepatch: Regularise Makefiles" we reworked
> xen/test/Makefile to use a pattern rule. However, there are two
> problems with this. Both are related to the way that xen/Rules.mk is
> implicitly part of this Makefile beca
On Mon, Jun 19, 2017 at 8:54 AM, George Dunlap wrote:
> On 19/06/17 15:48, Tamas K Lengyel wrote:
>> On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap
>> wrote:
>>> On 19/06/17 09:15, Jan Beulich wrote:
>>> On 18.06.17 at 21:19, wrote:
> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
>
On Mon, Jun 19, 2017 at 8:52 AM, Julien Grall wrote:
>
>
> On 19/06/17 15:39, Tamas K Lengyel wrote:
>>
>> On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 19/06/17 09:15, Jan Beulich wrote:
>>>
>>>
>>> On 18.06.17 at 21:19, wrote:
>
>
>
On Mon, Jun 19, 2017 at 03:36:47PM +0100, Ian Jackson wrote:
> osstest service owner writes ("[linux-linus bisection] complete
> build-i386-pvops"):
> > branch xen-unstable
> > xenbranch xen-unstable
> > job build-i386-pvops
> > testid kernel-build
> >
> > Tree: linux
> > git://git.kernel.org/pu
On 16/06/17 19:10, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu
> driver already implements a proper ->mapping_error method, so it's only
> using the value internally. Add a new local define using the value
> that arm64 which is the only curre
flight 110557 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110557/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
110456
Tests which ar
On 19/06/17 15:57, Tamas K Lengyel wrote:
On Mon, Jun 19, 2017 at 8:52 AM, Julien Grall wrote:
On 19/06/17 15:39, Tamas K Lengyel wrote:
On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall
wrote:
Hi,
On 19/06/17 09:15, Jan Beulich wrote:
On 18.06.17 at 21:19, wrote:
On Tue, Apr 4, 2
Hi Julien,
[...]
On 06/19/2017 02:45 PM, Julien Grall wrote:
> Hi Sergej,
>
>> +/* Normalized page granule size indices. */
>> +#define GRANULE_SIZE_INDEX_4K (0)
>> +#define GRANULE_SIZE_INDEX_16K (1)
>> +#define GRANULE_SIZE_INDEX_64K (2)
>
> Why this is e
On 19/06/17 16:43, Sergej Proskurin wrote:
Hi Julien,
[...]
On 06/19/2017 02:45 PM, Julien Grall wrote:
Hi Sergej,
+/* Normalized page granule size indices. */
+#define GRANULE_SIZE_INDEX_4K (0)
+#define GRANULE_SIZE_INDEX_16K (1)
+#define GRANULE_SIZE_INDEX_64K
On Mon, Jun 19, 2017 at 9:34 AM, Julien Grall wrote:
>
>
> On 19/06/17 15:57, Tamas K Lengyel wrote:
>>
>> On Mon, Jun 19, 2017 at 8:52 AM, Julien Grall
>> wrote:
>>>
>>>
>>>
>>> On 19/06/17 15:39, Tamas K Lengyel wrote:
On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall
wrote:
>>
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls
> take a pointer to an RB node or RB root. They do not change the
> pointed objects, so add a 'const' qualifier in order to make life
> of the users of these functions easier.
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> Tfour 4 redundant if-conditions in function __rb_erase_color() in
> lib/rbtree.c are removed.
>
> In pseudo-source-code, the structure of the code is as follows:
>
> if ((!A || B) && (!C || D)) {
> .
> .
> .
> } else {
> if (
On Wed, Jun 07, 2017 at 07:17:16AM -0600, Jan Beulich wrote:
> >>> 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);
> >
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> First, move some code around in order to make the next change more
> obvious.
>
> [a...@linux-foundation.org: coding-style fixes]
> Signed-off-by: Peter Zijlstra
> Signed-off-by: Wolfram Strepp
> Signed-off-by: Andrew Morton
> Signed-off
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> There are two cases when a node, having 2 childs, is erased:
> 'normal case': the successor is not the right-hand-child of the node
> to be
> erased
> 'special case': the successor is the right-hand child of the node to
> be erased
>
> Here
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> Furthermore, notice that the initial checks:
>
> if (!node->rb_left)
> child = node->rb_right;
> else if (!node->rb_right)
> child = node->rb_left;
> else
>
Hi Andre,
On 19 June 2017 at 15:03, Andre Przywara wrote:
> Hi Bhupinder,
>
> I think the commit message is a bit misleading.
> Actually you *rename* functions and their call sites, and also this
> touches the VGIC code, so shouldn't it mention both in the first line of
> the commit message? Afte
The helpers p2m_valid, p2m_table, p2m_mapping and p2m_is_superpage are
not specific to the stage-2 translation tables. They can also work on
any LPAE translation tables. So rename then to lpae_* and use pte.walk
to look for the value of the field.
Signed-off-by: Julien Grall
---
Cc: prosku...@se
The file xen/arch/arm/p2m.c is using typesafe MFN in most of the place.
This requires caller to mfn_to_page and page_to_mfn to use _mfn/mfn_x.
To avoid extra _mfn/mfn_x, re-define mfn_to_page and page_to_mfn within
xen/arch/arm/p2m.c to handle typesafe MFN.
Signed-off-by: Julien Grall
---
Th
xenheap_mfn_end is storing an MFN and not a physical address. Xen is not
currently using xenheap_mfn_end and the value will be reset after the
loop. So drop this bogus xenheap_mfn_end.
Signed-off-by: Julien Grall
---
Changes in v2:
- Update commit message
---
xen/arch/arm/setup.c | 2
Also adding one missing full stop + fix description
Signed-off-by: Julien Grall
---
Cc: prosku...@sec.in.tum.de
I haven't retained Stefano's reviewed-by because of the description
update.
Changes in v2:
- Fix description regarding x86 page-table
---
xen/include/asm-arm/lpae
page.h is getting bigger. Move out every LPAE definitions in a separate
header. There is no functional changes.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: prosku...@sec.in.tum.de
Changes in v2:
- Move comment after the #endif rather than before
- A
The file xen/arch/arm/alternative.c is using typesafe MFN in most of
the place. The only caller to virt_to_mfn is using with _mfn(...).
To avoid extra _mfn(...), re-define virt_to_mfn within
xen/arch/arm/alternative.c to handle typesafe MFN.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabe
The file xen/arch/arm/mm.c is using the typesafe MFN in most of the
place. This requires all caller of virt_to_mfn to prefixed by _mfn(...).
To avoid the extra _mfn(...), re-defined virt_to_mfn within arch/arm/mm.c
to handle typesafe MFN.
This patch also introduce __virt_to_mfn, so virt_to_mfn ca
This is improving the code readability and avoid to dereference the
table every single time we need to access the entry.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/mm.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
Hi all,
This is a merged of the remainder of 2 series + new clean-up patches:
- xen/arm: Extend the usage of typesafe MFN [1]
- xen/arm: Move LPAE definition in a separate header. [2]
Cheers,
[1] <20170613161323.25196-1-julien.gr...@arm.com>
[2] <20170615203057.755-1-julien.gr...@arm.com
The file xen/arch/arm/livepatch.c is using typesafe MFN in most of
the place. The only caller to virt_to_mfn is using with _mfn(...).
To avoid extra _mfn(...), re-define virt_to_mfn within
xen/arch/arm/livepatch.c to handle typesafe MFN.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellin
lpae_* helpers can work on any LPAE translation tables. Move them in
lpae.h to allow other part of Xen to use them.
Signed-off-by: Julien Grall
---
Cc: prosku...@sec.in.tum.de
Changes in v2:
- Patch added
---
xen/arch/arm/p2m.c | 23 ---
xen/include/asm-
Add more safety when using xenheap_mfn_*.
Signed-off-by: Julien Grall
---
I haven't introduced mfn_less_than() and mfn_greather_than() as
there would be only a couple of usage. We would be able to introduce
them and replace the open-coding easily in the future grepping
mfn_x().
-
This newly introduced lpae_valid and lpae_table helpers will recude the
code and make more readable.
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/mm.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xe
flight 110560 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/110560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 5 kernel-build fail REGR. vs. 110515
test-amd64-amd64-xl
INVALID_{G,M}FN are defined using static inline helpers _{g,m}fn.
This means, they cannot be used to initialize a build time static variable:
In file included from mm.c:24:0:
xen/xen/include/xen/mm.h:59:26: error: initializer element is not constant
#define INVALID_MFN _mfn(~0UL)
Signed-off
The file xen/arch/arm/domain_build.c is using typesafe MFN in most of
the place. The only caller to virt_to_mfn is using prefixed with
_mfn(...).
To avoid extra _mfn(...), re-define virt_to_mfn within
arch/arm/domain_build.c to handle typesafe MFN.
Signed-off-by: Julien Grall
Reviewed-by: Stefan
Signed-off-by: Julien Grall
---
Changes in v2:
- Patch added
---
xen/arch/arm/mm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 657fee0b17..91af4c8743 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/m
Add a bit more safety when using create_xen_entries.
Also when destroying/modifying mapping, the MFN is currently not used.
Rather than passing _mfn(0) use INVALID_MFN to stay consistent with the
other usage.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Changes in v2:
> The method I found to work is getting the maximum_gpfn from the guest
> and then calling populate_physmap with ++max_gpfn. The only problem
> then is that I don't see a way to "unpopulate" the page from the
> domain and free the corresponding mfn while the domain is running. Is
> that currently p
Hi,
On 19/06/17 17:53, Bhupinder Thakur wrote:
> Hi Andre,
>
> On 19 June 2017 at 15:03, Andre Przywara wrote:
>> Hi Bhupinder,
>>
>> I think the commit message is a bit misleading.
>> Actually you *rename* functions and their call sites, and also this
>> touches the VGIC code, so shouldn't it m
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> Empty nodes have no color. We can make use of this property to
> simplify
> the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE
> macros. Also,
> we can get rid of the rb_init_node function which had been introduced
> by
> commit 88d19
On Wed, Jun 07, 2017 at 07:20:38AM -0600, Jan Beulich wrote:
> >>> 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_g
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> --- a/xen/include/xen/rbtree.h
> +++ b/xen/include/xen/rbtree.h
> @@ -21,9 +21,7 @@
>
> struct rb_node
> {
>
The Linux commit converts this into:
struct rb_node {
and..
> -unsigned long rb_parent_color;
> -#define RB_RED 0
> -#d
On Mon, Jun 19, 2017 at 05:57:45PM +0100, Julien Grall wrote:
> The file xen/arch/arm/livepatch.c is using typesafe MFN in most of
> the place. The only caller to virt_to_mfn is using with _mfn(...).
>
> To avoid extra _mfn(...), re-define virt_to_mfn within
> xen/arch/arm/livepatch.c to handle ty
On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote:
> It is a well known property of rbtrees that insertion never requires
> more
> than two tree rotations. In our implementation, after one loop
> iteration
> identified one or two necessary tree rotations, we would iterate and
> look
> for mor
1 - 100 of 122 matches
Mail list logo
