>>> On 09.03.16 at 19:46, wrote:
> On 09/03/16 15:23, Jan Beulich wrote:
>>
>> And there's a second issue here: map_pages_to_xen() updates
>> the idle page tables, only part of which is actually in use on a
>> huge machine in the context of a PV guest, so the above is also
>> risking a #PF on a g
This reverts an unintended change in commit 879b44b041 ("x86/fpu: add
a per-domain field to set the width of FIP/FDP"), which I had done
intermediately while fixing the build issue: After having reverted that
adjustment I must have forgotten to "git add" the adjustment.
Signed-off-by: Jan Beulich
flight 85818 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85818/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 3 host-install(3)broken REGR. vs. 85758
test-amd64-amd64-am
CC Kevin,
On March 09, 2016 11:00pm, wrote:
> On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> > pcidevs_lock should be held with interrupt enabled.
> >
> There's a message from Jan when he says:
> < disabled while being acquired".>>
>
> :-O
>
> > However there remains
> > an exception in A
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Wednesday, March 09, 2016 11:08 PM
>
> Hi,
>
> > +/* Here we just expose minimal host bridge offset subset. */
> > +static const IGDHostInfo igd_host_bridge_infos[] = {
> > +{0x08, 2}, /* revision id */
> > +{0x2c, 2}, /* sybsys
On March 09, 2016 10:45pm, Dario Faggioli wrote:
> On Wed, 2016-03-09 at 06:55 -0700, Jan Beulich wrote:
> > >
> > > > > On 09.03.16 at 14:46, wrote:
> > > Now I am still not clear for this point- "this inconsistency might
> > > lead to deadlock".
> > > I think it is similar to 'mixing interrupt d
An error occurring when calling "xl cpupool-cpu-remove" might leave
the system in a state where a cpu is neither completely free nor in
a cpupool. This can easily be repaired by adding the cpu via
"xl cpupool-cpu-add" to the cpupool where it was removed from before.
Print a message telling this the
In order to be able to undo a vcpu pin override in case of a kernel
driver error add a flag "-f" to the "xl vcpu-pin" command forcing the
hypervisor to undo the override.
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Wei Liu
Signed-off-by: Juergen Gross
---
V4: - change "force" variable to bool a
Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be
called on physical cpu 0 only. Linux drivers like dcdbas or i8k try
to achieve this by pinning the running thread to cpu 0, but in Dom0
this is not enough: the vcpu must be pinned to physical cpu 0 via
Xen, too.
This patch series enh
The hypervisor might return EBUSY when trying to remove a cpu from a
cpupool when a domain running in this cpupool has pinned a vcpu
temporarily. Do some retries in this case, perhaps the situation
cleans up.
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Wei Liu
Signed-off-by: Juergen Gross
---
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: Thursday, March 10, 2016 12:23 AM
>
> [Changing the subject and CC'ing more people]
>
> On 09/03/16 13:39, Jan Beulich wrote:
> On 08.03.16 at 19:38, wrote:
> >> If I may go "meta" for a moment here -- this is exactly what I'm
Hi Dushyant,
On 09/03/2016 20:37, Wei Liu wrote:
On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
I'm working on a research project with IBM, and I want to run Xen on Nvidia
Tegra Jetson-tk1 board.
I looked at a post on this mailing list (http://lists.xenproject.org/archives/
ht
flight 85813 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85813/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
flight 85805 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 3 host-install(3) broken REGR. vs. 83004
build-armhf-pvops
flight 85802 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85802/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
On Wed, Mar 9, 2016 at 10:46 AM, Dario Faggioli
wrote:
> On Tue, 2016-03-08 at 23:33 -0500, Meng Xu wrote:
>> I didn't mark out all repeated style issues. I think you can correct
>> all of the style issues, such as the spaces in the code, in the next
>> version.
>>
> Yes, please. At v7, style issu
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenb
On 03/09/16 09:17, Jan Beulich wrote:
> >>> On 09.03.16 at 13:22, wrote:
> > On 03/08/16 02:27, Jan Beulich wrote:
> >> >>> On 08.03.16 at 10:15, wrote:
[...]
> > I should reexplain the choice of data structures and where to put them.
> >
> > For handling MCE for NVDIMM, we need to track followi
On March 09, 2016 9:56pm, wrote:
> >>> On 09.03.16 at 14:46, wrote:
> > Now I am still not clear for this point- "this inconsistency might
> > lead to deadlock".
> > I think it is similar to 'mixing interrupt disabled and enabled
> > spinlocks is something we disallow'.
> > I hope you can give me
On 3/9/16 4:09 PM, Daniel De Graaf wrote:
> On 03/09/2016 04:17 PM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Mar 09, 2016 at 01:24:15PM +, Andrew Cooper wrote:
>>> On 09/03/16 01:51, Konrad Rzeszutek Wilk wrote:
Hey,
I was wondering if it we should change the default flask_bootpar
On March 10, 2016 1:45am, wrote:
> On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> > Signed-off-by: Quan Xu
> > Acked-by: Kevin Tian
> >
> Reviewed-by: Dario Faggioli
>
> And I've applied and build tested it, against current staging, and this time,
> it
> worked. :-)
>
Dario, thanks!! :
> -Original Message-
> From: David Vrabel [mailto:david.vra...@citrix.com]
> Sent: Thursday, March 10, 2016 2:02 AM
> To: George Dunlap ; Jan Beulich
>
> Cc: Andrew Cooper ; Dario Faggioli
> ; George Dunlap ;
> Wu, Feng ; Tian, Kevin ; xen-
> de...@lists.xen.org; Konrad Rzeszutek Wilk ;
Hello Ian, Stefano,
I believe there is a bug in setup_frametable_mappings() where the function
allocates pages for pagetables via alloc_boot_pages() but does not zero them
out. This results in a crash on Qualcomm systems when prefetching is enabled
since the processor is free to prefetch a location
flight 85790 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85790/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 85731
build-i386-rumpuserxen
On 03/09/2016 04:17 PM, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 09, 2016 at 01:24:15PM +, Andrew Cooper wrote:
On 09/03/16 01:51, Konrad Rzeszutek Wilk wrote:
Hey,
I was wondering if it we should change the default flask_bootparam
option from permissive to disabled?
The reason being is t
This run is configured for baseline tests only.
flight 44235 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44235/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-amd 3 host-inst
On Wed, Mar 9, 2016 at 11:28 AM, Dario Faggioli
wrote:
> On Tue, 2016-03-08 at 19:12 +, Wei Liu wrote:
>
>> Overall I think the patch is moving towards the right direction.
>>
> I also think so. Thanks a lot Wei for the review, BTW.
>
>> Just
>> that there are too many places where indentation
flight 85838 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85838/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On Wed, Mar 09, 2016 at 01:24:15PM +, Andrew Cooper wrote:
> On 09/03/16 01:51, Konrad Rzeszutek Wilk wrote:
> > Hey,
> >
> > I was wondering if it we should change the default flask_bootparam
> > option from permissive to disabled?
> >
> > The reason being is that I was startled to see that my
> On 9 Mar 2016, at 17:06, Daniel Izquierdo wrote:
>
> On 02/03/16 23:45, Daniel Izquierdo wrote:
>
> [...]
>>> Given, that the Xen-A1.A2.A3 dash board is quite busy, we should keep that
>>> separate.
>>>
>>>
>>>
>>
>> I still have to upload this, sorry for the delay!
>>
>>
>> This is a
flight 85776 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85776/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
On Wed, Mar 09, 2016 at 07:03:15PM +, Andrew Cooper wrote:
> The foreign header generation blindly replaces 'uint64_t' with '__align8__
> uint64_t', to get correct alignment when built as 32bit. This is correct in
> most circumstances, but Clang objects to two specific uses.
>
> * Inside a s
On Wed, Mar 09, 2016 at 07:03:16PM +, Andrew Cooper wrote:
> Fixes a build failure with Clang.
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
> ---
> CC: Ian Jackson
> CC: Wei Liu
>
> New in v2
> ---
> tools/misc/gtracestat.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --g
flight 85827 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85827/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85661
Tests which di
Fixes a build failure with Clang.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
New in v2
---
tools/misc/gtracestat.c | 4
1 file changed, 4 deletions(-)
diff --git a/tools/misc/gtracestat.c b/tools/misc/gtracestat.c
index 3c2bd2c..67cb003 100644
--- a/tools/misc/gtracest
The foreign header generation blindly replaces 'uint64_t' with '__align8__
uint64_t', to get correct alignment when built as 32bit. This is correct in
most circumstances, but Clang objects to two specific uses.
* Inside a sizeof() expression
* As part of a typecast
An example error looks like:
Introduce the FLUSH_CACHE_BY_VA flag to flush_area_mask() and friends
to say that it is safe to use CLFLUSH (i.e., the virtual address is
still valid).
Use this when changing the cachability of the Xen direct mappings (in
response to the guest changing the cachability of its mappings). This
signif
On 09/03/16 15:23, Jan Beulich wrote:
>
> And there's a second issue here: map_pages_to_xen() updates
> the idle page tables, only part of which is actually in use on a
> huge machine in the context of a PV guest, so the above is also
> risking a #PF on a guest address for the CLFLUSH. Setting the
On 09/03/16 16:23, George Dunlap wrote:
>
> I don't know why this is controversial -- this seems obvious to me.
> What do other committers / maintainers think?
I started on a reply to this but then I went back and read the original
thread...
+/*
+ * XXX: The length of the list depends on
On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> Signed-off-by: Quan Xu
> Acked-by: Kevin Tian
>
Reviewed-by: Dario Faggioli
And I've applied and build tested it, against current staging, and this
time, it worked. :-)
Regards,
Dario
--
<> (Raistlin Majere)
-
On Tue, 2016-03-08 at 19:12 +, Wei Liu wrote:
> Overall I think the patch is moving towards the right direction.
>
I also think so. Thanks a lot Wei for the review, BTW.
> Just
> that there are too many places where indentation need fixing. Please
> fix them in the next iteration. I really
flight 85819 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85661
Tests which di
On Wed, 2016-03-09 at 18:09 +0100, Dario Faggioli wrote:
> While fiddling with the Cc-list, can you please try to arrange things
> in such a way that each person is Cc-ed only to the subset of the
> series that he would reasonably care about.
>
> For instance, Jan is likely not going to look at li
On the whole series, you are Cc-ing ian.campb...@eu.citrix.com, which
is no longer a tools maintainer.
Please, double check by looking at MAINTAINERS and/or with
./scripts/get_maintainer.pl.
While fiddling with the Cc-list, can you please try to arrange things
in such a way that each person is Cc
On 02/03/16 23:45, Daniel Izquierdo wrote:
[...]
Given, that the Xen-A1.A2.A3 dash board is quite busy, we should keep
that separate.
I still have to upload this, sorry for the delay!
This is a summary of the actions unless extra comments are provided:
* Balance should be calculated as
On 03/03/16 19:55, Lars Kurth wrote:
Daniel, (added Jan - search for @Jan)
thanks for the feedback
On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote:
On 01/03/16 18:04, Lars Kurth wrote:
Daniel, Jesus,
I am going to break my comments down into different sections to make this more
consumable
>>> On 09.03.16 at 17:23, wrote:
> [Changing the subject and CC'ing more people]
>
> On 09/03/16 13:39, Jan Beulich wrote:
> On 08.03.16 at 19:38, wrote:
>>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>>> about with "Something bad may happen" being difficult to
>>> On 09.03.16 at 17:52, wrote:
> On Tue, Mar 08, 2016 at 01:48:05AM -0700, Jan Beulich wrote:
>> >>> On 07.03.16 at 23:04, wrote:
>> > Hmm, if it was some other PCI based serial card like:
>> >
>> > 01:05.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O
>> > Controller (rev 01) (prog-
On Tue, Mar 08, 2016 at 09:09:20PM -0500, Konrad Rzeszutek Wilk wrote:
> > Furthermore, I think coming up with a story for PV-aware guests (PVHVM,
> > PV and PVH) is also non-trivial. For one the disk replication logic is
>
> Pls keep in mind that PV guests can use QEMU qdisk if they wish.
>
Oh
On Tue, Mar 08, 2016 at 01:48:05AM -0700, Jan Beulich wrote:
> >>> On 07.03.16 at 23:04, wrote:
> >> +[param_pericom_4port] = {
> >> +.base_baud = 921600,
> >> +.uart_offset = 8,
> >> +.reg_width = 1,
> >> +.fifo_size = 16,
> >> +.lsr_mask = UART_LSR_TH
>>> On 09.03.16 at 17:10, wrote:
> On Tue, 2016-03-08 at 19:09 +, Wei Liu wrote:
>> On Sun, Mar 06, 2016 at 11:55:55AM -0600, Chong Li wrote:
>>
>> > +spin_lock_irqsave(&prv->lock, flags);
>> > +svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
>> > +svc->period
>>> On 09.03.16 at 17:01, wrote:
> On 09/03/16 13:39, Jan Beulich wrote:
> On 08.03.16 at 19:38, wrote:
>>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>>> about with "Something bad may happen" being difficult to work with.
>>> Rather than you spelling out exactly
On 08/03/16 15:30, Malcolm Crossley wrote:
> Nested hap code assumed implict bitmask semantics of the p2m_access_t
> enum prior to C/S 4c63692d7c38c5ac414fe97f8ef37b66e05abe5c
>
> The change to the enum ordering broke this assumption and caused functional
> problems for the nested hap code. As it
George,
Thank you for all the information. I'll take a dive in and see what I can see.
I'd at least like to get the CPU core frequency detection in as that will
make things a lot easier for us as we port to multiple platforms with
different cores. Then we don't have to keep looking up core speeds.
Paul,
>see the patch attached. It's a bit dirty still (that's why it wasn't
>upstreamed
>long time ago), but you can obviously look through it and gain some
>information.
Thanks, I’ll take a look and compare it against
mine to make sure we capture everything.
Ben
Hi all
I picked up Ian Campbell's work on introducing a set of stable
libraries that can be used by user space programs. The latest one is
libxendevicemodel which is designed to be used by, well, device model.
The last obstacle for it (without PCI passthrough support) is
video ram handling.
I tho
[Changing the subject and CC'ing more people]
On 09/03/16 13:39, Jan Beulich wrote:
On 08.03.16 at 19:38, wrote:
>> If I may go "meta" for a moment here -- this is exactly what I'm talking
>> about with "Something bad may happen" being difficult to work with.
>> Rather than you spelling out
>>> On 09.03.16 at 13:22, wrote:
> On 03/08/16 02:27, Jan Beulich wrote:
>> >>> On 08.03.16 at 10:15, wrote:
>> > More thoughts on reserving NVDIMM space for per-page structures
>> >
>> > Currently, a per-page struct for managing mapping of NVDIMM pages may
>> > include following fields:
>> >
>
On Tue, 2016-03-08 at 19:09 +, Wei Liu wrote:
> On Sun, Mar 06, 2016 at 11:55:55AM -0600, Chong Li wrote:
>
> > +spin_lock_irqsave(&prv->lock, flags);
> > +svc = rt_vcpu(d->vcpu[local_sched.vcpuid]);
> > +svc->period = period;
> > +svc->budget =
On 09/03/16 13:39, Jan Beulich wrote:
On 08.03.16 at 19:38, wrote:
>> Still -- I have a hard time constructing in my mind a scenario where
>> huge numbers of idle vcpus for some reason decide to congregate on a
>> single pcpu.
>>
>> Suppose we had 1024 pcpus, and 1023 VMs each with 5 vcpus, o
On Tue, 2016-03-08 at 23:33 -0500, Meng Xu wrote:
> I didn't mark out all repeated style issues. I think you can correct
> all of the style issues, such as the spaces in the code, in the next
> version.
>
Yes, please. At v7, style issues shouldn't definitely be there any
longer.
Have another look
flight 85758 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85758/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 85694 pass
in 85758
test-amd64-i386-xl-qemuu-
Thank you so much but it need programming?
On Wednesday, March 9, 2016 5:02 PM, Wei Liu wrote:
Hello
On Tue, Mar 08, 2016 at 03:22:32PM +, Jason Long wrote:
> Hello.
> How can I test Xen and report bug? Can it need programming?
>
Thanks for you enthusiasm. I don't think knowing how to pr
>>> On 09.03.16 at 15:52, wrote:
On 09.03.16 at 15:36, wrote:
>> On 09/03/16 14:01, Jan Beulich wrote:
>> On 08.03.16 at 19:44, wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5641,7 +5641,7 @@ int map_pages_to_xen(
flush_flags |= FLUSH_TLB_GLOBAL
Hi,
> +/* Here we just expose minimal host bridge offset subset. */
> +static const IGDHostInfo igd_host_bridge_infos[] = {
> +{0x08, 2}, /* revision id */
> +{0x2c, 2}, /* sybsystem vendor id */
> +{0x2e, 2}, /* sybsystem id */
Can anyone clarify where this comes from?
Setting
On Wed, 2016-03-09 at 21:17 +0800, Quan Xu wrote:
> pcidevs_lock should be held with interrupt enabled.
>
There's a message from Jan when he says:
<>
:-O
> However there remains
> an exception in AMD IOMMU code, where the lock is acquired with
> interrupt
> disabled. This inconsistency might lea
>>> On 09.03.16 at 15:36, wrote:
> On 09/03/16 14:01, Jan Beulich wrote:
> On 08.03.16 at 19:44, wrote:
>>> --- a/xen/arch/x86/flushtlb.c
>>> +++ b/xen/arch/x86/flushtlb.c
>>> @@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
>>> if ( order < (B
On Wed, 2016-03-09 at 06:55 -0700, Jan Beulich wrote:
> >
> > > > On 09.03.16 at 14:46, wrote:
> > Now I am still not clear for this point- "this inconsistency might
> > lead to
> > deadlock".
> > I think it is similar to 'mixing interrupt disabled and enabled
> > spinlocks is
> > something we
On 09/03/16 14:01, Jan Beulich wrote:
On 08.03.16 at 19:44, wrote:
>> --- a/xen/arch/x86/flushtlb.c
>> +++ b/xen/arch/x86/flushtlb.c
>> @@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>> if ( order < (BITS_PER_LONG - PAGE_SHIFT) )
>>
>>> On 09.03.16 at 12:19, wrote:
> On 08/03/16 07:57, Jan Beulich wrote:
@@ -174,10 +174,43 @@ compat_bad_hypercall:
/* %rbx: struct vcpu, interrupts disabled */
ENTRY(compat_restore_all_guest)
ASSERT_INTERRUPTS_DISABLED
+.Lcr4_orig:
+ASM_NOP3 /* mo
>>> On 09.03.16 at 09:09, wrote:
>> >> +/* This mustn't modify registers other than %rax. */
>> >> +ENTRY(cr4_smep_smap_restore)
>> >> +mov %cr4, %rax
>> >> +test $X86_CR4_SMEP|X86_CR4_SMAP,%eax
>> >> +jnz 0f
>
> If we clear every place where we are back to 32bit pv g
I saw quite a few coding style issues. Please fix them in next
iteration.
On Sun, Mar 06, 2016 at 11:55:58AM -0600, Chong Li wrote:
[...]
>
> -if (cpupool && (dom || opt_p || opt_b)) {
> +if (cpupool && (dom || opt_p || opt_b || opt_v || opt_all)) {
> fprintf(stderr, "Specifying
flight 85763 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
>>> On 09.03.16 at 09:09, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, March 4, 2016 7:28 PM
>> @@ -1471,7 +1475,10 @@ void __init noreturn __start_xen(unsigne
>> * copy_from_user().
>> */
>> if ( cpu_has_smap )
>> +{
>> +cr4_smep_smap_mask &
>>> On 09.03.16 at 11:45, wrote:
> On 09/03/16 08:09, Wu, Feng wrote:
>
>>> --- a/xen/arch/x86/x86_64/entry.S
>>> +++ b/xen/arch/x86/x86_64/entry.S
>>> @@ -434,6 +434,7 @@ ENTRY(dom_crash_sync_extable)
>>>
>>> ENTRY(common_interrupt)
>>> SAVE_ALL CLAC
>>> +SMEP_SMAP_RESTORE
>>>
On Tue, Mar 08, 2016 at 03:24:35PM -0600, Chong Li wrote:
[...]
> >> +case 'v':
> >> +if (!strcmp(optarg, "all")) { /* get or set all vcpus of a domain
> >> */
> >> +opt_all = 1;
> >> +break;
> >> +}
> >> +if (v_index >= v_size) { /* vcpus array
On Tue, Mar 08, 2016 at 06:38:54PM -0600, Chong Li wrote:
> >> +if (scinfo->num_vcpus > 0) {
> >> +num_vcpus = scinfo->num_vcpus;
> >> +GCNEW_ARRAY(vcpus, num_vcpus);
> >> +for (i = 0; i < num_vcpus; i++) {
> >> +if (scinfo->vcpus[i].vcpuid < 0 ||
> >> +
>>> On 08.03.16 at 19:44, wrote:
> --- a/xen/arch/x86/flushtlb.c
> +++ b/xen/arch/x86/flushtlb.c
> @@ -140,7 +140,8 @@ unsigned int flush_area_local(const void *va, unsigned
> int flags)
> if ( order < (BITS_PER_LONG - PAGE_SHIFT) )
> sz = 1UL << (order + PAGE_SHIFT);
>
>
>>> On 09.03.16 at 14:46, wrote:
> Now I am still not clear for this point- "this inconsistency might lead to
> deadlock".
> I think it is similar to 'mixing interrupt disabled and enabled spinlocks is
> something we disallow'.
> I hope you can give me an example about how to lead to deadlock.
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, March 09, 2016 9:20 PM
> To: Xu, Quan
> Cc: Suravee Suthikulpanit; xen-devel@lists.xen.org; Jan Beulich; Tian, Kevin
> Subject: Re: [Xen-devel] [PATCH v2 1/2] IOMMU/spinlock: Fix a bug found
Processing commands for x...@bugs.xenproject.org:
> graft 53 !
Graft `<20160309133517.gc2...@citrix.com>' onto #53
> thanks
Finished processing.
Modified/created Bugs:
- 53: http://bugs.xenproject.org/xen/bug/53
---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_
flight 85777 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85777/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 85689
test-armhf-armhf-libvirt
On 09/03/16 13:35, Wu, Feng wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, March 9, 2016 8:37 PM
>> To: andrew.coop...@citrix.com; Wu, Feng ; xen-
>> de...@lists.xenproject.org
>> Cc: k...@xen.org
>> Subject: Re: [PATCH 2/4] x86: suppress
>>> On 09.03.16 at 13:33, wrote:
> On Wed, Mar 09, 2016 at 03:25:58AM -0700, Jan Beulich wrote:
>> Btw., one more thing: Can't the exclusion of FP and SSE states in the logic
>> determining which state set to save be extended to also include YMM? If
> saved,
>> YMM will also always live at a fixe
>>> On 08.03.16 at 19:38, wrote:
> Still -- I have a hard time constructing in my mind a scenario where
> huge numbers of idle vcpus for some reason decide to congregate on a
> single pcpu.
>
> Suppose we had 1024 pcpus, and 1023 VMs each with 5 vcpus, of which 1
> was spinning at 100% and the ot
CC ARM maintainers
On Tue, Mar 08, 2016 at 08:23:29AM +, Dushyant K Behl wrote:
> Hi All,
>
> I'm working on a research project with IBM, and I want to run Xen on Nvidia
> Tegra Jetson-tk1 board.
> I looked at a post on this mailing list (http://lists.xenproject.org/archives/
> html/xen-deve
graft 53 !
thanks
Post this message to xen-devel so that bug tracker can pick it up.
On Mon, Mar 07, 2016 at 10:38:47AM +1000, John Thomson wrote:
> Hi,
>
> I am encountering an error compiling Xen (4.6.1) in configuring
> stubdom/gmp on x86_64 Arch Linux.
> I think it may be due to the system's
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, March 9, 2016 8:37 PM
> To: andrew.coop...@citrix.com; Wu, Feng ; xen-
> de...@lists.xenproject.org
> Cc: k...@xen.org
> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> gu
Obviously the subject should not have contained an internal ticket
reference.
Please remove before committing or, if preferred, I can resend.
David
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hello
On Tue, Mar 08, 2016 at 03:22:32PM +, Jason Long wrote:
> Hello.
> How can I test Xen and report bug? Can it need programming?
>
Thanks for you enthusiasm. I don't think knowing how to program is a
must-have for testing Xen (or any software in general). What is needed
is the ability to
Processing commands for x...@bugs.xenproject.org:
> create ^
Created new bug #53 rooted at
`<1457311127.3237075.541322218.485cf...@webmail.messagingengine.com>'
Title: `Re: [Xen-users] Error compiling Xen in configuring stubdom/gmp with
glibc-2.23 on Arch Linux'
> thanks
Finished processing.
Mo
On 09/03/16 01:51, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I was wondering if it we should change the default flask_bootparam
> option from permissive to disabled?
>
> The reason being is that I was startled to see that my xSplice
> code was able to patch the hypervisor from within an PV guest!
>
>
Signed-off-by: Quan Xu
Acked-by: Kevin Tian
CC: Keir Fraser
CC: Jan Beulich
CC: Andrew Cooper
CC: Suravee Suthikulpanit
CC: Feng Wu
CC: Kevin Tian
CC: Dario Faggioli
---
xen/arch/x86/domctl.c | 8 +--
xen/arch/x86/hvm/vmsi.c | 4 +-
xen/arch/x86
pcidevs_lock should be held with interrupt enabled. However there remains
an exception in AMD IOMMU code, where the lock is acquired with interrupt
disabled. This inconsistency might lead to deadlock.
The fix is straightforward to use spin_lock instead. Also interrupt has been
enabled when this fu
On Wed, 2016-03-09 at 12:52 +, Xu, Quan wrote:
> On March 09, 2016 6:25pm, wrote:
> > On Wed, 2016-03-09 at 07:31 +, Xu, Quan wrote:
> > > On March 09, 2016 1:19pm, wrote:
> > > >
> > If we are absolutely sure that they are enabled, i.e., there is no
> > _risk_ that they
> > are disabled
This patch set makes the pcidevs_lock a recursive one. It is a prereq
patch set for Patch:'VT-d Device-TLB flush issue', as the pcidevs_lock
may be recursively held for hiding the ATS device, when VT-d Device-TLB
flush timed out.
In detail:
1. Fix a bug found in AMD IOMMU initialization.
pcid
flight 85775 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
If an architecture does not provide a custom page_list_entry, default
page_list_* helpers are provided, wrapping list_head as an underlying type for
page_list_head.
The two declarations of the page_list_* helpers differ between defines and
static inline functions, where the defines discard some of
common/page_alloc.c references d->arch.relmem_list, which only exists on x86.
This only compiles on ARM because page_list_del2() discards its second
argument.
Introduce a new common arch_free_heap_page() which only uses common lists in
struct domain, and allow an architecture to override this with
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, March 9, 2016 8:37 PM
> To: andrew.coop...@citrix.com; Wu, Feng ; xen-
> de...@lists.xenproject.org
> Cc: k...@xen.org
> Subject: Re: [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV
> gu
1 - 100 of 132 matches
Mail list logo
