>>> On 22.12.15 at 08:40, wrote:
> Maybe, there are still some misunderstanding about your expectation.
> Let me summarize it here.
>
> After Quan's patch-set, there are two types of error code:
> - -EOPNOTSUPP
> Now we only support and use software way to synchronize the invalidation,
> if someo
flight 66816 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66816/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62044
build-a
>On 22.12.2015 at 4:01pm wrote:
> >>> On 22.12.15 at 08:40, wrote:
> > Maybe, there are still some misunderstanding about your expectation.
> > Let me summarize it here.
> >
> > After Quan's patch-set, there are two types of error code:
> > - -EOPNOTSUPP
> > Now we only support and use software w
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, December 22, 2015 4:01 PM
> To: Wu, Feng ; Xu, Quan
> Cc: 'andrew.coop...@citrix.com' ;
> 'george.dun...@eu.citrix.com' ; Nakajima, Jun
> ; Tian, Kevin ; 'xen-
> de...@lists.xen.org' ; 'k...@xen.org' ;
>
On Mon, 2015-12-21 at 08:32 -0700, Jan Beulich wrote:
> > > > On 21.12.15 at 08:21, wrote:
> > --- a/xen/arch/x86/mm/guest_walk.c
> > +++ b/xen/arch/x86/mm/guest_walk.c
> > @@ -90,6 +90,55 @@ static uint32_t set_ad_bits(void *guest_p, void
> > *walk_p, int set_dirty)
> > return 0;
> > }
> >
>>> On 22.12.15 at 09:10, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, December 22, 2015 4:01 PM
>> To: Wu, Feng ; Xu, Quan
>> Cc: 'andrew.coop...@citrix.com' ;
>> 'george.dun...@eu.citrix.com' ; Nakajima, Jun
>> ; Tian, Kevin ; 'xen-
>>> On 22.12.15 at 09:10, wrote:
> For Device-TLB flush error, I think we need to propagated error code.
> For IEC/iotlb/context flush error, if panic is acceptable, we can ignore the
> propagated error code. BTW, it is very challenge / tricky to handle all
> Of error, and some error is unrecover
>>> On 22.12.15 at 03:54, wrote:
> On Mon, 2015-12-21 at 08:07 -0700, Jan Beulich wrote:
>> > > > On 21.12.15 at 08:21, wrote:
>> > @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input, unsigned
>> > int *eax, unsigned int *ebx,
>> > /* Don't expose INVPCID to non-hap hvm. */
>> >
> On December 22, 2015 4:27pm, wrote:
> >>> On 22.12.15 at 09:10, wrote:
> > For Device-TLB flush error, I think we need to propagated error code.
> > For IEC/iotlb/context flush error, if panic is acceptable, we can
> > ignore the propagated error code. BTW, it is very challenge / tricky
> > to
>>> On 22.12.15 at 09:12, wrote:
> On Mon, 2015-12-21 at 08:32 -0700, Jan Beulich wrote:
>> > > > On 21.12.15 at 08:21, wrote:
>> > --- a/xen/arch/x86/mm/guest_walk.c
>> > +++ b/xen/arch/x86/mm/guest_walk.c
>> > @@ -90,6 +90,55 @@ static uint32_t set_ad_bits(void *guest_p, void
>> > *walk_p, int
flight 66779 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66779/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 65650
build-amd64-prev
flight 66831 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66831/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 62112
build-a
On 2015-12-21 23:58, xen-devel-requ...@lists.xen.org wrote:
Send Xen-devel mailing list submissions to
xen-devel@lists.xen.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel
or, via email, send a message with subj
>>> On 21.12.15 at 18:16, wrote:
> c/s 506db90 "x86/HVM: merge HVM and PVH hypercall tables" introduced a path
> whereby 'okay' was used uninitialised, with broke compilation on CentOS 7.
It appeared to be used uninitialized, but wasn't in fact (i.e. the
outcome - the value rc gets set to - didn'
On 22/12/2015 08:57, Jan Beulich wrote:
On 21.12.15 at 18:16, wrote:
>> c/s 506db90 "x86/HVM: merge HVM and PVH hypercall tables" introduced a path
>> whereby 'okay' was used uninitialised, with broke compilation on CentOS 7.
> It appeared to be used uninitialized, but wasn't in fact (i.e. th
>>> On 22.12.15 at 09:43, wrote:
> Let's finish our discussion. I accept your idea. But I need to separate it
> into 3 patch set (It is complicated for me, sometime it makes me crash.):
>Patch set 1: Device-TLB/iotlb flush error. (send out this week)
>Patch set 2: context flush error. (
> On 22.12.2015 at 5:09pm, wrote:
> >>> On 22.12.15 at 09:43, wrote:
> > Let's finish our discussion. I accept your idea. But I need to
> > separate it into 3 patch set (It is complicated for me, sometime it makes me
> crash.):
> >Patch set 1: Device-TLB/iotlb flush error. (send out this wee
On Tue, 2015-12-22 at 01:30 -0700, Jan Beulich wrote:
> > > > On 22.12.15 at 03:54, wrote:
> > On Mon, 2015-12-21 at 08:07 -0700, Jan Beulich wrote:
> > > > > > On 21.12.15 at 08:21, wrote:
> > > > @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input,
> > > > unsigned
> > > > int *eax, unsign
On 12/16/2015 09:32 AM, Robert Hu wrote:
On Fri, 2015-12-11 at 12:01 +, Ian Campbell wrote:
On Fri, 2015-12-11 at 11:48 +0800, Robert Hu wrote:
On Fri, 2015-12-11 at 01:16 +, osstest service owner wrote:
flight 65633 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/
El 22/12/15 a les 0.45, Boris Ostrovsky ha escrit:
> With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
> builder if supported") location of ramdisk may not be available to
> HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
> guest supports unmapped initrd.
>
>
>>> On 22.12.15 at 10:25, wrote:
> On Tue, 2015-12-22 at 01:30 -0700, Jan Beulich wrote:
>> > > > On 22.12.15 at 03:54, wrote:
>> > On Mon, 2015-12-21 at 08:07 -0700, Jan Beulich wrote:
>> > > > > > On 21.12.15 at 08:21, wrote:
>> > > > @@ -4600,6 +4600,14 @@ void hvm_cpuid(unsigned int input,
>
On 21/12/2015 17:50, Boris Ostrovsky wrote:
> On 12/21/2015 12:16 PM, Andrew Cooper wrote:
>> c/s 506db90 "x86/HVM: merge HVM and PVH hypercall tables" introduced
>> a path
>> whereby 'okay' was used uninitialised, with broke compilation on
>> CentOS 7.
>>
>> Splitting the error handling like this
On 21/12/15 22:57, M A Young wrote:
> I am testing Fedora rawhide in a xen pv guest and I get the error
> [9.809550] genirq: Flags mismatch irq 8. (hvc_console) vs.
> (rtc0)
> [9.809714] hvc_open: request_irq failed with rc -16.
> during the boot and the hvc console doesn
> On 22.12.2015 at 5:09pm, wrote:
> >>> On 22.12.15 at 09:43, wrote:
> > Let's finish our discussion. I accept your idea. But I need to
> > separate it into 3 patch set (It is complicated for me, sometime it makes me
> crash.):
> >Patch set 1: Device-TLB/iotlb flush error. (send out this wee
Changes in v5:
*Add static for opt_pku.
*Update commit message for some patches.
*Add condition 5:the access is to a user page to pkey_fault, and simplify #ifdef
for guest_walk_tables patch.
*Don't write XSTATE_PKRU to PV's xcr0.
*count == 0 is combined in hvm_cpuid function.
Changes in v4:
*Delet
CR4.PKE(bit 22) enables support for the RDPKRU/WRPKRU instructions to access
PKRU and
the protection keys check (a page fault trigger).
This patch adds X86_CR4_PKE to hvm_cr4_guest_reserved_bits so that CR4 check
works
before setting.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
---
This patch adds the flag("pku") to enable Memory Protection Keys, and updates
the markdown.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
---
docs/misc/xen-command-line.markdown | 10 ++
xen/arch/x86/cpu/common.c | 10 +-
xen/include/asm-x86/cpufeature.h|
This patch adds xstate support for pkeys.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
---
xen/arch/x86/xstate.c| 3 ++-
xen/include/asm-x86/xstate.h | 4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index b6
Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
leaf entries of the page tables.
PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the access-disable bit for
protection key i (ADi); PKRU[
This patch adds pkeys support for cpuid handing.
Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
Signed-off-by: Huaitong Han
---
tools/libxc/xc_cpufeature.h | 2 ++
tools/libxc/xc_cpuid_x86.c | 6 -
This patch disables pkeys for guest in non-paging mode, However XEN always uses
paging mode to emulate guest non-paging mode, To emulate this behavior, pkeys
needs to be manually disabled when guest switches to non-paging mode.
Signed-off-by: Huaitong Han
Reviewed-by: Andrew Cooper
---
xen/arch
On 22/12/15 10:30, Huaitong Han wrote:
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -373,6 +373,45 @@ static always_inline void clear_in_cr4 (unsigned long
> mask)
> write_cr4(read_cr4() & ~mask);
> }
>
> +static inline unsigned int read_pkru(void)
>
On 21/12/15 14:48, Jan Beulich wrote:
On 21.12.15 at 15:41, wrote:
>> On 21/12/15 14:34, Jan Beulich wrote:
>>> --- a/xen/arch/x86/io_apic.c
>>> +++ b/xen/arch/x86/io_apic.c
>>> @@ -2310,13 +2310,14 @@ int ioapic_guest_read(unsigned long phys
>>> return 0;
>>> }
>>>
>>> -#define WARN_
flight 66794 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66794/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65639
test-amd64-i386-x
On 22/12/15 04:46, Doug Goldstein wrote:
> The flask utilities only have dependencies on libxc so there's no
> downside to always building it. Distros and projects based on Xen can
> put these utilities into a different package and not install them for
> everyone. Prior to this change FLASK_ENABLE
flight 66936 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66936/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
On 18/12/15 16:08, Malcolm Crossley 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 operations which can be particularly slo
This run is configured for baseline tests only.
flight 38549 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38549/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail
On 18/12/15 16:08, Malcolm Crossley wrote:
> The per domain p2m read lock suffers from significant contention when
> performance multi-queue block or network IO due to the parallel
> grant map/unmaps/copies occuring on the DomU's p2m.
>
> On multi-socket systems, the contention results in the lock
On 18/12/15 13:50, David Vrabel wrote:
> Holding the p2m lock while calling ept_sync_domain() is very expensive
> since it does a on_selected_cpus() call. IPIs on many socket machines
> can be very slows and on_selected_cpus() is serialized.
>
> It is safe to defer the invalidate until the p2m lo
MiniOS for QEMU stubdom has frontends, such as mini-os/blkfront.c and
mini-os/netfront.c, not backends.
Cheers,
Stefano
On Mon, 21 Dec 2015, Eric Shelton wrote:
> Seeing as "All OSes providing PV backends are susceptible," doesn't this
> include MiniOS for QEMU stubdom as well?
> Are there pa
>>> On 22.12.15 at 11:30, wrote:
> This patch adds the flag("pku") to enable Memory Protection Keys, and updates
> the markdown.
>
> Signed-off-by: Huaitong Han
> Reviewed-by: Andrew Cooper
Please avoid resending patches which got applied already.
Jan
___
On 12/21/15 6:53 AM, Jan Beulich wrote:
On 21.12.15 at 13:40, wrote:
>> On 21/12/15 12:11, Jan Beulich wrote:
>> On 18.12.15 at 22:35, wrote:
Since we now support changing Xen options with Kconfig, we should save
the configuration that was used to build up Xen. This will save i
flight 66848 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66848/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3865 xen-build fail REGR. vs. 66433
build-i386-xsm
On 12/21/15 9:35 AM, Jan Beulich wrote:
On 21.12.15 at 16:20, wrote:
>> On 12/21/15 8:51 AM, Jan Beulich wrote:
>> On 21.12.15 at 15:35, wrote:
On 12/21/15 6:11 AM, Jan Beulich wrote:
On 18.12.15 at 22:35, wrote:
>> Since we now support changing Xen options with Kconfi
>>> On 22.12.15 at 13:45, wrote:
> On 12/21/15 6:53 AM, Jan Beulich wrote:
> On 21.12.15 at 13:40, wrote:
>>> On 21/12/15 12:11, Jan Beulich wrote:
>>> On 18.12.15 at 22:35, wrote:
> Since we now support changing Xen options with Kconfig, we should save
> the configuration that w
>>> On 22.12.15 at 13:45, wrote:
> On 12/21/15 9:35 AM, Jan Beulich wrote:
> On 21.12.15 at 16:20, wrote:
>>> On 12/21/15 8:51 AM, Jan Beulich wrote:
>>> On 21.12.15 at 15:35, wrote:
> On 12/21/15 6:11 AM, Jan Beulich wrote:
> On 18.12.15 at 22:35, wrote:
>>> Since we no
>>> On 22.12.15 at 11:30, wrote:
I dislike having to repeat this: Please trim your Cc lists.
> --- a/xen/arch/x86/mm/guest_walk.c
> +++ b/xen/arch/x86/mm/guest_walk.c
> @@ -90,6 +90,57 @@ static uint32_t set_ad_bits(void *guest_p, void *walk_p,
> int set_dirty)
> return 0;
> }
>
> +exte
>>> On 22.12.15 at 11:30, wrote:
> --- a/xen/include/asm-x86/xstate.h
> +++ b/xen/include/asm-x86/xstate.h
> @@ -34,13 +34,15 @@
> #define XSTATE_OPMASK (1ULL << 5)
> #define XSTATE_ZMM (1ULL << 6)
> #define XSTATE_HI_ZMM (1ULL << 7)
> +#define XSTATE_PKRU(1ULL << 9)
> #define XSTATE
>>> On 22.12.15 at 11:30, wrote:
> This patch adds pkeys support for cpuid handing.
>
> Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
> CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
>
> Signed-off-by: Huaitong Han
> ---
> tools/libxc/xc_cpufeature
flight 38550 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38550/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 38518
test-amd64-i3
Stefano Stabellini, on Tue 22 Dec 2015 12:24:35 +, wrote:
> MiniOS for QEMU stubdom has frontends, such as mini-os/blkfront.c and
> mini-os/netfront.c, not backends.
There is one backend, tpmback. It however doesn't use a ring.
Samuel
___
Xen-deve
On Thu, 17 Dec 2015, Markus Armbruster wrote:
> Cc: Stefano Stabellini
> Cc: xen-de...@lists.xensource.com
> Signed-off-by: Markus Armbruster
> ---
> xen-hvm.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/xen-hvm.c b/xen-hvm.c
> index 3d78a0c..2a93390 100644
> --- a/xen-hvm.c
>>> On 18.12.15 at 15:09, wrote:
> +/**
> + * rspin_until_writer_unlock - inc reader count & spin until writer is gone
Stale comment - the function doesn't increment anything.
Also throughout the file, with Linux coding style converted to Xen
style, comment style should be made Xen-like too.
>
On Mon, 21 Dec 2015, Jan Beulich wrote:
> >>> On 20.12.15 at 13:25, wrote:
> > flight 66583 xen-4.4-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/66583/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not b
On 22/12/15 12:23, George Dunlap wrote:
> On 18/12/15 13:50, David Vrabel wrote:
>> Holding the p2m lock while calling ept_sync_domain() is very expensive
>> since it does a on_selected_cpus() call. IPIs on many socket machines
>> can be very slows and on_selected_cpus() is serialized.
>>
>> It is
On 12/22/2015 04:42 AM, Roger Pau Monné wrote:
El 22/12/15 a les 0.45, Boris Ostrovsky ha escrit:
With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
builder if supported") location of ramdisk may not be available to
HVMlite guests by the time alloc_magic_pages_hvm() is invoked if
Hello Russell,
Would you please consider this patch for the next merge window? It
is a very old patch (March 2014) which has been left over.
See some of the original threads here:
http://marc.info/?l=linux-arm-kernel&m=138920414402610&w=2
http://marc.info/?l=linux-arm-kernel&m=139031200118436&w=
On 22/12/15 14:01, Andrew Cooper wrote:
> On 22/12/15 12:23, George Dunlap wrote:
>> On 18/12/15 13:50, David Vrabel wrote:
>>> Holding the p2m lock while calling ept_sync_domain() is very expensive
>>> since it does a on_selected_cpus() call. IPIs on many socket machines
>>> can be very slows and
>>> On 22.12.15 at 14:55, wrote:
> On Mon, 21 Dec 2015, Jan Beulich wrote:
>> >>> On 20.12.15 at 13:25, wrote:
>> > flight 66583 xen-4.4-testing real [real]
>> > http://logs.test-lab.xenproject.org/osstest/logs/66583/
>> >
>> > Regressions :-(
>> >
>> > Tests which did not succeed and are bloc
El 22/12/15 a les 15.12, Boris Ostrovsky ha escrit:
> On 12/22/2015 04:42 AM, Roger Pau Monné wrote:
>> Also, why is everything done inside of alloc_magic_pages_hvm moved to
>> start_info_hvm? AFAICT we should only need to move the code that fills
>> the hvm_start_info struct, but the rest of the c
On Tue, 22 Dec 2015, Jan Beulich wrote:
> >>> On 22.12.15 at 14:55, wrote:
> > On Mon, 21 Dec 2015, Jan Beulich wrote:
> >> >>> On 20.12.15 at 13:25, wrote:
> >> > flight 66583 xen-4.4-testing real [real]
> >> > http://logs.test-lab.xenproject.org/osstest/logs/66583/
> >> >
> >> > Regressions :
On Tue, Dec 22, 2015 at 02:17:17PM +, Stefano Stabellini wrote:
> Hello Russell,
>
> Would you please consider this patch for the next merge window? It
> is a very old patch (March 2014) which has been left over.
This patch has some obvious problems...
> diff --git a/arch/arm/Kconfig b/arch/
On 22/12/15 12:52, Jan Beulich wrote:
On 22.12.15 at 13:45, wrote:
>> On 12/21/15 9:35 AM, Jan Beulich wrote:
>> On 21.12.15 at 16:20, wrote:
On 12/21/15 8:51 AM, Jan Beulich wrote:
On 21.12.15 at 15:35, wrote:
>> On 12/21/15 6:11 AM, Jan Beulich wrote:
>> On 1
On 12/22/2015 09:36 AM, Roger Pau Monné wrote:
El 22/12/15 a les 15.12, Boris Ostrovsky ha escrit:
On 12/22/2015 04:42 AM, Roger Pau Monné wrote:
Also, why is everything done inside of alloc_magic_pages_hvm moved to
start_info_hvm? AFAICT we should only need to move the code that fills
the hvm_
On 22/12/15 14:20, David Vrabel wrote:
> On 22/12/15 14:01, Andrew Cooper wrote:
>> On 22/12/15 12:23, George Dunlap wrote:
>>> On 18/12/15 13:50, David Vrabel wrote:
Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does a on_selected_cpus() call. IPIs on m
flight 66804 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66804/
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. 66614
build-amd64-pvops
The XSA mentions that "PV frontend patches will be developed and
released (publicly) after the embargo date." Has anything been done
towards this that should also be incorporated into MiniOS? On a
system utilizing a "driver domain," where a backend is running on a
domain that is considered unpriv
On 22/12/15 13:02, Jan Beulich wrote:
On 22.12.15 at 11:30, wrote:
>
> I dislike having to repeat this: Please trim your Cc lists.
>
>> --- a/xen/arch/x86/mm/guest_walk.c
>> +++ b/xen/arch/x86/mm/guest_walk.c
>> @@ -90,6 +90,57 @@ static uint32_t set_ad_bits(void *guest_p, void *walk_p,
>>
On 22/12/15 10:30, Huaitong Han wrote:
> Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
> leaf entries of the page tables.
>
> PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
> domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the acc
This should retain the .config file from the Kconfig process so that we
know how this build of Xen was configured.
Signed-off-by: Doug Goldstein
---
ts-xen-build | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-build b/ts-xen-build
index b02e737..80b1faa 100755
--- a/ts-xen-build
+++ b
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 02:17:17PM +, Stefano Stabellini wrote:
> > Hello Russell,
> >
> > Would you please consider this patch for the next merge window? It
> > is a very old patch (March 2014) which has been left over.
>
> This patch ha
On 12/22/15 9:44 AM, Doug Goldstein wrote:
> This should retain the .config file from the Kconfig process so that we
> know how this build of Xen was configured.
>
> Signed-off-by: Doug Goldstein
> ---
> ts-xen-build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/ts-xen-build b/ts-xen
On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote:
> The code builds, but of course it could not actually run on CPU_V6. But
> the use case for me is building drivers/xen/grant-table.c, which can
> only run on CPU_V7 anyway, so it is not a problem.
What I'm concerned about in this
>>> On 22.12.15 at 15:46, wrote:
> On 22/12/15 12:52, Jan Beulich wrote:
> On 22.12.15 at 13:45, wrote:
>>> On 12/21/15 9:35 AM, Jan Beulich wrote:
>>> On 21.12.15 at 16:20, wrote:
> On 12/21/15 8:51 AM, Jan Beulich wrote:
> On 21.12.15 at 15:35, wrote:
>>> On 12/21/15 6
On 12/22/15 9:59 AM, Jan Beulich wrote:
On 22.12.15 at 15:46, wrote:
>> On 22/12/15 12:52, Jan Beulich wrote:
>> On 22.12.15 at 13:45, wrote:
On 12/21/15 9:35 AM, Jan Beulich wrote:
On 21.12.15 at 16:20, wrote:
>> On 12/21/15 8:51 AM, Jan Beulich wrote:
>> On 2
On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote:
> > The code builds, but of course it could not actually run on CPU_V6. But
> > the use case for me is building drivers/xen/grant-table.c, which can
> > only run on CPU_V7 anyw
>>> On 22.12.15 at 17:02, wrote:
> How does it not make sense in this case? That's what Andrew and I are
> asking you to explain.
But I already explained it: The file isn't needed for booting.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
ht
>>> On 17.12.15 at 17:31, wrote:
> I've looked at reworking XENMEM_exchange to avoid mfn_to_gmfn. My idea would
> be to allocate a temporary array to store the GFN between the two loops.
> However, the array would be quite large (the max default is 18 on ARM),
> so I don't know if it's acceptable.
>>> On 17.12.15 at 17:31, wrote:
> Direct mapped domain needs to retrieve the exact same underlying
> physical page when the region is re-populated.
In which case - what sense does it make for such a domain to
exchange memory (the primary purpose of which is to get
_different_ memory populated at
>>> On 17.12.15 at 17:31, wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1786,6 +1786,57 @@ int assign_pages(
> return -1;
> }
>
> +int steal_page(
> +struct domain *d, struct page_info *page, unsigned int memflags)
> +{
I think it would better go into co
The following changes since commit c3626ca7df027dabf0568284360a23faf18f0884:
Update version for v2.5.0-rc3 release (2015-12-07 17:47:40 +)
are available in the git repository at:
git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-12-22
for you to fetch changes up to fc3e
From: Jan Beulich
The remaining log message in pci_msix_write() is wrong, as there guest
behavior may only appear to be wrong: For one, the old logic didn't
take the mask-all bit into account. And then this shouldn't depend on
host device state (i.e. the host may have masked the entry without the
From: Jan Beulich
The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.
Signed-off-by: Jan Beulich
Signe
From: Jan Beulich
Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.
Signed-off-by: Jan Beulich
Signed-off-by: Stefano Stabellini
Reviewed-by: Stefano Stabellini
---
hw/xen/xen_pt.h |2 ++
The Xen toolstack uses "vhd" to specify a disk in VHD format, however
the name of the driver in QEMU is "vpc". Replace "vhd" with "vpc", so
that QEMU can find the right driver to use for it.
Signed-off-by: Stefano Stabellini
---
hw/block/xen_disk.c |3 +++
1 file changed, 3 insertions(+)
di
Current Intel VPMU emulation needs to perform more checks when writing
PMU MSRs on guest's behalf:
* MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
* MSR_CORE_PERF_FIXED_CTR_CTRL has more reserved bits in PMU version 2
* MSR_CORE_PERF_GLOBAL_OVF_CTRL's bit 61 is allowed on versions greater
* than
>>> On 16.12.15 at 22:24, wrote:
> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2 */
> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore
> insn) */
> +#define X86_FEATURE_XSTORE_EN((FSMAX+1)*32+ 3) /* on-CPU RNG enabled
> */
> +#de
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/include/public/arch-x86/featureset.h
> +++ b/xen/include/public/arch-x86/featureset.h
> @@ -163,6 +163,7 @@
>
> /* Intel-defined CPU features, CPUID level 0x0007:0.ebx, word 5 */
> #define X86_FEATURE_FSGSBASE ( 5*32+ 0) /* {RD,WR}{FS,GS}BA
>>> On 16.12.15 at 22:24, wrote:
> --- /dev/null
> +++ b/xen/arch/x86/cpuid/cpuid-private.h
> @@ -0,0 +1,27 @@
> +#ifdef __XEN__
> +
> +#include
> +
> +#include
> +
> +#else
> +
> +# error TODO for userspace
I suppose your intentions with this will become apparent in later
patches?
Jan
_
Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"
to make this happen automatically. This is not a great solution
On 22/12/15 10:30, Huaitong Han wrote:
> Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
> leaf entries of the page tables.
>
> PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
> domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the acce
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -324,6 +324,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
>* we do "generic changes."
>*/
> for (i = 0; i < XEN_NR_FEATURESET_ENTRIES; ++i) {
> + c-
On 22/12/15 16:28, Jan Beulich wrote:
On 16.12.15 at 22:24, wrote:
>> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2
>> */
>> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore
>> insn) */
>> +#define X86_FEATURE_XSTORE_EN ((FSMAX
On Thu, 17 Dec 2015, Ian Campbell wrote:
> > > +/* Save PPI and SGI states (per-CPU) */
> > > +spin_lock(&v->arch.vgic.lock);
> >
> > vgic_lock
>
> Ah, yes, this function was originally in save.c so didn't have access, but
> now it is in the right place I should use all the correct
>>> On 16.12.15 at 22:24, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -481,7 +481,7 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>
> if (c->extended_cpuid_level >= 0x8007) {
> c->x86_power = cpuid_edx(0x8007);
> -
>>> On 16.12.15 at 22:24, wrote:
> xen/arch/x86/Makefile | 1 +
> xen/arch/x86/cpuid.c| 23 +++
> xen/arch/x86/setup.c| 3 +++
> xen/include/asm-x86/cpuid.h | 22 ++
> 4 files changed, 49 insertions(+)
> create mode 100644 xen/arch/
On Tue, 10 Nov 2015, Ian Campbell wrote:
> s/it/if/ makes more sense.
>
> Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
> xen/include/asm-arm/vgic.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
>
On Tue, 10 Nov 2015, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
Acked-by: Stefano Stabellini
> xen/include/asm-arm/domain.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index e7e40da..
>>> On 16.12.15 at 22:24, wrote:
> @@ -190,6 +191,56 @@ long arch_do_sysctl(
> }
> break;
>
> +case XEN_SYSCTL_get_featureset:
> +{
> +uint32_t *featureset;
const
> +unsigned int nr;
> +
> +/* Request for maximum number of features? */
> +
1 - 100 of 173 matches
Mail list logo
