>>> On 17.04.17 at 17:51, wrote:
> I have a question about __initconst that you mentioned.
Sure, but please trim your replies.
> On 4/3/2017 6:55 AM, Jan Beulich wrote:
> On 31.03.17 at 17:42, wrote:
>>> +/* enum struct keeping a table of all accepted parameter names
>>> + * for parsing cmd
>>> On 13.04.17 at 18:55, wrote:
> On 04/13/2017 11:46 AM, Jan Beulich wrote:
> On 03.04.17 at 18:50, wrote:
>>> While waiting for a lock we may want to periodically run some
>>> code. We could use spin_trylock() but since it doesn't take lock
>>> ticket it may take a long time until the lock
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the acc feature (thermal monitoring)
is indicated as not being present by special casing the related
cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for acc instead.
Sign
There is no need to set the same capabilities for each cpu
individually. This can be done for all cpus in platform initialization.
Cc: Alok Kataria
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Juergen
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the xsave feature availability is
indicated by special casing the related cpuid leaf.
Instead of delivering fake cpuid values set or clear the cpu
capability bits for xsave instead.
Signed-off-by: Juerge
There is no user of x86_hyper->set_cpu_features() any more. Remove it.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
arch/x86/include/asm/hypervisor.h | 5 -
arch/x86/kernel/cpu/common.c | 1
There is no need to set the same capabilities for each cpu
individually. This can easily be done for all cpus when starting the
kernel.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
arch/x86/xen/enlighten_pv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Reduce special casing of xen_cpuid() by using cpu capabilities instead
of faked cpuid nodes.
This cleanup enables us remove the hypervisor specific set_cpu_features
callback as the same effect can be reached via
setup_[clear|force]_cpu_cap().
Removing the rest faked nodes from xen_cpuid() require
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated
as not being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for aperf/mperf instead.
Signed-of
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the acpi feature is indicated as not
being present by special casing the related cpuid leaf in case we
are not the initial domain.
Instead of delivering fake cpuid values clear the cpu capability bit
for
Xen doesn't support DCA (direct cache access) for pv domains. Clear
the corresponding capability indicator.
Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
---
arch/x86/xen/enlighten_pv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/en
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the mwait feature is indicated to be
present or not by special casing the related cpuid leaf.
Instead of delivering fake cpuid values use the cpu capability bit
for mwait instead.
Signed-off-by: Juergen
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the mtrr feature is indicated as not
being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for mtrr instead.
Signed-off-by: Juergen
When running as pv domain xen_cpuid() is being used instead of
native_cpuid(). In xen_cpuid() the x2apic feature is indicated as not
being present by special casing the related cpuid leaf.
Instead of delivering fake cpuid values clear the cpu capability bit
for x2apic instead.
Signed-off-by: Juer
> From: Gao, Chao
> Sent: Monday, April 17, 2017 4:14 AM
>
> On Tue, Apr 11, 2017 at 02:21:07AM -0600, Jan Beulich wrote:
> On 11.04.17 at 02:59, wrote:
> >> As you know, with VT-d PI enabled, hardware can directly deliver external
> >> interrupts to guest without any VMM intervention. It wi
flight 107488 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail in 107371 REGR. vs. 107176
Tests which are f
On 14/04/17 19:52, Stefano Stabellini wrote:
> On Fri, 14 Apr 2017, Juergen Gross wrote:
>> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
>>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
>>>
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Friday, April 14, 2017 11:35 PM
>
> Hello,
>
> Although PVHv2 Dom0 is not yet finished, I've been trying the current code
> on
> different hardware, and found that with pre-Haswell Intel hardware PVHv2
> Dom0
> completely freezes the b
flight 107487 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are faili
On Mon, Apr 17, 2017 at 05:09:22PM +0100, Roger Pau Monne wrote:
>The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which
>means that all GSIs must belong to an IO APIC. This doesn't match reality,
>where there are systems with non-contiguous GSIs.
>
>In order to fix this add a b
flight 107486 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107486/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 11 guest-start fail REGR. vs. 59254
test-armhf-armhf-xl
flight 107485 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 107406
test-amd64-i386-xl-q
On Sat, Apr 15, 2017 at 1:45 AM, Razvan Cojocaru
wrote:
> This patch adds support for testing instruction emulation when
> required by the vm_event reply sent for MEM_ACCESS events. To this
> end, it adds the "emulate_write" and "emulate_exec" parameters
> that behave like the old "write" and "ex
On Apr 14, 2017, at 16:43, Daniel Kiper wrote:
>
>> On Fri, Apr 14, 2017 at 04:17:54PM +0100, Andrew Cooper wrote:
>>> On 14/04/2017 15:54, Daniel Kiper wrote:
>>> Hey,
>>>
>>> Has anybody tried to run EFI + tboot + Xen?
>>> I have a feeling that it does not work because
>>> tboot shuts down EFI
The POSIX spec specifies to use:
#include
instead of:
#include
as seen here:
http://pubs.opengroup.org/onlinepubs/009695399/functions/poll.html
This removes the warning:
#warning redirecting incorrect #include to
when building with the musl C-library.
Signed-off-by: Alistair F
The POSIX spec specifies to use:
#include
instead of:
#include
as seen here:
http://pubs.opengroup.org/onlinepubs/009695399/functions/signal.html
This removes the warning:
#warning redirecting incorrect #include to
when building with the musl C-library.
Signed-off-by: Alistair
Hi Jan,
I have a question about __initconst that you mentioned.
On 4/3/2017 6:55 AM, Jan Beulich wrote:
On 31.03.17 at 17:42, wrote:
The title needs improvement - it doesn't really reflect what the
patch does.
Add name=value parsing options for com1 and com2 to add flexibility
in setting r
The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec hypercall, which is
now protected at the top-level in do_kexec_op_internal(),
thus the local spinlock is no longer necessary.
Signed-off-by: Eric DeVolder
Reviewed-by: Bhavesh Davda
Reviewed-by: Konra
During testing (using the script below) we found that multiple
invocations of kexec of unload/load are not safe.
This does not exist in classic Xen kernels in which the kexec-tools
did the kexec via Linux kernel syscall (which in turn made the
hypercall), as the Linux code has a mutex_trylock whic
When we concurrently try to unload and load crash
images we eventually get:
Xen call trace:
[] machine_kexec_add_page+0x3a0/0x3fa
[] machine_kexec_load+0xdb/0x107
[] kexec.c#kexec_load_slot+0x11/0x42
[] kexec.c#kexec_load+0x119/0x150
[] kexec.c#do_kexec_op_internal+0xab/0xcf
flight 107483 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107483/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 107176
Tests which are f
The current vIO APIC for PVH Dom0 doesn't allow non-contiguous GSIs, which
means that all GSIs must belong to an IO APIC. This doesn't match reality,
where there are systems with non-contiguous GSIs.
In order to fix this add a base_gsi field to each hvm_vioapic struct, in order
to store the base G
>> +static const char * const tegra_dt_compat[] __initconst =
>> +{
>> +"nvidia,tegra120", /* Tegra K1 */
>
> This is still tegra120 (not tegra124), is that intended? If so, it is
> still missing from arch/arm*/boot/dts. Do you have a pointer?
It was not intended; thank you for catching it. I
On Fri, Mar 17, 2017 at 07:27:15PM +0800, Lan Tianyu wrote:
> From: Chao Gao
>
> When irq remapping enabled, IOAPIC Redirection Entry maybe is in remapping
> format. If that, generate a irq_remapping_request and send it to domain.
>
> Signed-off-by: Chao Gao
> Signed-off-by: Lan Tianyu
> ---
>
On Mon, Mar 20, 2017 at 02:23:02PM +, Roger Pau Monné wrote:
> On Fri, Mar 17, 2017 at 07:27:00PM +0800, Lan Tianyu wrote:
> > This patchset is to introduce vIOMMU framework and add virtual VTD's
> > interrupt remapping support according "Xen virtual IOMMU high level
> > design doc
> > V3"(htt
On Fri, Mar 17, 2017 at 07:27:04PM +0800, Lan Tianyu wrote:
> This patch is to add get_irq_info callback for platform implementation
> to convert irq remapping request to irq info (E,G vector, dest, dest_mode
> and so on).
>
> Signed-off-by: Lan Tianyu
> ---
> xen/common/viommu.c | 11 +
On Fri, Mar 17, 2017 at 07:27:03PM +0800, Lan Tianyu wrote:
> This patch is to add irq request callback for platform implementation
> to deal with irq remapping request.
>
> Signed-off-by: Lan Tianyu
> ---
> xen/common/viommu.c | 11 +++
> xen/include/asm-arm/viommu.h | 4
On Fri, Mar 17, 2017 at 07:27:02PM +0800, Lan Tianyu wrote:
> This patch is to introduce create, destroy and query capabilities
> command for vIOMMU. vIOMMU layer will deal with requests and call
> arch vIOMMU ops.
>
> Signed-off-by: Lan Tianyu
> ---
> xen/arch/x86/hvm/dm.c | 29 +++
Hello Jesus,
I would like to thank you for the comments. I will look into the part where
it uploads the data to the Elasticsearch index and the jwzthreading.py. I
believe that I had mentioned in one of the IRC chats that I would be
reusing the jwzthreading.py. I am sorry if I hadn't mentioned it.
On Mon, Apr 17, 2017 at 01:57:10PM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 01:47:47PM +0800, Chao Gao wrote:
>> On Mon, Apr 17, 2017 at 01:21:01PM +0100, Roger Pau Monné wrote:
>> >On Mon, Apr 17, 2017 at 01:12:27PM +0800, Chao Gao wrote:
>> >[...]
>> >> It works. I can test for you
This run is configured for baseline tests only.
flight 71199 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71199/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51a1db9b24d850c785d240da599c4bf9ba1c0fd3
baseline v
On Mon, Apr 17, 2017 at 01:47:47PM +0800, Chao Gao wrote:
> On Mon, Apr 17, 2017 at 01:21:01PM +0100, Roger Pau Monné wrote:
> >On Mon, Apr 17, 2017 at 01:12:27PM +0800, Chao Gao wrote:
> >[...]
> >> It works. I can test for you when you send out a formal patch.
> >
> >Thanks for the testing, will
On Mon, Apr 17, 2017 at 01:21:01PM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 01:12:27PM +0800, Chao Gao wrote:
>[...]
>> It works. I can test for you when you send out a formal patch.
>
>Thanks for the testing, will send formal patch shortly.
>
>Have you been able to reproduce the IOMM
Hey,
Over the week I built from scratch and installed Xen 4.9-rc1 on
Fedora Core 20.
I had one issue that I hadn't yet dug completely in - that is the
xenstored.service would not start. Invoking it manually made it
work.
But Fedora Core 20 is ancient, and I am planning to update that machine
to
flight 107482 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107482/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 107358
Tests which are faili
On Mon, Apr 17, 2017 at 01:12:27PM +0800, Chao Gao wrote:
[...]
> It works. I can test for you when you send out a formal patch.
Thanks for the testing, will send formal patch shortly.
Have you been able to reproduce the IOMMU issue with that, or you just hit the
panic at the end of PVH Dom0 buil
On Mon, Apr 17, 2017 at 11:38:33AM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 10:49:45AM +0800, Chao Gao wrote:
>> On Mon, Apr 17, 2017 at 09:38:54AM +0100, Roger Pau Monné wrote:
>> >On Mon, Apr 17, 2017 at 09:03:12AM +0800, Chao Gao wrote:
>> >> On Mon, Apr 17, 2017 at 08:47:48AM +010
On 2017年04月17日 19:08, Wei Liu wrote:
> On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote:
>> Hi Paul:
>> Sorry for later response.
>>
>> On 3/31/2017 3:57 AM, Chao Gao wrote:
>>> On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durrant wrote:
> -Original Message-
> From
flight 107480 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 3 host-install(3) broken REGR. vs. 59254
test-armhf-armhf-xl
On Fri, Apr 14, 2017 at 11:38:15PM +0800, Lan, Tianyu wrote:
> Hi Paul:
> Sorry for later response.
>
> On 3/31/2017 3:57 AM, Chao Gao wrote:
> > On Wed, Mar 29, 2017 at 09:08:06AM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Xen-devel [mailto:xen-devel-boun...
flight 107481 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107481/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail pass in
107468
Regressions which are regar
On Mon, Apr 17, 2017 at 10:49:45AM +0800, Chao Gao wrote:
> On Mon, Apr 17, 2017 at 09:38:54AM +0100, Roger Pau Monné wrote:
> >On Mon, Apr 17, 2017 at 09:03:12AM +0800, Chao Gao wrote:
> >> On Mon, Apr 17, 2017 at 08:47:48AM +0100, Roger Pau Monné wrote:
> >> >On Mon, Apr 17, 2017 at 07:32:45AM +0
flight 107484 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107484/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51a1db9b24d850c785d240da599c4bf9ba1c0fd3
baseline version:
ovmf 0c9fc4b1679946f59efa1
On Mon, Apr 17, 2017 at 09:38:54AM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 09:03:12AM +0800, Chao Gao wrote:
>> On Mon, Apr 17, 2017 at 08:47:48AM +0100, Roger Pau Monné wrote:
>> >On Mon, Apr 17, 2017 at 07:32:45AM +0800, Chao Gao wrote:
>> >> On Fri, Apr 14, 2017 at 04:34:41PM +010
flight 71198 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71198/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start fail like 71167
test-amd64-amd64-i3
On Sun, 2017-04-16 at 21:26 -0700, Heather Booker wrote:
> Hi Jesus!
>
> I appreciate the info on the unicode error. I might have missed it,
> but I also asked about the general microtask specifications. Here
> was my original inquiry:
> > And to clarify, my understanding is that the final result
On Mon, Apr 17, 2017 at 09:03:12AM +0800, Chao Gao wrote:
> On Mon, Apr 17, 2017 at 08:47:48AM +0100, Roger Pau Monné wrote:
> >On Mon, Apr 17, 2017 at 07:32:45AM +0800, Chao Gao wrote:
> >> On Fri, Apr 14, 2017 at 04:34:41PM +0100, Roger Pau Monné wrote:
> >> >Hello,
> >> >
> >> >Although PVHv2 Do
On Mon, Apr 17, 2017 at 08:47:48AM +0100, Roger Pau Monné wrote:
>On Mon, Apr 17, 2017 at 07:32:45AM +0800, Chao Gao wrote:
>> On Fri, Apr 14, 2017 at 04:34:41PM +0100, Roger Pau Monné wrote:
>> >Hello,
>> >
>> >Although PVHv2 Dom0 is not yet finished, I've been trying the current code
>> >on
>> >
On Mon, Apr 17, 2017 at 07:32:45AM +0800, Chao Gao wrote:
> On Fri, Apr 14, 2017 at 04:34:41PM +0100, Roger Pau Monné wrote:
> >Hello,
> >
> >Although PVHv2 Dom0 is not yet finished, I've been trying the current code on
> >different hardware, and found that with pre-Haswell Intel hardware PVHv2 Dom
On Mon, Apr 10, 2017 at 02:34:35PM +0100, Roger Pau Monne wrote:
> clang doesn't understand the "=A" register constrain when used with 64bits
> assembly and spits out an internal error:
>
> fatal error: error in backend: Cannot select: 0x7f9fb89c9390: i64 =
> build_pair 0x7f9fb89c92b0,
> 0x
60 matches
Mail list logo
