flight 44422 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44422/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 4 capture-logs !broken
On 17/05/2016 07:40, Wei Chen wrote:
Hi Julien,
Hi Wei,
Please avoid top-posting on the mailing list.
This code looks good to me.
Thank you for the review.
Reviewed-by: Wei Chen
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-dev
>>> On 16.05.16 at 16:28, wrote:
> It has been a while without any ARM backport request. Ian Campbell
> used to keep a list of backport fixes for Xen ARM and apply them
> to stable. Now that he left, I am not sure who will do it.
>
> I would be fine to keep the list of patches, although I am not
On 17/05/16 06:28, Ed Swierk wrote:
> I'm trying to figure out a crash when booting a Linux 4.4 dom0 on
> a recent stable xen 4.5. I'm capping the dom0 memory by setting
> dom0_mem=18432M,max:18432M on the xen command line, and the kernel
> config has CONFIG_XEN_BALLOON unset.
>
> The crash seems
Hi Jan,
On 17/05/2016 08:38, Jan Beulich wrote:
xen/arm: Force broadcast of TLB and instruction cache maintenance
instructions
commit e2faa286faa36da36ee14f6bc973043013001724
up to Xen 4.4
For both of those please note that 4.4 is in security-only
maintenance mode, and hence shouldn't be getti
>>> On 17.05.16 at 05:19, wrote:
>> From: Xu, Quan
>> Sent: Monday, May 16, 2016 11:26 PM
>>
>> On May 13, 2016 11:28 PM, Jan Beulich wrote:
>> > >>> On 22.04.16 at 12:54, wrote:
>> > > --- a/docs/misc/xen-command-line.markdown
>> > > +++ b/docs/misc/xen-command-line.markdown
>> > > @@ -1532,6
>>> On 13.05.16 at 18:29, wrote:
> On Fri, May 13, 2016 at 10:12 AM, Jan Beulich wrote:
> On 13.05.16 at 17:31, wrote:
>>> On Fri, May 13, 2016 at 9:09 AM, Jan Beulich wrote:
>>> On 13.05.16 at 16:50, wrote:
> On Fri, May 13, 2016 at 6:00 AM, Jan Beulich wrote:
> On 12.05.
flight 94500 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94500/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
flight 94498 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94498/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3fe37de
baseline version:
ovmf 5ac96e3a28dd26eabee421919f67fa7c443
>>> On 16.05.16 at 12:49, wrote:
> * Abstract (X86_CR4_SMEP | X86_CR4_SMAP) behind XEN_CR4_PV32_BITS to avoid
>opencoding the invidial bits which are fixed up behind a 32bit PV guests
>back.
> * In the debug case, perform the the AND and CMP on 64bit values rather than
>32bit values,
>>> On 16.05.16 at 17:40, wrote:
> On Mon, 16 May 2016, Julien Grall wrote:
>> It has been a while without any ARM backport request. Ian Campbell
>> used to keep a list of backport fixes for Xen ARM and apply them
>> to stable. Now that he left, I am not sure who will do it.
>>
>> I would be fine
>>> On 16.05.16 at 17:00, wrote:
> Actually I did that, but the policy is not loaded at all. 'xl list -Z' show
> no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0' is
> ingnored during booting. (the policy file is moved to the same directory as
> xen.cfg)
If you suspect it t
>>> On 16.05.16 at 18:59, wrote:
> In general, Invariant TSC is not a feature which can be advertised to guests,
> because it cannot be guaranteed across migrate. domain_cpuid() goes so far as
> to deliberately clobber the feature flag under a number of circumstances.
>
> Because ITSC is absent
>>> On 16.05.16 at 05:41, wrote:
> I also met this problem when passthrough 82599 to domU by SRIOV, and the
> call stack as follows:
> (XEN) Xen call trace:
> (XEN)[] panic+0xc3/0x1a0
> (XEN)[] symbols_lookup+0x22/0x2a0
> (XEN)[] syscall_enter+0x88/0x8d
> (XEN)[] syscall_enter+0x8
I should add the xsm=policy option to the end of the xen.cfg instead of as
an option. Sorry for the fault.
However, another problem is that when I modified the policy and reload it
using '*xl loadpolicy*', the policy seemed not working.
The policy I add is *'allow domU_t security_t:security check
>>> On 16.05.16 at 11:29, wrote:
> On 16/05/16 10:24, Wei Liu wrote:
>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>>> flight 94442 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/94442/
>> [...]
>>> test-amd64-i386-qemuu-rhel6hvm-intel
Hi Julien,
On 17 May 2016 at 00:30, Julien Grall wrote:
> Hi Wei,
>
>
> On 16/05/16 16:47, Wei Liu wrote:
>>
>> On Mon, May 16, 2016 at 05:03:54PM +0200, Edgar E. Iglesias wrote:
>>>
>>> From: "Edgar E. Iglesias"
>>>
>>> I'm sending this as a v2 considering that I previously posted a diff
>>> in
On 17/05/16 09:59, Jan Beulich wrote:
On 16.05.16 at 11:29, wrote:
>> On 16/05/16 10:24, Wei Liu wrote:
>>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
flight 94442 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94442/
>>> [...]
hi all
i have two question about xl migrate
write_batch
120 for ( i = 0; i < nr_pfns; ++i )
121 {
122 types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx,
123
ctx->save.batch_pfns[i]);
124
125 /* Likely a ballooned page
>>> On 17.05.16 at 10:59, wrote:
On 16.05.16 at 11:29, wrote:
>> On 16/05/16 10:24, Wei Liu wrote:
>>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
flight 94442 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94442/
>>> [...]
>>>
>>> On 17.05.16 at 11:01, wrote:
> On 17/05/16 09:59, Jan Beulich wrote:
> On 16.05.16 at 11:29, wrote:
>>> On 16/05/16 10:24, Wei Liu wrote:
On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
> flight 94442 xen-unstable real [real]
> http://logs.test-lab.xenp
On Sun, May 15, 2016 at 5:11 AM, Tony S wrote:
> Hi all,
>
> When I was running latency-sensitive applications in VMs on Xen, I
> found some bugs in the credit scheduler which will cause long tail
> latency in I/O-intensive VMs.
>
>
> (1) Problem description
>
> Description
On Mon, May 16, 2016 at 11:33 PM, Boris Ostrovsky
wrote:
> On 05/16/2016 05:38 PM, Tony S wrote:
>> The issue behind it is that the process execution calculation(e.g.,
>> delta_exec) in virtualized environment should not be calculated as it
>> did in physical enviroment.
>>
>> Here are two solutio
flight 94495 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 5 xen-install fail REGR. vs. 94487
Regressions which ar
On 17/05/16 10:01, Zhang, Chunyu wrote:
> hi all
>
> i have two question about xl migrate
>
> write_batch
> 120 for ( i = 0; i < nr_pfns; ++i )
> 121 {
> 122 types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx,
> 123
> ctx->save.b
On 17/05/16 11:33, George Dunlap wrote:
> On Mon, May 16, 2016 at 11:33 PM, Boris Ostrovsky
> wrote:
>> On 05/16/2016 05:38 PM, Tony S wrote:
>>> The issue behind it is that the process execution calculation(e.g.,
>>> delta_exec) in virtualized environment should not be calculated as it
>>> did in
hi Andrew
>On 17/05/16 10:01, Zhang, Chunyu wrote:
>> hi all
>>
>> i have two question about xl migrate
>>
>> write_batch
>> 120 for ( i = 0; i < nr_pfns; ++i )
>> 121 {
>> 122 types[i] = mfns[i] = ctx->save.ops.pfn_to_gfn(ctx,
>> 123
>>> 2. line 125
>>> in hvm mode,would not be a balloon page.
>>> gfn would not be INVALID_MFN.
>>> mfn would be INVALID_MFN.
>>> right?
>> I don't understand what you asking here.
> i think those code should delete:
>>> 125 /* Likely a ballooned page. */
> if page is ballooed, gfns is not
flight 94496 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs.
92452
Regressions which ar
Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.
Also there is one more place for XEN_CR4_PV32_BITS to be used.
Signed-off-by: J
hi Andrew
>
2. line 125
in hvm mode,would not be a balloon page.
gfn would not be INVALID_MFN.
mfn would be INVALID_MFN.
right?
>>> I don't understand what you asking here.
>> i think those code should delete:
125 /* Likely a ballooned page. */
>> if page is ba
Hi Konrad,
On 16/05/16 20:43, Konrad Rzeszutek Wilk wrote:
On Thu, May 05, 2016 at 04:41:51PM +0100, Steve Capper wrote:
[Apologies for the late send]
Xen - ARM Status
There was discussion on the following items:
*) Booting Xen on 64-bit ARM SoC
o) Unfortunately Xen was ex
This run is configured for baseline tests only.
flight 44421 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44421/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 capture-logs
On Sat, 14 May 2016, Matt Fleming wrote:
> Folks,
>
> Please pull the following branch which contains support for Xen on ARM
> EFI platforms.
>
> This merge includes a merge of Stefano's xen/linux-next branch to pull
> in the prerequisites required for Shannon's commit:
>
> 11ee5491e5ff ("Xen:
/proc/xen/xenbus does not work correctly. A read blocked waiting for
a xenstore message holds the mutex needed for atomic file position
updates. This blocks any writes on the same file handle, which can
deadlock if the write is needed to unblock the read.
/proc/xen/xenbus is supposed to be ident
simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.
Signed-off-by: David Vrabel
---
v2:
- simplified.
---
fs/libfs.c | 15 +--
include/linux/fs.h | 2 +-
2 files changed, 14 insertions(+), 3 deletions(-)
diff
Using /proc/xen/xenbus can cause deadlocks on the atomic file position
mutex since this file should behave like a character device and not a
regular file. This is easiest to achive by making it a symlink to the
existing /dev/xen/xenbus device.
This requires extending simple_fill_super() to add sy
On 17/05/16 10:54, Jan Beulich wrote:
> Instead of just latching cr4_pv32_mask into %rdx, correct the found
> wrong value in %cr4 (to avoid triggering another BUG). The value left
> in %rdx should be sufficient for deducing cr4_pv32_mask from the
> register dump.
Alternatively, you can reuse %rax
This run is configured for baseline tests only.
flight 44423 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44423/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3fe37de
baseline version:
ovm
On 17/05/16 11:12, Stefano Stabellini wrote:
> On Sat, 14 May 2016, Matt Fleming wrote:
>> Folks,
>>
>> Please pull the following branch which contains support for Xen on ARM
>> EFI platforms.
>>
>> This merge includes a merge of Stefano's xen/linux-next branch to pull
>> in the prerequisites requi
>>> On 17.05.16 at 12:28, wrote:
> On 17/05/16 10:54, Jan Beulich wrote:
>> Instead of just latching cr4_pv32_mask into %rdx, correct the found
>> wrong value in %cr4 (to avoid triggering another BUG). The value left
>> in %rdx should be sufficient for deducing cr4_pv32_mask from the
>> register d
On Tue, 17 May 2016, Jan Beulich wrote:
> >>> On 16.05.16 at 17:40, wrote:
> > On Mon, 16 May 2016, Julien Grall wrote:
> >> It has been a while without any ARM backport request. Ian Campbell
> >> used to keep a list of backport fixes for Xen ARM and apply them
> >> to stable. Now that he left, I
>>> On 16.05.16 at 11:24, wrote:
> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>> flight 94442 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/94442/
> [...]
>>
>> test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-installfail REGR. vs.
>
>>> On 17.05.16 at 12:49, wrote:
> On Tue, 17 May 2016, Jan Beulich wrote:
>> >>> On 16.05.16 at 17:40, wrote:
>> > On Mon, 16 May 2016, Julien Grall wrote:
>> >> It has been a while without any ARM backport request. Ian Campbell
>> >> used to keep a list of backport fixes for Xen ARM and apply t
On Mon, 16 May 2016, Julien Grall wrote:
> Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
> Xen has been undoing the P2M mappings when an error occurred during
> insertion or memory allocation.
>
> The function apply_p2m_changes can work with region not-aligned to a
> blo
Hi Edgar,
On 16/05/16 16:03, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Do not remap IRQs connected to secondary interrupt controllers.
These IRQs have no meaning to us until they connect to the
primary controller.
Secondary IRQ controllers will at some point connect to the
primary co
On 13/04/16 10:49, Juergen Gross wrote:
> On 06/04/16 16:17, Juergen Gross wrote:
>> Some hardware (e.g. Dell Studio laptops) require special functions to
>> be called on physical cpu 0 in order to avoid occasional hangs. When
>> running as dom0 under Xen this could be achieved only via special boo
I think you are right. Especially with backports in mind, it would be
better to introduce an __apply_p2m_changes function which assumes that
the p2m lock has already been taken by the caller. Then you can base the
implementation of apply_p2m_changes on it.
Wei,
It might be best for you to give two
All,
with this due in about three weeks, please indicate backports you find
missing from its staging tree but you deem necessary in the release.
I already have commit 556c69f4ef ("x86/PoD: skip eager reclaim when
possible") queued, and I'm undecided about af07377007 ("IOMMU/x86:
per-domain control
Hi Stefano and Wei,
On 17/05/16 12:24, Stefano Stabellini wrote:
I think you are right. Especially with backports in mind, it would be
better to introduce an __apply_p2m_changes function which assumes that
the p2m lock has already been taken by the caller. Then you can base the
implementation of
I just set the domid to DOMID_SELF to pass the check, but another problem
is how to assign the gfn used to store #ve infomation. As I'm doing all the
things in user space, directly assign a new physical page seems impossible.
While LKM can do that with kmalloc and virt_to_phys, it cannot call user
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-4480 / XSA-176
version 3
x86 software guest page walk PS bit handling flaw
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
===
From: "Edgar E. Iglesias"
Do not remap IRQs connected to secondary interrupt controllers.
These IRQs have no meaning to us until they connect to the
primary controller.
Secondary IRQ controllers will at some point connect to the
primary controller (possibly via other IRQ controllers). We
map the
On Tue, May 17, 2016 at 12:20:43PM +0100, Julien Grall wrote:
> Hi Edgar,
>
> On 16/05/16 16:03, Edgar E. Iglesias wrote:
> >From: "Edgar E. Iglesias"
> >
> >Do not remap IRQs connected to secondary interrupt controllers.
> >These IRQs have no meaning to us until they connect to the
> >primary co
On Tue, 17 May 2016, Julien Grall wrote:
> Hi Stefano and Wei,
>
> On 17/05/16 12:24, Stefano Stabellini wrote:
> > I think you are right. Especially with backports in mind, it would be
> > better to introduce an __apply_p2m_changes function which assumes that
> > the p2m lock has already been tak
>>> On 22.04.16 at 12:54, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -33,6 +33,8 @@ integer_param("vtd_qi_timeout", vtd_qi_timeout);
>
> #define IOMMU_QI_TIMEOUT (vtd_qi_timeout * MILLISECS(1))
>
> +static int invalidate_sync(struct i
On 5/17/16 6:33 AM, Jan Beulich wrote:
> All,
>
> with this due in about three weeks, please indicate backports you find
> missing from its staging tree but you deem necessary in the release.
> I already have commit 556c69f4ef ("x86/PoD: skip eager reclaim when
> possible") queued, and I'm undecid
Hi Stefano,
On 17/05/16 13:27, Stefano Stabellini wrote:
On Tue, 17 May 2016, Julien Grall wrote:
On 17/05/16 12:24, Stefano Stabellini wrote:
I think you are right. Especially with backports in mind, it would be
better to introduce an __apply_p2m_changes function which assumes that
the p2m lo
On 17/05/16 11:42, Jan Beulich wrote:
On 17.05.16 at 12:28, wrote:
>> On 17/05/16 10:54, Jan Beulich wrote:
>>> Instead of just latching cr4_pv32_mask into %rdx, correct the found
>>> wrong value in %cr4 (to avoid triggering another BUG). The value left
>>> in %rdx should be sufficient for de
flight 94502 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94502/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 guest-saverestorefail never pass
test-armhf-armhf-libvirt 12 migrate-sup
On Tue, 17 May 2016, David Vrabel wrote:
> On 17/05/16 11:12, Stefano Stabellini wrote:
> > On Sat, 14 May 2016, Matt Fleming wrote:
> >> Folks,
> >>
> >> Please pull the following branch which contains support for Xen on ARM
> >> EFI platforms.
> >>
> >> This merge includes a merge of Stefano's xe
>>> On 17.05.16 at 14:45, wrote:
> Should we backport something like
> 013396f93ee2d4ec416f701ae420c683b7327230 to help users avoid the
> deadlock present when using a domU with a Linux kernel 3.14 or newer?
>
> If yes then you might want the init script fixes to make the daemons use
> that as we
>>> On 17.05.16 at 14:56, wrote:
> On 17/05/16 11:42, Jan Beulich wrote:
> On 17.05.16 at 12:28, wrote:
>>> On 17/05/16 10:54, Jan Beulich wrote:
Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
On 17/05/16 11:57, Jan Beulich wrote:
On 16.05.16 at 11:24, wrote:
>> On Mon, May 16, 2016 at 02:57:13AM +, osstest service owner wrote:
>>> flight 94442 xen-unstable real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/94442/
>> [...]
>>> test-amd64-i386-qemuu-rhel6hvm-inte
On Mon, May 16, 2016 at 05:59:15PM +0100, Andrew Cooper wrote:
> In general, Invariant TSC is not a feature which can be advertised to guests,
> because it cannot be guaranteed across migrate. domain_cpuid() goes so far as
> to deliberately clobber the feature flag under a number of circumstances.
On Tue, May 17, 2016 at 02:15:50PM +0200, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias"
>
> Do not remap IRQs connected to secondary interrupt controllers.
> These IRQs have no meaning to us until they connect to the
> primary controller.
>
> Secondary IRQ controllers will at some point c
On Tue, May 17, 2016 at 05:33:48AM -0600, Jan Beulich wrote:
> All,
>
> with this due in about three weeks, please indicate backports you find
> missing from its staging tree but you deem necessary in the release.
> I already have commit 556c69f4ef ("x86/PoD: skip eager reclaim when
> possible") q
On Thu, Mar 10, 2016 at 01:36:34PM +, Wu, Feng wrote:
>
>
> > -Original Message-
> > From: Tian, Kevin
> > Sent: Thursday, March 10, 2016 6:06 PM
> > To: Jan Beulich
> > Cc: Andrew Cooper ; Dario Faggioli
> > ; David Vrabel ;
> > GeorgeDunlap ; Lars Kurth ;
> > George Dunlap ; Ian Ja
flight 94499 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94499/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
build-amd64-libvi
>>> On 17.05.16 at 15:23, wrote:
> I would like to propose backporting some mini-os patches to mini-os.git
> stable-4.6 branch and update Config.mk in 4.6.
On top of the recently backported ones?
> I guess I will bring that up with Samuel and then post patch here?
Yes please.
Jan
___
Instead of just latching cr4_pv32_mask into %rdx, correct the found
wrong value in %cr4 (to avoid triggering another BUG). The value left
in %rdx should be sufficient for deducing cr4_pv32_mask from the
register dump.
Also there is one more place for XEN_CR4_PV32_BITS to be used.
Signed-off-by: J
On Tue, May 17, 2016 at 07:35:16AM -0600, Jan Beulich wrote:
> >>> On 17.05.16 at 15:23, wrote:
> > I would like to propose backporting some mini-os patches to mini-os.git
> > stable-4.6 branch and update Config.mk in 4.6.
>
> On top of the recently backported ones?
Yes.
>
> > I guess I will b
On 17/05/16 14:35, Jan Beulich wrote:
> Instead of just latching cr4_pv32_mask into %rdx, correct the found
> wrong value in %cr4 (to avoid triggering another BUG). The value left
> in %rdx should be sufficient for deducing cr4_pv32_mask from the
> register dump.
>
> Also there is one more place fo
On Tue, May 17, 2016 at 02:37:16PM +0100, Andrew Cooper wrote:
> On 17/05/16 14:35, Jan Beulich wrote:
> > Instead of just latching cr4_pv32_mask into %rdx, correct the found
> > wrong value in %cr4 (to avoid triggering another BUG). The value left
> > in %rdx should be sufficient for deducing cr4_
Here is the instrumented output with dom0_mem=18432M,max:18432M.
...
[0.00] xen_count_remap_pages(max_pfn=0x48) == 0x85dea
[0.00] max_pages 0x505dea
[0.00] xen_add_extra_mem(48, 85dea)
[0.00] memblock_reserve(0x48000, 0x85dea000)
[0.00] Released
> - The serial controller on the Tegra SoCs doesn't behave in the same
> was as most NS16550-compatibles; it actually adheres to the NS16550
> spec a little more rigidly than most compatible controllers. A
> coworker (Chris Patterson, cc'd) figured out what was going on; from
> what I understand, m
On Tue, May 17, 2016 at 04:58:03PM +0800, Big Strong wrote:
> I should add the xsm=policy option to the end of the xen.cfg instead of as
> an option. Sorry for the fault.
>
> However, another problem is that when I modified the policy and reload it
> using '*xl loadpolicy*', the policy seemed not
Hi all,
please find below the tally of the following vote
http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00801.html
covering the attached change to our governance
5 votes (3 from Hypervisor Committers, 2 from XAPI committers), all with +1, so
it carries
Best Regards
Lars
---
T
There is one instruction boundary where any kind of interruption would
break the assumptions cr4_pv32_restore's debug mode checking makes on
the correlation between the CR4 register value and its in-memory cache.
Correct this (see the code comment) even in non-debug mode, or else
a subsequent cr4_p
On 17/05/16 14:43, Jan Beulich wrote:
> There is one instruction boundary where any kind of interruption would
> break the assumptions cr4_pv32_restore's debug mode checking makes on
> the correlation between the CR4 register value and its in-memory cache.
> Correct this (see the code comment) even
On Tue, May 17, 2016 at 07:43:34AM -0600, Jan Beulich wrote:
> There is one instruction boundary where any kind of interruption would
> break the assumptions cr4_pv32_restore's debug mode checking makes on
> the correlation between the CR4 register value and its in-memory cache.
> Correct this (see
On Tue, May 17, 2016 at 10:57:12AM +0100, Julien Grall wrote:
> Hi Konrad,
>
> On 16/05/16 20:43, Konrad Rzeszutek Wilk wrote:
> >On Thu, May 05, 2016 at 04:41:51PM +0100, Steve Capper wrote:
> >>[Apologies for the late send]
> >>
> >>Xen - ARM Status
> >>
> >>There was discussion
>>> On 22.04.16 at 12:54, wrote:
> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -206,10 +206,71 @@ static int invalidate_sync(struct iommu *iommu)
> return 0;
> }
>
> +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
> +
Thanks very much, it turns out to be the problem of modules.conf. I turn
the xen module off for mistake, I'm very sorry for the time you spend.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 13.05.16 at 21:54, wrote:
> --- a/xen/drivers/passthrough/amd/iommu_acpi.c
> +++ b/xen/drivers/passthrough/amd/iommu_acpi.c
> @@ -821,13 +821,23 @@ static u16 __init parse_ivhd_device_special(
> return dev_length;
> }
>
> +static inline int get_ivhd_header_size(const struct acpi_ivr
flight 94503 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94503/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
baseline version:
ovmf 7b13510f2a0a2a118cdafdaa67720ca8e3f
flight 94514 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94514/
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
flight 94508 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94508/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 92452
build-i386-libvirt
On Sun, May 15, 2016 at 7:54 PM, Tianyang Chen wrote:
> The first part of this patch series aims at fixing coding syle issue
> for control structures. Because locks are grabbed in schedule.c before
> hooks are called, underscores in front of function names are removed.
>
> The second part replaces
On Sun, May 15, 2016 at 7:54 PM, Tianyang Chen wrote:
> No functional change:
> -Various coding style fix
> -Added comments for UPDATE_LIMIT_SHIFT.
>
> Signed-off-by: Tianyang Chen
Reviewed-by: Meng Xu
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylv
Hey,
I was wondering if there is an interest in exposing those
via xentop?
I wrote a hack patch (see attached) that expose this which helped
me figure out what guests are doing when their CPU consumption
time is low. As in whether they are truly 'halted' or
if they are preempted by the hypervisor
On Sun, May 15, 2016 at 7:54 PM, Tianyang Chen wrote:
> Vcpu flags are checked and cleared atomically. Performance can be
> improved with corresponding non-atomic versions since schedule.c
> already has spin_locks in place.
>
> Signed-off-by: Tianyang Chen
Reviewed-by: Meng Xu
Thanks,
Meng
--
Hello Jan,
perhaps you can shed some light on the state of the xenfied SUSE kernels
(http://kernel.opensuse.org/cgit/kernel-source).
We use xenified kernels based on kernel 3.4 for years and benchmarks
showed that they are faster than the pvops (vanilla) kernels.
But what is the current stat
On 11/05/16 11:16, David Vrabel wrote:
>
> Why don't we get the RW bits correct when making the pteval when we
> already have the pfn, instead trying to fix it up afterwards.
Kevin, can you try this patch.
David
8<-
x86/xen: avoid m2p lookup when setting early page table entries
On Tue, 2016-05-17 at 11:07 -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> I was wondering if there is an interest in exposing those
> via xentop?
>
> I wrote a hack patch (see attached) that expose this which helped
> me figure out what guests are doing when their CPU consumption
> time is low.
flight 94504 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94504/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 3 host-install(3) broken REG
>>> On 17.05.16 at 17:10, wrote:
> We use xenified kernels based on kernel 3.4 for years and benchmarks
> showed that they are faster than the pvops (vanilla) kernels.
> But what is the current state in terms of performance and features?
I'm not sure what you expect here. Up to openSUSE 42.1 and
Patches pulled in:
lib/sys.c: enclose file_types in define guards
build: change MINI-OS_ROOT to MINIOS_ROOT
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Ian Jackson
One of the patches is required to build stubdom on Ubuntu 16.04.
Samuel has confirmed it's fine to backport both.
htt
flight 94501 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94501/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 5 libvirt-build fail REGR. vs. 93932
build-i386-libvir
On Tue, May 17, 2016 at 3:27 AM, George Dunlap wrote:
> On Sun, May 15, 2016 at 5:11 AM, Tony S wrote:
>> Hi all,
>>
>> When I was running latency-sensitive applications in VMs on Xen, I
>> found some bugs in the credit scheduler which will cause long tail
>> latency in I/O-intensive VMs.
>>
>>
>
1 - 100 of 129 matches
Mail list logo
