> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Wednesday, November 18, 2015 6:11 PM
> To: Wu, Feng ; Jan Beulich
> Cc: Tian, Kevin ; wei.l...@citrix.com;
> ian.campb...@citrix.com; stefano.stabell...@eu.citrix.com;
> george.dun...@eu.citrix.com; ian
>>> On 19.11.15 at 04:58, wrote:
> I will come back when I experience the reboot issue on Xen master.
> But I still think that Xen should reboot even when the other parts of
> Xen (not the reboot logic) has a bug. Maybe I'm wrong?
No, that's a perfectly valid expectation. Just that what you propo
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about how to s
>>> On 19.11.15 at 08:00, wrote:
> On Wed, Nov 18, 2015 at 03:40:50AM -0700, Jan Beulich wrote:
>> > For this save side. As cpu_has_xsaveopt should be handled indenpently.
>> > If we just use alternative asm for xsaves or xsavec, the following code
>> > handle xsaveopt/xsave should be like this:
>
On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski wrote:
> On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
> wrote:
>> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
>> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
>> frame that is passed to xe
On Wed, Nov 18, 2015 at 03:40:50AM -0700, Jan Beulich wrote:
> > For this save side. As cpu_has_xsaveopt should be handled indenpently.
> > If we just use alternative asm for xsaves or xsavec, the following code
> > handle xsaveopt/xsave should be like this:
> > if ( !cpu_has_xsavec && !cpu_has_xsa
>>> On 11/19/2015 at 09:33 AM, in message
<564d9761026600085...@relay2.provo.novell.com>, "Chun Yan Liu"
wrote:
>
On 11/18/2015 at 05:44 PM, in message <20151118094410.gb21...@aepfle.de>,
Olaf
> Hering wrote:
> > On Tue, Nov 17, Chun Yan Liu wrote:
> >
> > > I think l
On 18/11/15 17:21, Boris Ostrovsky wrote:
> 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 d
flight 64668 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64668/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 386cdfbecbbacb600ffc8e2ffa8c7af1b3855a61
baseline version:
ovmf bd3afeb1d62c68d8144d39e82bb188b2af3
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, November 19, 2015 2:12 AM
>
> [cc +qemu-devel, +paolo, +gerd]
>
> On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > Hi all,
> >
> > We are pleased to announce another update of Intel GVT-g for Xen.
> >
> > Intel G
2015-11-18 22:50 GMT-05:00 Tianyang Chen :
> In nested virtualization, choosing the smaller value for the
> time slice between the MAX_SCHEDULE and the budget will cause
> high host CPU usage.
Just add one comment:
I also experienced this issue when I develop Xen in a virtual box on
MacBook Air.
2015-11-13 2:39 GMT-05:00 Jan Beulich :
On 12.11.15 at 20:54, wrote:
>> However, the line after that if statement is:
>> smp_send_stop();
>>
>> which is not in the if ( get_apic_id() != boot_cpu_physical_apicid )
>> statement.
>>
>> So P0 may run this code, and from what I read from this
>> s
This run is configured for baseline tests only.
flight 38306 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38306/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 5 xen-build
In nested virtualization, choosing the smaller value for the
time slice between the MAX_SCHEDULE and the budget will cause
high host CPU usage.
Signed-off-by: Tianyang Chen
---
xen/common/sched_rt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/sched_rt.c b/xe
flight 64579 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64579/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail like 64290
Tests which did not succeed,
Hi
I am sending this due the change of behaviour in some parts, and perhaps
it needs some code amendments, unsure if the devel list is the best
place, fell free to point me to the right place for this. Let me know if
I should load a bug instead.
Per the documentation
http://wiki.xenproject.
>>> On 11/18/2015 at 05:44 PM, in message <20151118094410.gb21...@aepfle.de>,
>>> 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.
On 19/11/2015 00:31, Atom2 wrote:
> Am 19.11.15 um 00:17 schrieb Andrew Cooper:
>> On 18/11/2015 22:51, Atom2 wrote:
>>> Am 17.11.15 um 00:10 schrieb Atom2:
> [big snip]
>>> Hi Andrew,
>>> as promised I have again tried with a debug build and the results are
>>> very mixed. I initially tried to bet
flight 64584 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64584/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 64145
Tests which did not succeed, but a
Am 19.11.15 um 00:17 schrieb Andrew Cooper:
On 18/11/2015 22:51, Atom2 wrote:
Am 17.11.15 um 00:10 schrieb Atom2:
[big snip]
Hi Andrew,
as promised I have again tried with a debug build and the results are
very mixed. I initially tried to better understand what the debug USE
flag actually does
On 18/11/2015 22:51, Atom2 wrote:
> Am 17.11.15 um 00:10 schrieb Atom2:
>> Am 17.11.15 um 00:01 schrieb Andrew Cooper:
>>> On 16/11/2015 19:16, Atom2 wrote:
Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
Your analysis was absolutely spot on. After re-thinking this for a
Am 17.11.15 um 00:10 schrieb Atom2:
Am 17.11.15 um 00:01 schrieb Andrew Cooper:
On 16/11/2015 19:16, Atom2 wrote:
Am 16.11.15 um 16:31 schrieb Konrad Rzeszutek Wilk:
Your analysis was absolutely spot on. After re-thinking this for a
moment, I thought going down that route first would make a l
On November 17, 2015 6:15:38 PM EST, Jim Fehlig wrote:
>Joao Martins wrote:
>> Introduce support for domainMemoryStats API call, which
>> consequently enables the use of `virsh dommemstat` command to
>> query for memory statistics of a domain. We support
>> the following statistics: balloon info,
flight 64562 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64562/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 5 kernel-build fail REGR. vs. 62648
Tests which are failin
On 11/18/2015 03:58 PM, Andy Lutomirski wrote:
On Wed, Nov 18, 2015 at 12:50 PM, Brian Gerst wrote:
Can you just add !xen_pv_domain() to the opportunistic SYSRET check
instead? Bury the alternatives in that macro, ie.
static_cpu_has(X86_FEATURE_XENPV). That would likely benefit other
code as
On 11/13/2015 06:14 AM, Joao Martins wrote:
> Introduce support for connectGetAllDomainStats call that
> allow us to _all_ domain(s) statistics including network, block,
allows us to get
> cpus and memory. Changes are rather mechanical and mostly
> take care of the format to export the data.
>
>
On Wed, Nov 18, 2015 at 03:34:32PM -0500, Boris Ostrovsky wrote:
> On 11/18/2015 03:11 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote:
> >>Xen PV guests have been the only ones using it and now they don't.
> >Could you elaborate on the 'now they
On Wed, Nov 18, 2015 at 12:50 PM, Brian Gerst wrote:
> On Wed, Nov 18, 2015 at 3:21 PM, Andy Lutomirski wrote:
>> On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
>> wrote:
>>> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
>>> ("x86/entry/32: Re-implement SYSENTER usi
On 11/13/2015 06:14 AM, Joao Martins wrote:
> Introduce a new helper function "virDiskNameParse" which extends
> virDiskNameToIndex but handling both disk index and partition index.
> Also rework virDiskNameToIndex to be based on virDiskNameParse.
> A test is also added for this function testing bo
On Wed, Nov 18, 2015 at 12:21:56PM -0800, Andy Lutomirski wrote:
> > diff --git a/arch/x86/include/asm/cpufeature.h
> > b/arch/x86/include/asm/cpufeature.h
> > index e4f8010..0e4fe5b 100644
> > --- a/arch/x86/include/asm/cpufeature.h
> > +++ b/arch/x86/include/asm/cpufeature.h
> > @@ -216,6 +216,7
On 11/18/2015 11:05 AM, Joao Martins wrote:
>
> On 11/17/2015 11:15 PM, Jim Fehlig wrote:
>> Joao Martins wrote:
>>> Introduce support for domainMemoryStats API call, which
>>> consequently enables the use of `virsh dommemstat` command to
>>> query for memory statistics of a domain. We support
>>>
On 11/18/2015 03:11 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote:
Xen PV guests have been the only ones using it and now they don't.
Could you elaborate on the 'now they don't' please?
Is Xen not doing it? Did it do it in the past?
Is it bec
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
wrote:
> Xen PV guests have been the only ones using it and now they don't.
Yay!
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
wrote:
> Xen PV guests have been the only ones using it and now they don't.
Fantastic!
--Andy
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Nov 18, 2015 at 12:06 PM, Boris Ostrovsky
wrote:
> After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
> ("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
> frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
> it's not pt_regs
On Wed, Nov 18, 2015 at 03:06:18PM -0500, Boris Ostrovsky wrote:
> Xen PV guests have been the only ones using it and now they don't.
Could you elaborate on the 'now they don't' please?
Is Xen not doing it? Did it do it in the past?
Is it because the Linux code paths will never run to this in Xe
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
it's not pt_regs).
Since we end up calling xen_iret from xen_sysexit we don't nee
The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the
earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
(and sysret32 in compat mode) pv ops, as suggested by Andy. (I ended up patching
TEST with XOR to avoid extra NOPs, even though I said yester
Xen PV guests have been the only ones using it and now they don't.
Signed-off-by: Boris Ostrovsky
---
arch/x86/entry/entry_32.S | 8 ++--
arch/x86/include/asm/paravirt.h | 7 ---
arch/x86/include/asm/paravirt_types.h | 9 -
arch/x86/kernel/asm-offsets.c
Xen PV guests have been the only ones using it and now they don't.
Signed-off-by: Boris Ostrovsky
---
arch/x86/entry/entry_64_compat.S | 10 ++
arch/x86/include/asm/paravirt.h | 5 -
arch/x86/include/asm/paravirt_types.h | 8
arch/x86/kernel/asm-offsets_64.c
On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper 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_table.c
> >> @@ -178,6 +178,10 @@ struct active_grant_entry {
> >> #define _active_entry(t, e)
On 11/13/2015 06:14 AM, Joao Martins wrote:
> Introduce initial support for domainBlockStats API call that
> allow us to query block device statistics. openstack nova
> uses this API call to query block statistics, alongside
> virDomainMemoryStats and virDomainInterfaceStats. Note that
> this patc
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Bob Liu
Changes in v2:
- Add Royger's acked-by
---
dri
Hi all,
This is a follow-up on the previous discussion [1] related to guest using 64KB
page granularity which doesn't boot when the backend isn't using indirect
descriptor.
This has been successfully tested on ARM64 with both 64KB and 4KB page
granularity guests and QEMU as the backend. Indeed QE
The minimal size of request in the block framework is always PAGE_SIZE.
It means that when 64KB guest is support, the request will at least be
64KB.
Although, if the backend doesn't support indirect descriptor (such as QDISK
in QEMU), a ring request is only able to accommodate 11 segments of 4KB
(
Hello All,
I am currently working on the OpenXT project [1]. My work is currently
focused on creating a shim layer between XenMgr [2] (written in Haskell)
and LibXL. Goal is to replace the current XenOps/XenVM [3] (written in
OCaml).
I wanted to inquire about the current state of LibXL and in
On 11/18/2015 05:33 PM, Jim Fehlig wrote:
> On 11/16/2015 07:59 PM, Jim Fehlig wrote:
>> On 11/13/2015 06:14 AM, Joao Martins wrote:
>> @@ -5233,6 +5342,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
>> #endif
>> .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
>> .n
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
>
> Intel GVT-g is a full GPU virtualization solution with mediated
> pass-through, starting from 4th generation Intel Core(TM) proc
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 PIC does not
exist, which is the case for Xen PV guests.
Therefore we may need to allocate those descriptors oursel
On 11/17/2015 11:38 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>>
>> On 11/17/2015 02:48 AM, Jim Fehlig wrote:
>>> On 11/13/2015 06:14 AM, Joao Martins wrote:
Introduce support for domainInterfaceStats API call for querying
network interface statistics. Consequently it also enables the
On 11/17/2015 11:15 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> Introduce support for domainMemoryStats API call, which
>> consequently enables the use of `virsh dommemstat` command to
>> query for memory statistics of a domain. We support
>> the following statistics: balloon info, available a
flight 64510 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs.
60684
tes
Our vGIC emulation have GICD_TYPER.MBIS set to 0 which means that
GICD_*SPI_* registers are reserved. Implement them using the *_reserved
labels.
Also, implement theses registers for the read part.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's ac
A read to a write only register is unknown. Use a memorable value to
differentiate from an actual RAZ register.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
---
xen/arch/arm/vgic-v3.c | 20
1 file changed, 12 insert
Hi Konrad,
On 09/11/15 16:05, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 09, 2015 at 03:51:48PM +, Julien Grall wrote:
>> Hi,
>>
>> Any comments on this new version?
>
> I completly ignored thinking that the:
>
> c004a6f block/xen-blkfront: Make it running on 64KB page granularity
> 4f503fb
On 11/16/2015 07:59 PM, Jim Fehlig wrote:
> On 11/13/2015 06:14 AM, Joao Martins wrote:
> @@ -5233,6 +5342,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
> #endif
> .nodeGetFreeMemory = libxlNodeGetFreeMemory, /* 0.9.0 */
> .nodeGetCellsFreeMemory = libxlNodeGetCellsFreeMemory
The offset in the emulation is based on byte. As most of the registers
are 64/32 bits, they will span over multiple bytes.
However, the current emulation only cares about the first offset. This
will result in not properly emulating any access on the register with
any other offset.
Introduce new m
Each ITARGETSR register are 4-byte wide and the offset is in byte.
The current implementation is computing the offset of ICFGR1 and ICFG2
wonrgly result to emulate only the first 2 byte of the ICFGR range
read-only. The rest will be treated as read-write.
For convenience introduce ITARGETSR1 and
The 2 registers are not described in the software spec (ARM IHI 0069A)
and their offsets are marked "implementation defined".
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Note that I didn't combine the 2 cases because a follow-up patch
will add reserved registers between the 2
Hi all,
The main purpose of this patch series is to fix the access to any register when
the user doesn't write at the base offset of the registers.
At the same time, I took the opportunity to re-arrange the emulation and
dropping any registers which don't exist or not required by the spec.
This
Most of the identification registers space contains implementation
defined registers (see 8.1.13 in ARM IHI 0069A) and only GIC{D,R}_PIDR2
is required to be implemented.
Currently the emulation of those registers mimic the ARM implementation,
but it's untrue to say that we properly emulate a such
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
---
xen/arch/arm/vgic-v3.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 98104ba..c68afdb 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/x
The range of valid IROUTER are n = 32 - 1019 (see 8.9.13 in IHI 0069A)
which correspond to the offset 0x6100-0x7FD8.
Other offset are invalid and therefore should not be emulated.
Also remove the now unused label read_as_zero_64 and write_ignore_64.
Note that GICD_IROUTER is kept to accomadate t
It helps to find quickly whether we forgot to emulate a register or not.
At the same time add the missing reserved/implementation defined
registers. All other missing registers will be added in a follow-up if
necessary.
Note that only the distributor register map explicitely say the
size of a reg
The offset is 0x0D00 and not 0x0F80.
Also re-order the definition to keep all the definitions ordered.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
---
xen/include/asm-arm/gic_v3_defs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletio
The GICD_ICACTIVER registers are missing in the read emulation of the
distributor.
Call the common emulation for the whole range.
Signed-off-by: Julien Grall
Acked-by: Ian Campbell
---
Changes in v2:
- Add Ian's acked-by
---
xen/arch/arm/vgic-v3.c | 1 +
1 file changed, 1 insertio
On Wed, 2015-11-18 at 17:11 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH 4.6] Config: Switch to unified qemu
> trees."):
> > Are you going to apply this to 4.5 and older now too? Given the obvious
> > s/4.6/$X.$Y/g on this patch you may keep my ack on those too.
>
> Now done. Ther
flight 64520 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64520/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340
Tests which did not succe
Ian Campbell writes ("Re: [PATCH 4.6] Config: Switch to unified qemu trees."):
> Are you going to apply this to 4.5 and older now too? Given the obvious
> s/4.6/$X.$Y/g on this patch you may keep my ack on those too.
Now done. There was some fiddliness around ~4.4. Hopefully the
results are righ
>>> On 18.11.15 at 17:21, wrote:
> I have a suggestion to remove the "no accessing two percpu rwlock resources
> simultaneously on the same PCPU" restriction:
>
> On accessing the second resource, we can detect that the percpu read area is
> already
> in use, if this is the case then we can just
Hi Ian,
On 16/11/15 13:33, Ian Campbell wrote:
> On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
>> The 2 registers are not described in the software spec (ARM IHI 0069A)
>> and their offsets are marked "implementation defined".
>
> They do exist in "PRD03-GENC-010745 24.0", in that they a
Hi Ian,
On 16/11/15 13:27, Ian Campbell wrote:
> On Fri, 2015-11-13 at 11:54 +, Julien Grall wrote:
>> Most of the identification registers space contains implementation
>> defined registers (see 8.1.13 in ARM IHI 0069A) and only GIC{D,R}_PIDR2
>> is required to be implemented.
>
> I think yo
Hi all,
This series aims to fix the 32-bit access on 64-bit registers. Some guest
OS such as FreeBSD and Linux (ITS and recently 32-bit guest using GICv3)
use 32-bit access and will crash at boot time.
For all the changes see in each patch.
Sincerely yours,
Julien Grall (6):
xen/arm: vgic-v2:
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
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
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.
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
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
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
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
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.
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
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
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 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 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 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, 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
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 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
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 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
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 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]
>
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
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
1 - 100 of 173 matches
Mail list logo
