On Tue, Nov 17, 2015 at 04:49:03AM -0700, Jan Beulich wrote:
> >>> On 13.11.15 at 02:54, wrote:
> > @@ -91,7 +251,15 @@ void xsave(struct vcpu *v, uint64_t mask)
> > typeof(ptr->fpu_sse.fip.sel) fcs = ptr->fpu_sse.fip.sel;
> > typeof(ptr->fpu_sse.fdp.sel) fds = ptr->fpu_sse.fdp.s
On 2015/11/17 19:52, Julien Grall wrote:
> Hi Shannon,
>
> On 17/11/15 09:39, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> This patch set adds ACPI support for arm64 on Xen. The design document
>> could be found from [1].
>
> Thank you for your work on it. I think this series would
On Wednesday 18 November 2015 15:01:26 Shannon Zhao wrote:
> Hi Arnd,
>
> On 2015/11/17 17:50, Arnd Bergmann wrote:
> > On Tuesday 17 November 2015 17:40:03 shannon.z...@linaro.org wrote:
> >> +/*
> >> + * Emulate x86 io ports for arm.
> >> + */
> >> +#define __armio(addr) ( (void __iomem *)addr )
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Jan Beulich
> Sent: Tuesday, November 17, 2015 6:26 PM
> To: Andrew Cooper
> Cc: Tian, Kevin ; wei.l...@citrix.com;
> ian.campb...@citrix.com; stefano.stabell...@eu.citri
Why does libxl now allow script= with backend=tap|qdisk? See
tools/libxl/libxl_device.c:disk_try_backend.
Ideally the script should prepare the backend storage based on info from
target=. Then the script should report either the dentry to be used by
qemu back to libxl, or it should setup the "phys
On Wed, Nov 18, 2015 at 9:25 AM, Olaf Hering wrote:
> Why does libxl now allow script= with backend=tap|qdisk? See
> tools/libxl/libxl_device.c:disk_try_backend.
>
> Ideally the script should prepare the backend storage based on info from
> target=. Then the script should report either the dentry
On Wed, Nov 18, 2015 at 9:35 AM, George Dunlap
wrote:
> On Wed, Nov 18, 2015 at 9:25 AM, Olaf Hering wrote:
>> Why does libxl now allow script= with backend=tap|qdisk? See
>> tools/libxl/libxl_device.c:disk_try_backend.
>>
>> Ideally the script should prepare the backend storage based on info fro
On Tue, Nov 17, Chun Yan Liu wrote:
> I think libxl_device_usb doesn't need to be changed into libxl_device_usbdev?
In case of vscsi the struct and functions names are odd. It was not
obvious which one belongs to a ctrl and which one belongs to a device.
In the meantime I have changed everything
On Wed, Nov 18, George Dunlap wrote:
> You mean, should the bug wherein HVM domains with emulated disks
> (which is all of them, by default) cannot use block scripts be fixed?
Yes.
> Yes it should, and I'm working on it at the moment.
Great. Please cc me when the patches are ready.
Olaf
_
On Tue, Nov 17, 2015 at 12:50:29PM -0700, Linda wrote:
>
>
> On 11/17/2015 11:35 AM, Neil Sikka wrote:
> >How does Linda's work relate to Wei's patches available here (I didnt see
> >them in Xen-4.6.0):
> >
> >http://downloads.xen.org/Wiki/VirtioOnXen/qemu-01-xenpv-exec.patch
> >http://downloads.
On Tue, Nov 17, 2015 at 06:44:39PM +, Roger Pau Monne wrote:
> This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:
>
> Xen always set the FPU as initialized when loading a HVM context, so libxc
> has to provide a valid FPU context when setting the CPU registers.
>
> This is a stop-g
On Wed, 2015-11-18 at 10:44 +0100, Olaf Hering wrote:
> On Tue, Nov 17, Chun Yan Liu wrote:
>
> > I think libxl_device_usb doesn't need to be changed into
> > libxl_device_usbdev?
>
> In case of vscsi the struct and functions names are odd. It was not
> obvious which one belongs to a ctrl and wh
On 18/11/15 07:45, Jan Beulich wrote:
On 17.11.15 at 18:53, wrote:
>> On 17/11/15 17:39, Jan Beulich wrote:
>> On 17.11.15 at 18:30, wrote:
On 17/11/15 17:04, Jan Beulich wrote:
On 03.11.15 at 18:58, wrote:
>> --- a/xen/common/grant_table.c
>> +++ b/xen/common/gran
On 18/11/15 09:12, Wu, Feng wrote:
>
>> -Original Message-
>> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
>> boun...@lists.xen.org] On Behalf Of Jan Beulich
>> Sent: Tuesday, November 17, 2015 6:26 PM
>> To: Andrew Cooper
>> Cc: Tian, Kevin ; wei.l...@citrix.com;
>> ian.campb.
On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote:
> On 17/11/15 17:39, Jan Beulich wrote:
> > > > > On 17.11.15 at 18:30, wrote:
> > > On 17/11/15 17:04, Jan Beulich wrote:
> > > > > > > On 03.11.15 at 18:58, wrote:
> > > > > --- a/xen/common/grant_table.c
> > > > > +++ b/xen/common/grant_t
On 18/11/15 04:32, Shannon Zhao wrote:
> On 2015/11/18 0:02, David Vrabel wrote:
>> On 17/11/15 09:57, shannon.z...@linaro.org wrote:
>>> From: Shannon Zhao
>>>
>>> Move xlated_setup_gnttab_pages to common place, so it can be reused by
>>> ARM to setup grant table when booting with ACPI.
>> [...]
>>> On 18.11.15 at 09:09, wrote:
> On Tue, Nov 17, 2015 at 04:49:03AM -0700, Jan Beulich wrote:
>> >>> On 13.11.15 at 02:54, wrote:
>> > @@ -91,7 +251,15 @@ void xsave(struct vcpu *v, uint64_t mask)
>> > typeof(ptr->fpu_sse.fip.sel) fcs = ptr->fpu_sse.fip.sel;
>> > typeof(ptr->f
On Wed, Nov 18, Ian Campbell wrote:
> I'd been hoping that someone involved ion this would generate a patch
> adding a template for this controller+devices model to libxl.h, I've not
> seen anything since George's original RFC[0] "libxl: Introduce a template
> for devices with a controller".
Its
>>> On 18.11.15 at 11:06, wrote:
> On 18/11/15 07:45, Jan Beulich wrote:
> On 17.11.15 at 18:53, wrote:
>>> On 17/11/15 17:39, Jan Beulich wrote:
>>> On 17.11.15 at 18:30, wrote:
> On 17/11/15 17:04, Jan Beulich wrote:
> On 03.11.15 at 18:58, wrote:
>>> --- a/xen/common/
El 17/11/15 a les 19.02, Andrew Cooper ha escrit:
> On 17/11/15 18:44, Roger Pau Monne wrote:
>> Introduce a new filed to signal if the FPU has been initialised or not. Xen
>
> field
>
>> needs this new filed in order to know whether to set the FPU as initialised
>> or not during restore of CPU c
>>> On 18.11.15 at 11:36, wrote:
> On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote:
>> On 17/11/15 17:39, Jan Beulich wrote:
>> > > > > On 17.11.15 at 18:30, wrote:
>> > > On 17/11/15 17:04, Jan Beulich wrote:
>> > > > > > > On 03.11.15 at 18:58, wrote:
>> > > > > --- a/xen/common/grant_t
On 18/11/15 10:51, Roger Pau Monné wrote:
> El 17/11/15 a les 19.02, Andrew Cooper ha escrit:
>> On 17/11/15 18:44, Roger Pau Monne wrote:
>>> Introduce a new filed to signal if the FPU has been initialised or not. Xen
>> field
>>
>>> needs this new filed in order to know whether to set the FPU as
>>> On 18.11.15 at 12:00, wrote:
> As for the problem at hand, I don't see what was wrong with v1.
>
> Fundamentally, we have three different variations of the same structure;
> two of which require special compat handling. Pretending otherwise is
> just silly.
And if we gain a few more additio
Long time ago, I did a libxl patch for add basic spice support for pv domUs.
I did some improvements based on comments I received, if I remember good
I did all except add of vfb parameters (vfb=['spice=1,...'])
Major of advanced spice features can't be added in pv (also now based on
what I know)
Boris Ostrovsky writes:
> After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
> allocating descs for legacy IRQs") early_irq_init() will no longer
> preallocate descriptors for legacy interrupts if PIT does not
> exist.
PIC?
>
> Therefore we need to allocate those descriptors for
On 18/11/15 10:54, Jan Beulich wrote:
On 18.11.15 at 11:36, wrote:
>> On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote:
>>> On 17/11/15 17:39, Jan Beulich wrote:
>>> On 17.11.15 at 18:30, wrote:
> On 17/11/15 17:04, Jan Beulich wrote:
> On 03.11.15 at 18:58, wrote:
>>>
On 18/11/15 11:04, Jan Beulich wrote:
On 18.11.15 at 12:00, wrote:
>> As for the problem at hand, I don't see what was wrong with v1.
>>
>> Fundamentally, we have three different variations of the same structure;
>> two of which require special compat handling. Pretending otherwise is
>> jus
>>> On 18.11.15 at 12:23, wrote:
> On 18/11/15 10:54, Jan Beulich wrote:
>> That's not how I understood it, the rwlock isn't per-pCPU (at least not
>> in what this patch does - it remains a per-domain one). The per-pCPU
>> object is a pointer to an rwlock, which gets made point to whatever
>> doma
Hi Shannon,
On 18/11/15 02:28, Shannon Zhao wrote:
> On 2015/11/17 21:57, Julien Grall wrote:
>> On 17/11/15 12:32, Shannon Zhao wrote:
Hi Julien,
On 2015/11/17 19:27, Julien Grall wrote:
>> Hi Shannon,
>>
>> Why do you want to revert this patch?
>>
Because d->
flight 64484 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 59254
test-amd64-i386-xl-qe
On 18/11/15 02:37, Shannon Zhao wrote:
>
>
> On 2015/11/17 22:25, Julien Grall wrote:
>> On 17/11/15 13:21, Shannon Zhao wrote:
AFAICT, it does only works for SPCR table used for UART device. For the
GIC you've hardcoded the value and I can't find any version number in
the table.
>
On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote:
> On 18/11/15 10:54, Jan Beulich wrote:
> > > > > On 18.11.15 at 11:36, wrote:
> > > On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote:
> > > > On 17/11/15 17:39, Jan Beulich wrote:
> > > > > > > > On 17.11.15 at 18:30, wrote:
> > >
On 18/11/15 11:41, Jan Beulich wrote:
On 18.11.15 at 12:23, wrote:
>> On 18/11/15 10:54, Jan Beulich wrote:
>>> That's not how I understood it, the rwlock isn't per-pCPU (at least not
>>> in what this patch does - it remains a per-domain one). The per-pCPU
>>> object is a pointer to an rwlock
On 18/11/15 11:50, Ian Campbell wrote:
> On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote:
>> On 18/11/15 10:54, Jan Beulich wrote:
>> On 18.11.15 at 11:36, wrote:
On Tue, 2015-11-17 at 17:53 +, Andrew Cooper wrote:
> On 17/11/15 17:39, Jan Beulich wrote:
> On 17.
On 18/11/15 03:01, Shannon Zhao wrote:
> "All above tables will be mapped to Dom0 non-RAM space. Since when
> booting through ACPI it doesn't need the grant table region(see below
> section 3), it could use this region to store the tables or use the same
> way to find one memory region to store the
On Tue, Nov 17, Paul Durrant wrote:
> This patch documents paths to allow a domain to advertise an interface
> name, MAC (unicast and multicast) and IP (version 4 and 6) address
> information.
How does the domU do that in practice?
With some variant of xenstore-write or with the PV vif driver?
La
Signed-off-by: Ian Campbell
---
Right now osstest has tested rel-1.9.0~1 (flight 64145
http://lists.xen.org/archives/html/xen-devel/2015-11/msg01380.html ).
However the final commit simply updates docs/Releases.md to cover
1.9.0 so I don't anticipate any problems.
---
Config.mk | 6 +++---
1 file
On Wed, Nov 18, 2015 at 12:01:33PM +, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
Acked-by: Wei Liu
> ---
> Right now osstest has tested rel-1.9.0~1 (flight 64145
> http://lists.xen.org/archives/html/xen-devel/2015-11/msg01380.html ).
> However the final commit simply updates docs/Rel
This run is configured for baseline tests only.
flight 38303 linux-3.4 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38303/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumpuserxen-i386 15
rumpuserxen-demo-xenst
> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 18 November 2015 12:00
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Keir (Xen.org); Ian Campbell; Tim
> (Xen.org); Ian Jackson; Jan Beulich
> Subject: Re: [Xen-devel] [PATCH v5 4/4] docs: Introduce xenstore
On 18/11/15 12:00, Olaf Hering wrote:
> On Tue, Nov 17, Paul Durrant wrote:
>
>> This patch documents paths to allow a domain to advertise an interface
>> name, MAC (unicast and multicast) and IP (version 4 and 6) address
>> information.
> How does the domU do that in practice?
> With some variant
On 18/11/15 03:34, Shannon Zhao wrote:
> On 2015/11/17 20:02, Julien Grall wrote:
>> I'm nearly sure I already said it, this code already exists in the tree.
>> Why do you need to implement a new version?
> Ok, it needs to move the functions to the public place, right? So they
> can be called from
On Wed, 2015-11-18 at 11:56 +, Malcolm Crossley wrote:
> On 18/11/15 11:50, Ian Campbell wrote:
> > On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote:
> > > On 18/11/15 10:54, Jan Beulich wrote:
> > > > > > > On 18.11.15 at 11:36, wrote:
> > > > > On Tue, 2015-11-17 at 17:53 +, And
On 17/11/15 09:40, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/domain_build.c | 2 ++
> xen/common/efi/boot.c | 64
> +
Why do you add the creation of A
On 17/11/15 09:40, shannon.z...@linaro.org wrote:
> +/**
> + * IRQ line type.
> + *
> + * ACPI_IRQ_TYPE_NONE- default, unspecified type
> + * ACPI_IRQ_TYPE_EDGE_RISING - rising edge triggered
> + * ACPI_IRQ_TYPE_EDGE_FALLING- falling edge triggered
> + * ACPI_IRQ_TYPE_EDGE_BOTH
On 18/11/15 08:03, Shannon Zhao wrote:
> On 2015/11/17 19:52, Julien Grall wrote:
>> Hi Shannon,
>>
>> On 17/11/15 09:39, shannon.z...@linaro.org wrote:
>>> From: Shannon Zhao
>>>
>>> This patch set adds ACPI support for arm64 on Xen. The design document
>>> could be found from [1].
>>
>> Thank yo
Hi Shannon,
On 17/11/15 09:57, shannon.z...@linaro.org wrote:
> diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
> index 62f591f..c084ba6 100644
> --- a/drivers/xen/grant-table.c
> +++ b/drivers/xen/grant-table.c
> @@ -664,6 +664,55 @@ int gnttab_setup_auto_xlat_frames(phys_addr_
On 18/11/15 06:03, Shannon Zhao wrote:
>>
>> What about the removal of a bus device? No need to handle that?
>>
> I have thought about removal before. I think there is little(or no)
> chance for AMBA and platform bus devices to be removed. It's not like
> the PCI devices which will be hot-unplug.
>
This run is configured for baseline tests only.
flight 38304 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38304/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf bd3afeb1d62c68d8144d39e82bb188b2af3ca60c
baseline version:
ovm
flight 38305 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38305/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38266
jobs:
build-amd64 pass
build-armhf
On 2015/11/18 19:41, Julien Grall wrote:
Hi Shannon,
On 18/11/15 02:28, Shannon Zhao wrote:
On 2015/11/17 21:57, Julien Grall wrote:
On 17/11/15 12:32, Shannon Zhao wrote:
Hi Julien,
On 2015/11/17 19:27, Julien Grall wrote:
Hi Shannon,
Why do you want to revert this patch?
Because d->
On 18/11/15 12:07, Ian Campbell wrote:
> On Wed, 2015-11-18 at 11:56 +, Malcolm Crossley wrote:
>> On 18/11/15 11:50, Ian Campbell wrote:
>>> On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote:
On 18/11/15 10:54, Jan Beulich wrote:
On 18.11.15 at 11:36, wrote:
>> On Tu
On 2015/11/18 20:27, Julien Grall wrote:
On 18/11/15 06:03, Shannon Zhao wrote:
What about the removal of a bus device? No need to handle that?
I have thought about removal before. I think there is little(or no)
chance for AMBA and platform bus devices to be removed. It's not like
the PCI d
On 18/11/15 13:09, Shannon Zhao wrote:
>> Note it's a mandatory to emulate the same version as the hardware for
>> the virtual GIC.
>>
> So it doesn't support vGICv2 on GICv3 hardware for Xen?
Sorry I forgot to say it was for DOM0. We support GICv2 on GICv3 only
for guest.
Regards,
--
Julien Gr
On 2015/11/18 20:25, Julien Grall wrote:
Hi Shannon,
On 17/11/15 09:57, shannon.z...@linaro.org wrote:
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 62f591f..c084ba6 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -664,6 +664,55 @@ int gntt
On 2015/11/18 21:33, Julien Grall wrote:
On 18/11/15 13:09, Shannon Zhao wrote:
Note it's a mandatory to emulate the same version as the hardware for
the virtual GIC.
So it doesn't support vGICv2 on GICv3 hardware for Xen?
Sorry I forgot to say it was for DOM0. We support GICv2 on GICv3 on
>>> On 18.11.15 at 14:08, wrote:
> On 18/11/15 12:07, Ian Campbell wrote:
>> (Maybe I should have said "like a bit lock with 32 or 64 bits, setting any
>> of which corresponds to acquiring the lock" ;-))
>>
> Not quite, setting the per cpu read area "takes" the read lock for the
> particular
> r
On 17/11/15 17:00, Jan Beulich wrote:
On 03.11.15 at 18:58, wrote:
>> Per-cpu read-write locks allow for the fast path read case to have low
>> overhead
>> by only setting/clearing a per-cpu variable for using the read lock.
>> The per-cpu read fast path also avoids locked compare swap opera
On 11/18/2015 06:16 AM, Vitaly Kuznetsov wrote:
Boris Ostrovsky writes:
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate descriptors for legacy interrupts if PIT does not
exist.
PIC?
Right. Davi
>>> On 18.11.15 at 14:49, wrote:
> On 17/11/15 17:00, Jan Beulich wrote:
> On 03.11.15 at 18:58, wrote:
>>> Per-cpu read-write locks allow for the fast path read case to have low
>>> overhead
>>> by only setting/clearing a per-cpu variable for using the read lock.
>>> The per-cpu read fast p
On Wed, 2015-11-18 at 13:08 +, Malcolm Crossley wrote:
> On 18/11/15 12:07, Ian Campbell wrote:
> > On Wed, 2015-11-18 at 11:56 +, Malcolm Crossley wrote:
> > > On 18/11/15 11:50, Ian Campbell wrote:
> > > > On Wed, 2015-11-18 at 11:23 +, Malcolm Crossley wrote:
> > > > > On 18/11/15 10
Boris Ostrovsky writes:
> On 11/18/2015 06:16 AM, Vitaly Kuznetsov wrote:
>> Boris Ostrovsky writes:
>>
>>> After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
>>> allocating descs for legacy IRQs") early_irq_init() will no longer
>>> preallocate descriptors for legacy interrupts
flight 64494 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64035
test-armhf-armhf-xl
When the planning queue becomes empty, we update the plan. We should
also update the projection.
I have cowboyed this change in the Cambridge instance's
daemons-testing.git and tested it there.
Signed-off-by: Ian Jackson
---
ms-queuedaemon |1 +
1 file changed, 1 insertion(+)
diff --git a
On Wed, 2015-11-18 at 14:40 +, Ian Jackson wrote:
> When the planning queue becomes empty, we update the plan. We should
> also update the projection.
>
> I have cowboyed this change in the Cambridge instance's
> daemons-testing.git and tested it there.
>
> Signed-off-by: Ian Jackson
Acked
Hi Juergen
Looks like there is something we missed after all.
On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
> flight 64494 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/64494/
>
> Regressions :-(
>
> Tests which did not succeed and are bloc
On 11/18/2015 09:28 AM, Vitaly Kuznetsov wrote:
Boris Ostrovsky writes:
On 11/18/2015 06:16 AM, Vitaly Kuznetsov wrote:
Boris Ostrovsky writes:
After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
allocating descs for legacy IRQs") early_irq_init() will no longer
preallocate
On Wed, Nov 18, 2015 at 12:13:06PM +0100, Fabio Fantoni wrote:
> Long time ago, I did a libxl patch for add basic spice support for pv domUs.
> I did some improvements based on comments I received, if I remember good I
> did all except add of vfb parameters (vfb=['spice=1,...'])
> Major of advanced
flight 64505 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-prev 5 xen-build fail REGR. vs. 63449
build-i386-prev
The page will be use later for reference counting. So we need a quick
access to the page associated to the mapping.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f910cab..f28ae3f 100644
-
Currently, the translation table is left in place even if no entries is
inuse. Because of how the p2m code has been implemented, replacing a
translation table by a block (i.e superpage) is not supported. Therefore,
any mapping of a superpage size will be split in smaller chunks making
the translati
Currently, the TLB is not flushed if an error occured while updating the
stage-2 p2m. However, the TLB will contain stall mappings for any entry
updated so far.
To avoid a such situation, flush on every exit paths when the variable
"flush" is set.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2
On 18/11/15 15:49, Wei Liu wrote:
> Hi Juergen
>
> Looks like there is something we missed after all.
>
> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
>> flight 64494 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/64494/
>>
>> Regressions :-
Hello,
The main purpose of this patch series is to allow creation of superpage when
it has been previously shattered.
The first patch is not related to the main purpose of this series but fix a
latent bug I've found while looking at the p2m code.
Sincerely yours,
Julien Grall (4):
xen/arm: p2
Factorize the code to remove an entry in p2m_remove_pte so we can re-use
it later.
Signed-off-by: Julien Grall
---
xen/arch/arm/p2m.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f28ae3f..ae0acf0 100644
--- a/xen/ar
On Wed, Nov 18, 2015 at 04:54:34PM +0100, Juergen Gross wrote:
> On 18/11/15 15:49, Wei Liu wrote:
> > Hi Juergen
> >
> > Looks like there is something we missed after all.
> >
> > On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
> >> flight 64494 xen-unstable real [real]
>
osstest service owner writes ("[xen-4.6-testing test] 64505: regressions -
FAIL"):
> flight 64505 xen-4.6-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/64505/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
On 18/11/15 16:59, Wei Liu wrote:
> On Wed, Nov 18, 2015 at 04:54:34PM +0100, Juergen Gross wrote:
>> On 18/11/15 15:49, Wei Liu wrote:
>>> Hi Juergen
>>>
>>> Looks like there is something we missed after all.
>>>
>>> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
fligh
Il 18/11/2015 16:16, Konrad Rzeszutek Wilk ha scritto:
On Wed, Nov 18, 2015 at 12:13:06PM +0100, Fabio Fantoni wrote:
Long time ago, I did a libxl patch for add basic spice support for pv domUs.
I did some improvements based on comments I received, if I remember good I
did all except add of vfb
On 11/12/2015 08:43 AM, Juergen Gross wrote:
In order to prepare a p2m list outside of the initial kernel mapping
do a rework of the domain builder's page table handler. The goal is
to be able to use common helpers for page table allocation and setup
for initial kernel page tables and page tables
Upstream qemu is now in qemu-xen.git and the trad fork is in
qemu-xen-traditional.git.
QEMU_UPSTREAM_REVISION is currently a tag and
QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are
required to those.
Signed-off-by: Ian Campbell
Acked-by: Ian Jackson
Conflicts:
Confi
On Wed, Nov 18, 2015 at 11:11:16AM -0500, Boris Ostrovsky wrote:
> On 11/12/2015 08:43 AM, Juergen Gross wrote:
> >In order to prepare a p2m list outside of the initial kernel mapping
> >do a rework of the domain builder's page table handler. The goal is
> >to be able to use common helpers for page
>>> On 18.11.15 at 17:06, wrote:
> Upstream qemu is now in qemu-xen.git and the trad fork is in
> qemu-xen-traditional.git.
>
> QEMU_UPSTREAM_REVISION is currently a tag and
> QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are
> required to those.
>
> Signed-off-by: Ian Campbell
Hi Andrew,
On 17/11/15 18:47, Andrew Cooper wrote:
> On 17/11/15 18:09, Julien Grall wrote:
>> On ARM, it's possible to fail when removing a page from the P2M. It's
>> happening if we are trying to shatter a superpage and we don't have
>> memory to allocate the table. Therefore the mapping won't b
On Wed, 2015-11-18 at 16:06 +, Ian Jackson wrote:
> Upstream qemu is now in qemu-xen.git and the trad fork is in
> qemu-xen-traditional.git.
>
> QEMU_UPSTREAM_REVISION is currently a tag and
> QEMU_TRADITIONAL_REVISION is a specific revision, so no changes are
> required to those.
>
> Signed-
On 18/11/15 14:15, Jan Beulich wrote:
On 18.11.15 at 14:49, wrote:
>> On 17/11/15 17:00, Jan Beulich wrote:
>> On 03.11.15 at 18:58, wrote:
Per-cpu read-write locks allow for the fast path read case to have low
overhead
by only setting/clearing a per-cpu variable for usin
On 11/18/2015 11:16 AM, Wei Liu wrote:
On Wed, Nov 18, 2015 at 11:11:16AM -0500, Boris Ostrovsky wrote:
On 11/12/2015 08:43 AM, Juergen Gross wrote:
In order to prepare a p2m list outside of the initial kernel mapping
do a rework of the domain builder's page table handler. The goal is
to be abl
On 16/11/15 13:23, Ian Campbell wrote:
> On Mon, 2015-11-09 at 15:49 +, Julien Grall wrote:
>> #define GICD_ITARGETSR (0x800)
>> +#define GICD_ITARGETSR7 (0x81C)
>> +#define GICD_ITARGETSR8 (0x820)
>
> As a future change, I wonder if making these take a parameter (N) and do
> the necessary a
Hello,
This patch series tries to properly solve the problem seen with the HVMlite
series, that Xen always assumes the FPU is initialised on CPU context
restore.
Roger.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Ian Campbell writes ("Re: [PATCH 4.6] Config: Switch to unified qemu trees."):
> This looks like what my local backport got when I was developing this,
> which I erroneously posted as the patch for unstable in [0] so:
>
> Acked-by: Ian Campbell
Great, thanks.
> Are you going to apply this to 4.
Introduce a new field to signal if the FPU has been initialised or not. Xen
needs this new field in order to know whether to set the FPU as initialised
or not during restore of CPU context. Previously Xen always wrongly assumed
the FPU was initialised on restore.
Signed-off-by: Roger Pau Monné
Cc
In order to cope with types having multiple compat versions pass a size
parameter to the fixup function so we can identify which compat version
Xen is dealing with.
Signed-off-by: Roger Pau Monné
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Tim Deegan
---
Changes since v2:
- Size is
With the current compat implementation in the save/restore context handling,
only one compat structure is allowed, and using _zeroextend prevents the
fixup function from being called.
In order to allow for the compat handling layer to be able to handle
different compat versions allow calling the f
This reverts commit d64dbbcc7c9934a46126c59d78536235908377ad:
Xen always set the FPU as initialized when loading a HVM context, so libxc
has to provide a valid FPU context when setting the CPU registers.
This was a stop-gap measure in order to unblock OSSTest Windows 7 failures
while a proper fix
Xen is currently directly storing the value of GICD_ITARGETSR register
(for GICv2) and GICD_IROUTER (for GICv3) in the rank. This makes the
emulation of the registers access very simple but makes the code to get
the target vCPU for a given vIRQ more complex.
While the target vCPU of an vIRQ is ret
The current implementation ignores the whole write if one of the field is
0. Although, based on the spec (4.3.12 IHI 0048B.b), 0 is a valid value
when:
- The interrupt is not wired in the distributor. From the Xen
point of view, it means that the corresponding bit is not set in
d->arch.
During a store, the byte is always in the low part of the register (i.e
[0:7]).
We are incorrectly masking the register by using a shift of the byte
offset in the ITARGETSR while the byte is alwasy in r[0:7]. This will
result in a target list equal to 0 which is ignored by the emulation.
Because
Based on 8.1.3 (IHI 0069A), unless stated otherwise, the 64-bit registers
supports both 32-bit and 64-bits access.
All the registers we properly emulate (i.e not RAZ/WI) supports 32-bit access.
For RAZ/WI, it's also seems to be the case but I'm not 100% sure. Anyway,
emulating 32-bit access for t
and use them in the vGIC emulation.
The GIC registers may support different access sizes. Rather than open
coding the access for every registers, provide a set of helpers to access
them.
The caller will have to call vgic_regN_* where N is the size of the
emulated registers.
The new helpers suppo
Each ITARGETSR register are 4-byte wide and the offset is in byte.
The current implementation is computing the end of the range wrongly
resulting to emulate only ITARGETSR{0,1} read-only. The rest will be
treated as read-write.
As 8 registers should be read-only, the end of the range should be
IT
1 - 100 of 173 matches
Mail list logo
