>>> On 15.10.15 at 03:58, wrote:
> On Tue, Oct 13, 2015 at 07:49:12AM -0600, Jan Beulich wrote:
>> >>> On 12.10.15 at 08:07, wrote:
>>
>> > @@ -2257,9 +2261,14 @@ static int hvm_load_cpu_xsave_states(struct domain
> *d, hvm_domain_context_t *h)
>> > v->arch.xcr0_accum = ctxt->xcr0_accum;
>
On 10/14/2015 05:26 PM, Jan Beulich wrote:
On 14.10.15 at 11:08, wrote:
After some thinking, just set/clear p2m->ept.ept_ad is not enough -- we
also need to __vmwrite it to VMCS's EPTP, and then call ept_sync_domain.
Ah, yes, this makes sense of course.
I have verified attached patch can w
>>> On 15.10.15 at 03:03, wrote:
> Jan Beulich wrote on 2015-10-14:
>> As long as the multi-millisecond spins aren't going to go away by
>> other means, I think conversion to async mode is ultimately unavoidable.
>
> I am not fully agreed. I think the time to spin is important. To me, less
> tha
xen/interface/xen.h is not exported from kernel headers so remove the
dependency and provide needed defines for domid_t and xen_pfn_t if they
are not already defined by some other e.g. Xen specific headers.
Suggested by Andrew Cooper on lkml message
<5569f9c9.8000...@citrix.com>.
The ifdef for A
Fixes userspace compilation errors like:
xen/gntalloc.h:22:2: error: unknown type name ‘uint16_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/xen/gntalloc.h | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/uapi/xen/gntalloc.h b/include/uapi/x
Fixes userspace compilation errors like:
xen/gntdev.h:38:2: error: unknown type name ‘uint32_t’
Signed-off-by: Mikko Rapeli
---
include/uapi/xen/gntdev.h | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/include/uapi/xen/gntdev.h b/include/
flight 62959 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62959/
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. 62948
test-amd64-amd64-xl-pv
This run is configured for baseline tests only.
flight 38169 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38169/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 1e69581335354a7df3bc07b21e495b0b3c5909c0
baseline version:
ovm
Sometimes xennet_create_queues() may failed to created all requested
queues, we need to update num_queues to real created to avoid NULL
pointer dereference.
Signed-off-by: Joe Jin
Cc: Wei Liu
Cc: Ian Campbell
Cc: David S. Miller
---
drivers/net/xen-netfront.c |9 ++---
1 files changed
On Tue, Oct 13, 2015 at 07:49:12AM -0600, Jan Beulich wrote:
> >>> On 12.10.15 at 08:07, wrote:
>
> > @@ -2257,9 +2261,14 @@ static int hvm_load_cpu_xsave_states(struct domain
> > *d, hvm_domain_context_t *h)
> > v->arch.xcr0_accum = ctxt->xcr0_accum;
> > if ( ctxt->xcr0_accum & XSTATE
On 10/02/2015 11:48 AM, Roger Pau Monne wrote:
Introduce a bitmap in x86 xen_arch_domainconfig that allows enabling or
disabling specific devices emulated inside of Xen for HVM guests.
...
diff --git a/xen/include/public/arch-x86/xen.h
b/xen/include/public/arch-x86/xen.h
index 2ecc9c9..c97a
flight 62964 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62964/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 1e69581335354a7df3bc07b21e495b0b3c5909c0
baseline version:
ovmf af9785a9ed61daea52b47f0bf448f1f228b
Jan Beulich wrote on 2015-10-14:
On 14.10.15 at 07:12, wrote:
>> Jan Beulich wrote on 2015-10-13:
>> On 13.10.15 at 07:27, wrote:
Jan Beulich wrote on 2015-10-12:
On 12.10.15 at 03:42, wrote:
>> So, my suggestion is that we can rely on user to not assign the
>> ATS
On 10/7/2015 7:16 PM, Wei Liu wrote:
Hi all
I'm pleased to announce that Xen 4.6 is released. As release manager I
would like to thank everyone who involved in the making of 4.6 release
(either in the form of patch, bug report or packaging effort). This
release wouldn't have happened without all
flight 62958 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62958/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-rumpuserxen-amd64 10 guest-start fail REGR. vs. 59254
test-amd64-i386-xl-qe
On 14/10/2015 18:49, Stefano Stabellini wrote:
Hi all,
Hi Stefano,
this small patch series enable cpu_hotplug in ARM and ARM64 guests,
using the PV path to plug and unplug the cpus and psci to enable/disable
them.
That's a cool things to have on ARM!
I've got few questions related to CPU h
Hi Stefano,
On 14/10/2015 18:49, Stefano Stabellini wrote:
Build cpu_hotplug for ARM and ARM64 guests.
Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
empty implementation on ARM and ARM64. On x86 just call
arch_(un)register_cpu as we are already doing.
Initialize cpu_hotpl
Hi Stefano,
On 14/10/2015 18:49, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6c09cc4..59f5421 100644
--- a/arch/arm/xen/enlighte
Hi Stefano,
On 14/10/2015 16:57, Stefano Stabellini wrote:
-make -C BaseTools/Source/C
-OvmfPkg/build.sh -a X64 -b RELEASE -n 4
-cp Build/OvmfX64/RELEASE_GCC*/FV/OVMF.fd ovmf.bin
+make -C BaseTools
+
+if [[ $RAISIN_ARCH = "arm64" ]]
+then
+# Just use gcc4.8 flags
flight 62956 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62956/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 9 windows-installfail REGR. vs. 62711
test-amd64-amd64-xl-
On Wed, 14 Oct 2015, Konrad Rzeszutek Wilk wrote:
> On October 14, 2015 1:49:55 PM EDT, Stefano Stabellini
> wrote:
> >Build cpu_hotplug for ARM and ARM64 guests.
> >
> >Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
> >empty implementation on ARM and ARM64. On x86 just call
On October 14, 2015 1:49:55 PM EDT, Stefano Stabellini
wrote:
>Build cpu_hotplug for ARM and ARM64 guests.
>
>Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
>empty implementation on ARM and ARM64. On x86 just call
>arch_(un)register_cpu as we are already doing.
>
>Initialize
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/enlighten.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 6c09cc4..59f5421 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -93,6 +93,12 @@ static voi
Build cpu_hotplug for ARM and ARM64 guests.
Rename arch_(un)register_cpu to xen_(un)register_cpu and provide an
empty implementation on ARM and ARM64. On x86 just call
arch_(un)register_cpu as we are already doing.
Initialize cpu_hotplug on ARM.
Signed-off-by: Stefano Stabellini
---
arch/arm/i
When offlining a cpu, instead of cpu_down, call device_offline, which
also takes care of updating the cpu.dev.offline field. This keeps the
sysfs file /sys/devices/system/cpu/cpuN/online, up to date. Also move
the call to disable_hotplug_cpu, because it makes more sense to have it
there.
Signed-o
Hi all,
this small patch series enable cpu_hotplug in ARM and ARM64 guests,
using the PV path to plug and unplug the cpus and psci to enable/disable
them.
Stefano Stabellini (3):
xen/arm: Enable cpu_hotplug.c
xen, cpu_hotplug: call device_offline instead of cpu_down
xen/arm: do
Hi everyone,
I wanted to walk you through some of the results of the Review Process study
https://github.com/dicortazar/ipython-notebooks/blob/master/projects/xen-analysis/Code-Review-Metrics.ipynb
I am also looking for input and views.
Best Regards
Lars
== Caveats ==
C1) Only 60% percent of
On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 17:29 +0100, Stefano Stabellini wrote:
>
> > > Obviously the call to xen_be_unbind_evtchn is not useful as is, but I do
> > > wonder where the evtchn which the primary console must have somewhere
> > > actually is then...
> >
> > Ac
On 14/10/15 17:24, Roger Pau Monne wrote:
> Introduce a new filed to signal if the FPU has been initialised or not. Xen
"field", I am guessing?
> diff --git a/xen/include/public/arch-x86/hvm/save.h
> b/xen/include/public/arch-x86/hvm/save.h
> index c7560f2..c4863be 100644
> --- a/xen/include/pub
On Wed, 2015-10-14 at 17:29 +0100, Stefano Stabellini wrote:
> > Obviously the call to xen_be_unbind_evtchn is not useful as is, but I do
> > wonder where the evtchn which the primary console must have somewhere
> > actually is then...
>
> Actually I think that xen_be_unbind_evtchn might be usefu
On 14/10/15 17:21, George Dunlap wrote:
> Add systemd development libraries if we detect systemd present on the system
>
> Signed-off-by: George Dunlap
Sorry, meant to add a comment here...
> ---
> components/xen | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/components/
On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 16:41 +0100, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, Ian Campbell wrote:
> > > On Wed, 2015-10-14 at 15:10 +0100, Stefano Stabellini wrote:
> > > > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > > > In Xen 4.7 we are refacto
On Wed, Oct 14, 2015 at 06:24:40PM +0200, 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
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-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 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
---
xen/include/public/arch-x86/hvm/s
Introduce a new filed to signal if the FPU has been initialised or not. Xen
needs this new filed 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
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.
Since I don't have a pre-3.4 Xen box, I would like to request if this patch
series can be tested by the XenServer CI loop, which I'v
CentOS 7 now aliases acpica-tools instead of iasl, making its deps
essentially the same as Fedora. Add iasl|acpica-tools as an alias in
the Fedora deps, and make the CentOS deps a straight clone of the
Fedora deps (as they are for the other components).
Signed-off-by: George Dunlap
---
componen
Miscellaneous improvements
George Dunlap (5):
raisin: Handle aliases for packages, add pciutils-dev / libpci-dev
alias
raisin: Detect systemd
raisin: Allow iasl to alias acpica-tools, unify Fedora and CentOS deps
for xen
raisin: Change update/release parsing OSes
raisin: Add XEN_
Add systemd development libraries if we detect systemd present on the system
Signed-off-by: George Dunlap
---
components/xen | 10 ++
1 file changed, 10 insertions(+)
diff --git a/components/xen b/components/xen
index 090cceb..93ed288 100644
--- a/components/xen
+++ b/components/xen
@@
At the moment, something like 7.1.1503 will be parsed as RELEASE=7.1
UPDATE=1503. Change the bash string so that RELEASE=7 UPDATE=1.1503
in this case.
Also add an example CentOS 7 release string, and add the RELEASE /
UPDATE parsing to lsb_release as well.
Signed-off-by: George Dunlap
---
lib/
It's not uncommon for packages to be renamed, and for package managers
to know the translation from old packages to new packages. For
example:
# apt-get install pciutils-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libpci-dev' inste
Allowing the user to enable or disable specific functionality, such as
stubdoms.
Signed-off-by: George Dunlap
---
components/xen| 2 +-
configs/config-4.5| 4
configs/config-4.6| 4
configs/config-master | 4
4 files changed, 13 insertions(+), 1 deletion(-)
diff -
On Wed, 2015-10-14 at 16:57 +0100, Stefano Stabellini wrote:
> Disable ovmf build on x86_32: it does not work, the code was already
> forcing a x86_64 build.
FYI osstest builds OVMF (64-bit) in its build-i386 jobs just fine. e.g. in
[0]. That's useful in 32-on-64 type scenarios, maybe raisin doesn
On Wed, 2015-10-14 at 16:59 +0100, Ian Campbell wrote:
> I came up with the following patch[...]
> if (!xendev->dev) {
> +if (con->string) {
I've fixed the obvious typo in my actual tree...
> +munmap(con->sring, XC_PAGE_SIZE);
> +con->sring = NULL;
> +
Signed-off-by: Stefano Stabellini
---
lib/common-functions.sh |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 03642ae..27f6434 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -301,11 +301,16
Disable ovmf build on x86_32: it does not work, the code was already
forcing a x86_64 build.
---
Changes in v2:
- disable x86_32 build (it doesn't work, but it wasn't explicitly
disabled)
- remove export GCC48_AARCH64_PREFIX= as it is not necessary
- add a comment on why we are using -t GCC48
-
On 14/10/15 16:54, Jan Beulich wrote:
On 02.10.15 at 17:48, wrote:
>> --- a/xen/arch/x86/hvm/irq.c
>> +++ b/xen/arch/x86/hvm/irq.c
>> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t
>> via)
>> (via_type > HVMIRQ_callback_vector) )
>> via_type = HV
The insert_vcpu() hook is handled with inconsistent locking.
In fact, schedule_cpu_switch() calls the hook with runqueue
lock held, while sched_move_domain() relies on the hook
implementations to take the lock themselves (and, since that
is not done in Credit1 and RTDS, such operation is not safe
i
On Wed, 2015-10-14 at 16:41 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-14 at 15:10 +0100, Stefano Stabellini wrote:
> > > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > > > sepa
>>> On 02.10.15 at 17:48, wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -330,6 +330,10 @@ void hvm_set_callback_via(struct domain *d, uint64_t
> via)
> (via_type > HVMIRQ_callback_vector) )
> via_type = HVMIRQ_callback_none;
>
> +if ( via_type
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, take care of the case when
XEN_DOMCTL_SCHEDOP_getinfo is called but no vCPUs have
b
Idle vCPUs are set to run immediately, as a part of their
own initialization, so we shouldn't even try to put them
in a runqueue. In fact, actual schedulers don't do that,
even when asked to (that is rather explicit in Credit2
and RTDS, a bit less evident in Credit1).
Let's make things look as fol
schedule_cpu_switch() is meant to be only used for moving
pCPUs from a cpupool to no cpupool, and from there back
to a cpupool, *not* to move them directly from one cpupool
to another.
This is something that is reflected in the way it is
implemented, and should be kept in mind when looking at
it.
As, curently, there is no reason for bothering having
it and keeping it updated.
In fact, it is only used for dumping and changing
vCPUs parameters, but that can be achieved easily with
for_each_vcpu.
While there, improve alignment of comments, ad
add a const qualifier to a pointer, making things
Hey,
Here it comes v2 of this series. It took a bit more than how I wanted, mostly
because of the cpufreq issue I found while testing (as I though I was causing
it! :-/).
Version 1 is here:
http://www.gossamer-threads.com/lists/xen/devel/401619?page=last
I think I've addressed all the review c
In fact, csched_vcpu_remove() (i.e., the credit1
implementation of remove_vcpu()) manipulates runqueues,
so holding the runqueue lock is necessary.
Also, while there, *_lock_irq() (for the private lock) is
enough, there is no need to *_lock_irqsave().
Signed-off-by: Dario Faggioli
Reviewed-by: A
On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 15:10 +0100, Stefano Stabellini wrote:
> > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > > separate libraries which will provide backward and forward API and ABI
> >
flight 62954 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62954/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 60684
test-amd64
On Wed, 2015-10-07 at 16:08 +0100, George Dunlap wrote:
> On 07/10/15 15:15, Ian Campbell wrote:
> >
[...]
> > Signed-off-by: Ian Campbell
> > Acked-by: George Dunlap
> > Cc: George Dunlap
> >
[...]
> In any case:
>
> Acked-by: George Dunlap
It must be a really good patch... ;-)
Ian.
On 14/10/15 16:05, Ian Campbell wrote:
> On Wed, 2015-10-07 at 16:08 +0100, George Dunlap wrote:
>> On 07/10/15 15:15, Ian Campbell wrote:
>>>
> [...]
>>> Signed-off-by: Ian Campbell
>>> Acked-by: George Dunlap
>>> Cc: George Dunlap
>>>
> [...]
>> In any case:
>>
>> Acked-by: George Dunlap
>
>
On 10/14/2015 11:06 AM, Roger Pau Monné wrote:
El 14/10/15 a les 16.59, Boris Ostrovsky ha escrit:
On 10/14/2015 10:41 AM, Jan Beulich wrote:
On 02.10.15 at 17:48, wrote:
Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emu
El 14/10/15 a les 16.59, Boris Ostrovsky ha escrit:
> On 10/14/2015 10:41 AM, Jan Beulich wrote:
> On 02.10.15 at 17:48, wrote:
>>> Instead of choosing the interface to expose to guests based on the guest
>>> type, do it based on whether the guest has an emulated local apic or
>>> not.
>>>
>>>
On 10/14/2015 10:41 AM, Jan Beulich wrote:
On 02.10.15 at 17:48, wrote:
Instead of choosing the interface to expose to guests based on the guest
type, do it based on whether the guest has an emulated local apic or not.
Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
depending on Boris'
On Wed, 2015-10-14 at 14:08 +0100, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 01:21:11PM +0100, Ian Campbell wrote:
> > Aside: I'm a bit confused regarding whether our "stable release scheme" is
> > defined in terms of number of concurrently supported releases or in terms
> > of an absolute time.
>
On Wed, 7 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
>
> Previous patches have already
>> >>> On 13.10.2015 at 22:50 wrote:
> >>> On 13.10.15 at 16:29, wrote:
> >> > >>>On 29.09.2015 at 15:22 wrote:
> >> >>> On 29.09.15 at 04:53, wrote:
> >> Monday, September 28, 2015 2:47 PM, wrote:
> >> >> >>> On 28.09.15 at 05:08, wrote:
> >> >> Thursday, September 24, 2015 12:27 AM
>>> On 14.10.15 at 16:30, wrote:
> On 14/10/15 14:31, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/cpufeature.h
>> +++ b/xen/include/asm-x86/cpufeature.h
>> @@ -170,6 +170,7 @@
>> #define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
>> #define CPUID5_ECX_INTERRUPT_BREAK 0x2
>>
>> +#define cpu_h
On Mon, 2015-10-12 at 09:38 +0100, Ian Campbell wrote:
> The next Xen technical call will be at:
> Wed 14 Oct 17:00:00 BST 2015
> `date -d @1444838400`
No agenda => no call.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.o
>>> On 02.10.15 at 17:48, wrote:
> Instead of choosing the interface to expose to guests based on the guest
> type, do it based on whether the guest has an emulated local apic or not.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
depending on Boris' ack/review.
Jan
___
>> >>>On 13.10.2015 at 17:35, wrote:
> At 11:09 + on 11 Oct (1444561760), Xu, Quan wrote:
> What in particular is worrying you abo
>>> On 02.10.15 at 17:48, wrote:
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> Changes since v6:
> - Return ENODEV in pmtimer_load if the timer is disabled.
> - hvm_acpi_power_button and hvm_acpi_sleep_button become noops if the
>pmtimer is disabled.
But
On 14/10/15 14:31, Jan Beulich wrote:
> Their initialization happens without races, so there's no point in
> using atomic (locked) operations to update the respective flags.
> (There's one case where the clear_bit() was completely pointless.)
>
> Also drop a neighboring stale comment from AMD code.
>>> On 02.10.15 at 17:48, wrote:
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
(but awaiting an update to patch 2 for it to go in)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 14/10/15 14:31, Jan Beulich wrote:
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -170,6 +170,7 @@
> #define CPUID5_ECX_EXTENSIONS_SUPPORTED 0x1
> #define CPUID5_ECX_INTERRUPT_BREAK 0x2
>
> +#define cpu_has_fpu boot_cpu_has(X86_FEATURE_FP
On Wed, 2015-10-14 at 15:10 +0100, Stefano Stabellini wrote:
> On Wed, 7 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
> >
> > One such library will be l
On Wed, 7 Oct 2015, Ian Campbell wrote:
> Until the previous patch this relied on xc_fd(), which was only
> implemented for Xen 4.0 and earlier.
>
> I stopped short of disabling this by default, although I think there's
> a pretty strong argument for doing so.
>
> Removing this support drops the
On Wed, 2015-10-14 at 15:11 +0100, Stefano Stabellini wrote:
> On Wed, 14 Oct 2015, Ian Campbell wrote:
> > On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> > > I am very practical in this regard and I just don't want the raisin
> > > build to fail on arm64 with xen 4.6. We could hav
On Wed, 7 Oct 2015, Ian Campbell wrote:
> Using an existing libxenctrl handle after a fork was never
> particularly safe (especially if foreign mappings existed at the time
> of the fork) and the xc fd has been unavailable for many releases.
>
> Reopen the handle after fork and therefore do away w
On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 15:01 +0100, Stefano Stabellini wrote:
> > On Wed, 7 Oct 2015, Ian Campbell wrote:
> > > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > > separate libraries which will provide backward and forward API and ABI
> >
On Wed, 2015-10-14 at 15:01 +0100, Stefano Stabellini wrote:
> On Wed, 7 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
> >
> > One such library will be l
On Wed, 7 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> One such library will be libxenforeignmemory which provides access to
> privileged foreign mappings
On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> > I am very practical in this regard and I just don't want the raisin
> > build to fail on arm64 with xen 4.6. We could have a different raisin
> > config file, with a different ovmf revision
On Wed, 2015-10-14 at 14:51 +0100, Stefano Stabellini wrote:
> I am very practical in this regard and I just don't want the raisin
> build to fail on arm64 with xen 4.6. We could have a different raisin
> config file, with a different ovmf revision for Xen 4.6 on arm64, but I
> would prefer to avo
On 14/10/15 14:30, Jan Beulich wrote:
> EFER and SYSCALL are required on x86-64, and I think there's no point
> in assuming there might be no TSC. A few other predicates are simply
> unused. Of the ones left but constant I'm not convinced we should drop
> them; for some of them we may actually bett
On Wed, 7 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> One such library will be libxenforeignmemory which provides access to
> privileged foreign mappings
On 14/10/15 14:57, Andrew Cooper wrote:
> On 14/10/15 14:29, Jan Beulich wrote:
>> x86-64 requires FXSR, XMM, and XMM2, so there's no point in hiding
>> respective code behind conditionals.
>>
>> Signed-off-by: Jan Beulich
> Reviewed-by: Andrew Cooper , with two
> suggestions.
>
>> --- a/xen/arch/
On Wed, 7 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> One such library will be libxenforeignmemory which provides access to
> privileged foreign mappings
On 14/10/15 14:29, Jan Beulich wrote:
> x86-64 requires FXSR, XMM, and XMM2, so there's no point in hiding
> respective code behind conditionals.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , with two
suggestions.
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1295
On Wed, 14 Oct 2015, Ian Campbell wrote:
> On Wed, 2015-10-14 at 14:24 +0100, Wei Liu wrote:
> > On Wed, Oct 14, 2015 at 02:04:48PM +0100, Stefano Stabellini wrote:
> > > On Wed, 14 Oct 2015, Wei Liu wrote:
> > > > On Wed, Oct 14, 2015 at 01:55:39PM +0100, Stefano Stabellini wrote:
> > > > > On Wed
On Wed, 2015-10-14 at 14:30 +0100, Stefano Stabellini wrote:
> @@ -71,11 +71,29 @@ static inline int xenevtchn_close(xenevtchn_handle
> > *h)
> > #define xenevtchn_unmask(h,p) xc_evtchn_unmask(*h,p)
> > #define xenevtchn_unbind(h,p) xc_evtchn_unmask(*h,p)
> >
> > -static inline XenGnttab xen_xc
On Wed, Oct 14, 2015 at 02:35:57PM +0100, Ian Campbell wrote:
> On Wed, 2015-10-14 at 14:24 +0100, Wei Liu wrote:
> > On Wed, Oct 14, 2015 at 02:04:48PM +0100, Stefano Stabellini wrote:
> > > On Wed, 14 Oct 2015, Wei Liu wrote:
> > > > On Wed, Oct 14, 2015 at 01:55:39PM +0100, Stefano Stabellini wr
Their initialization happens without races, so there's no point in
using atomic (locked) operations to update the respective flags.
(There's one case where the clear_bit() was completely pointless.)
Also drop a neighboring stale comment from AMD code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x
x86-64 requires FXSR, XMM, and XMM2, so there's no point in hiding
respective code behind conditionals.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1542,8 +1542,7 @@ static int hvmemul_get_fpu(
return X86EMUL_UNHANDLEABLE;
On Wed, 2015-10-14 at 14:24 +0100, Wei Liu wrote:
> On Wed, Oct 14, 2015 at 02:04:48PM +0100, Stefano Stabellini wrote:
> > On Wed, 14 Oct 2015, Wei Liu wrote:
> > > On Wed, Oct 14, 2015 at 01:55:39PM +0100, Stefano Stabellini wrote:
> > > > On Wed, 14 Oct 2015, Ian Campbell wrote:
> > > > > On Wed
On Wed, 7 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
>
> One such library will be libxengnttab which provides access to grant
> tables.
>
> In preparation
One of the many things we need to do if we want to eventually be able
to run on e.g. Xeon Phi.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -261,6 +261,9 @@ static void __cpuinit generic_identify(s
cpuid_count(0x0007, 0, &dummy
On 14/10/15 14:27, Jan Beulich wrote:
On 14.10.15 at 15:22, wrote:
>> On 14/10/15 14:06, Jan Beulich wrote:
>>> Commit 6f8f53cc64 ("x86 cpu: Fix bug: unify cpu_dev attr as
>>> __cpuinitdata") fixed centaur_cpu_dev's annotation without also fixing
>>> the pointers hanging off of it. Even if CP
EFER and SYSCALL are required on x86-64, and I think there's no point
in assuming there might be no TSC. A few other predicates are simply
unused. Of the ones left but constant I'm not convinced we should drop
them; for some of them we may actually better make them non-constant
(see also next patch
>>> On 14.10.15 at 15:22, wrote:
> On 14/10/15 14:06, Jan Beulich wrote:
>> Commit 6f8f53cc64 ("x86 cpu: Fix bug: unify cpu_dev attr as
>> __cpuinitdata") fixed centaur_cpu_dev's annotation without also fixing
>> the pointers hanging off of it. Even if CPU hotplig support may be
>> purely theoreti
1 - 100 of 168 matches
Mail list logo
