flight 94519 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94519/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf b41ef32518095f783d0c2343b496cc857c6f3dff
baseline version:
ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215e
flight 94515 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94515/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail like 94038
test-amd64-i386-xl-qemuu-w
This run is configured for baseline tests only.
flight 44425 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44425/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-xsm 4 capture-logs
On Tue, May 17, 2016 at 8:43 PM, Big Strong wrote:
> Should the VMFUNC and #VE must run in kernel mode? I.E. as a linux kernel
> module or windows driver? if it is, how to invoke hypercall from the domU
> kernel, by ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall) or directly issue
> 0x82 interrupt?
flight 94507 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt5 libvirt-build fail REGR. vs. 94487
Tests which are fail
Should the VMFUNC and #VE must run in kernel mode? I.E. as a linux kernel
module or windows driver? if it is, how to invoke hypercall from the domU
kernel, by ioctl(fd, IOCTL_PRIVCMD_HYPERCALL, hypercall) or directly issue
0x82 interrupt?
2016-05-17 20:05 GMT+08:00 Big Strong :
> I just set the d
On 5/12/16 4:04 AM, Jan Beulich wrote:
On 11.05.16 at 19:37, wrote:
>> On 5/11/16 4:45 AM, Jan Beulich wrote:
>> On 10.05.16 at 23:05, wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -15,4 +15,11 @@ config DEBUG
option is intended for development purpos
flight 94525 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94525/
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 5/12/16 4:03 AM, Jan Beulich wrote:
On 11.05.16 at 19:35, wrote:
>> On 5/11/16 4:47 AM, Jan Beulich wrote:
>> On 10.05.16 at 23:05, wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -1,6 +1,13 @@
menu "Debugging Options"
+config CRASH_DE
On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> These four little cleanups move the bulk of tmem control ops
> from tmem.c to tmem_control.c.
>
> Last release I moved the control tmem ops from being part of tmem
> hypercall to be part of the syscall subops - and this is the next
> st
On 5/17/16 8:57 PM, Doug Goldstein wrote:
> On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
>> And adjust the macro: atomic_inc_and_max to update the structure.
>>
>> Sadly one entry: pool->pgp_count cannot use this macro anymore
>> so unroll the macro for this instance.
>>
>> No functional chang
On 5/16/16 10:58 AM, Konrad Rzeszutek Wilk wrote:
> And adjust the macro: atomic_inc_and_max to update the structure.
>
> Sadly one entry: pool->pgp_count cannot use this macro anymore
> so unroll the macro for this instance.
>
> No functional change. The name has the 'tmem_stats' as it will
> be
flight 94506 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94506/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94248
test-amd64-i386-xl-qemuu-win
On Fri, Apr 15, 2016 at 12:39:42PM +0900, Wonseok Ko wrote:
> Hi Konrad,
>
> Finally, I can use ethernet :D. It was my mistake. I thought the
> SET_NETDEV_DEV() makes ndev == pdev->dev, but it's not true.
>
> So I changed the dma configuration from:
>
> dma_coerce_mask_and_coherent(*&pdev->dev
On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
> Also adding Steve Maresca to the thread, who has been using XSM extensively
> and also documenting XSM and can provide some user perspective
> Lars
>
> > On 25 Apr 2016, at 20:51, Daniel De Graaf wrote:
> >
> > On 04/25/2016 02:32 P
flight 94529 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94529/
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 05/17/2016 09:11 AM, David Vrabel wrote:
> 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.
Yes :D. The patch is working fine.
I only g
I added some more instrumentation and discovered that the result of
xen_count_remap_pages() (0x85dea) is one less than the actual number
of pages remapped by xen_set_identity_and_remap() (0x85deb).
The two functions differ in their handling of a xen_e820_map entry
whose size is not a multiple of t
On Tue, May 17, 2016 at 12:31:10PM -0400, Chris Patterson wrote:
> On Tue, May 17, 2016 at 9:37 AM, Konrad Rzeszutek Wilk
> wrote:
> >> - 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 m
flight 94528 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94528/
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. 94514
build-amd64
Hi all
Xen 4.7 RC3 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.7.0-rc3
For you convenience there is also tarball at:
http://bits.xensource.com/oss-xen/release/4.7.0-rc3/xen-4.7.0-rc3.tar.gz
And the signature is at:
http://bits.xensource.com/oss-xen/release/
On Mon, May 16, 2016 at 11:58:27AM -0400, Konrad Rzeszutek Wilk wrote:
> Hey,
>
> These four little cleanups move the bulk of tmem control ops
> from tmem.c to tmem_control.c.
>
> Last release I moved the control tmem ops from being part of tmem
> hypercall to be part of the syscall subops - and
This run is configured for baseline tests only.
flight 44424 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44424/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 05b2f9c94e0c0b663ff2d2fb55397d8215eeb3f5
baseline version:
ovm
On 17/05/16 17:53, William Z. wrote:
> On 2016-05-04 18:02, Jan Beulich wrote:
> On 06.04.16 at 01:38, wrote:
>>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>>> Linux distros have been tested
flight 94521 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94521/
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. 94514
Tests which di
On 2016-05-04 18:02, Jan Beulich wrote:
On 06.04.16 at 01:38, wrote:
I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
with vga="qxl", Xorg will segfault instantly if tried started.
Multiple
Linux distros have been tested and Xorg segfaults in all.
So I've been wanting to
> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: 17 May 2016 17:32
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: re: xen-netback: add control protocol implementation
>
> Hello Paul Durrant,
>
> The patch 40d8abdee806: "xen-netback:
Hello Paul Durrant,
The patch 40d8abdee806: "xen-netback: add control protocol
implementation" from May 13, 2016, leads to the following static
checker warning:
drivers/net/xen-netback/hash.c:362 xenvif_set_hash_mapping()
warn: should this be 'len == -1'
drivers/net/xen-netback/h
On Tue, May 17, 2016 at 9:37 AM, Konrad Rzeszutek Wilk
wrote:
>> - 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 Patterso
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.
>>
>>
>
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
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
>>> 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
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 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.
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
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 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
--
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:
> 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
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
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
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 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
>>> 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
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 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,
> +
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 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 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
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
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
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
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 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_
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
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 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
___
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 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
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 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 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 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 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 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 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
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 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
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 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
>>> 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 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 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
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
-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
===
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
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
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
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
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
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 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
>>> 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 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 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 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
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
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
/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
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:
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
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
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
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
1 - 100 of 129 matches
Mail list logo
