flight 103161 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-2 52 leak-check/check fail REGR. vs. 102721
test-xtf-amd64-
On Dec 12, 2016 00:08, "Jan Beulich" wrote:
>>> On 09.12.16 at 19:38, wrote:
> On Fri, Dec 9, 2016 at 2:27 AM, Jan Beulich wrote:
> On 08.12.16 at 23:57, wrote:
>>> --- a/xen/arch/x86/mm/Makefile
>>> +++ b/xen/arch/x86/mm/Makefile
>>> @@ -9,6 +9,7 @@ obj-y += guest_walk_3.o
>>> obj-y += g
>>> On 09.12.16 at 18:55, wrote:
> ...if the domain is not under construction.
I think the title will end up misleading this way. How about "x86/hvm:
don't unconditionally create a default ioreq server" with "Avoid doing
so if the domain is not under construction" as the 1st sentence?
As the pat
>>> On 12.12.16 at 07:51, wrote:
> By the way, I think another place may need to do some modify as well.
>
> @@ -868,7 +868,7 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs
> *regs)
> if ( is_pmc_quirk )
> handle_pmc_quirk(msr_content);
> core2_vpmu_cxt
On Dec 12, 2016 00:42, "Jan Beulich" wrote:
>>> On 09.12.16 at 20:59, wrote:
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1461,7 +1461,8 @@ mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> * we indeed found a conflicting mem_access setting.
> */
> static struct page_info*
> -p
>>> On 09.12.16 at 20:59, wrote:
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1461,7 +1461,8 @@ mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> * we indeed found a conflicting mem_access setting.
> */
> static struct page_info*
> -p2m_mem_access_check_and_get_page(vaddr_t gva,
On 12/09/2016 09:08 PM, Boris Ostrovsky wrote:
On 12/09/2016 10:50 AM, Ross Lagerwall wrote:
When relocating the p2m/initrd, take special care not to relocate it so
that is overlaps with the current location of the p2m/initrd. This is
needed since the full extent of the current location is not m
>>> On 09.12.16 at 18:11, wrote:
> On 09/12/16 15:22, Jan Beulich wrote:
>> Move the looking at EFLAGS.DF into the macro, rendering all call sites
>> more readable.
>>
>> Signed-off-by: Jan Beulich
>
> The net change is ok; it is certainly cleaner to read in the body of
> x86_emulate().
>
> How
VMID space is increased to 16-bits from 8-bits in ARMv8 8.1 revision.
This allows more than 256 VMs to be supported by Xen.
This change adds support for 16-bit VMIDs in Xen based on whether the
architecture supports it.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/p2m.c | 56 ++
Since VMIDs are related to 2nd stage address translation, it makes more sense
to move the call to p2m_vmid_allocator_init(), which initializes the vmid
allocation bitmap, inside setup_virt_paging(), where 2nd stage address
translation
is set up.
Signed-off-by: Bhupinder Thakur
---
xen/arch/arm/
hi,
Thanks for the reply. I want to bring up xen on an intel embedded
development platform. I am going to buy one. Can you suggest a intel
development platform for embedded applications on which xen could work?
Thanks and regards,
George
On Friday, December 9, 2016, Konrad Rzeszutek Wilk
wrot
On 09/12/16 20:31, Stefano Stabellini wrote:
> On Fri, 9 Dec 2016, Juergen Gross wrote:
>> On 09/12/16 00:50, Stefano Stabellini wrote:
>>> On Thu, 8 Dec 2016, Andrew Cooper wrote:
On 08/12/2016 19:18, Stefano Stabellini wrote:
> On Thu, 8 Dec 2016, Andrew Cooper wrote:
>> On 08/12/16
>>> On 09.12.16 at 19:38, wrote:
> On Fri, Dec 9, 2016 at 2:27 AM, Jan Beulich wrote:
> On 08.12.16 at 23:57, wrote:
>>> --- a/xen/arch/x86/mm/Makefile
>>> +++ b/xen/arch/x86/mm/Makefile
>>> @@ -9,6 +9,7 @@ obj-y += guest_walk_3.o
>>> obj-y += guest_walk_4.o
>>> obj-y += mem_paging.o
>>>
> On 12/08/2016 10:17 PM, Luwei Kang wrote:
> > IA32_PERF_GLOBAL_STATUS.OvfUncore (MSR 38EH, bit[61]) is always 0 and
> > writing 1 to IA32_PERF_GLOBAL_OVF_CTRL.ClrOvfUncore (MSR 390H,
> > bit[61]) signals #GP.
> > Reference "Intel Xeon Phi Procssor x200 Product Family", document
> > number 334646-
On 12/10/2016 02:21 AM, Andrew Cooper wrote:
On 09/12/16 17:55, Paul Durrant wrote:
...if the domain is not under construction.
If upstream QEMU is in use then it will explicitly create an ioreq server
rather than implicitly creating the default ioreq server, which is a
side-effect of reading
On 12/09/16 17:27 -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 10, 2016 at 08:32:24AM +0800, Haozhong Zhang wrote:
The host pmem pages mapped to a domain are unassigned at domain destroy
so as to be used by other domains in future.
Signed-off-by: Haozhong Zhang
---
Cc: Jan Beulich
Cc: Andr
On 12/09/16 17:22 -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 10, 2016 at 08:32:23AM +0800, Haozhong Zhang wrote:
XENMEM_populate_pmemmap is used by toolstack to map given host pmem pages
to given guest pages. Only pages in the data area of a pmem region are
allowed to be mapped to guest.
S
On 12/09/16 17:02 -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 10, 2016 at 08:32:22AM +0800, Haozhong Zhang wrote:
Xen hypervisor does not include a pmem driver. Instead, it relies on the
pmem driver in Dom0 to report the PFN ranges of the entire pmem region,
its reserved area and data area v
On 12/09/16 16:38 -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 10, 2016 at 08:32:21AM +0800, Haozhong Zhang wrote:
A reserved area on each pmem region is used to place the M2P table.
However, it's not at the beginning of the pmem region, so we need to
specify the location explicitly when crea
On 12/09/16 16:35 -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Oct 10, 2016 at 08:32:20AM +0800, Haozhong Zhang wrote:
A reserved area on each pmem region is used to place the frame table.
However, it's not at the beginning of the pmem region, so we need to
specify the location explicitly when ex
On 2016/12/10 0:15, Konrad Rzeszutek Wilk wrote:
On Fri, Dec 09, 2016 at 04:21:02PM +0800, Ken wrote:
Hi all,
I run the Ubuntu 16.04 server (2 vcpu/2G, Linux 4.4.0) on the Xen-4.1.2, and
installed gcc through the CDROM used by 16.04 iso file, when I installed gcc
that depends deb packages to
flight 103167 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/103167/
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 1
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid xen-boot/dst_host
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfi
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-pair
testid xen-boot/src_host
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfi
On 11/12/16 17:33, Boris Ostrovsky wrote:
> - andrew.coop...@citrix.com wrote:
>
>> On 09/12/16 19:55, Andrew Cooper wrote:
>>> On 09/12/16 19:55, Boris Ostrovsky wrote:
On 12/09/2016 02:01 PM, Andrew Cooper wrote:
> Hello,
>
> While working on XSA-192, I found a curious thing.
- andrew.coop...@citrix.com wrote:
> On 09/12/16 19:55, Andrew Cooper wrote:
> > On 09/12/16 19:55, Boris Ostrovsky wrote:
> >> On 12/09/2016 02:01 PM, Andrew Cooper wrote:
> >>> Hello,
> >>>
> >>> While working on XSA-192, I found a curious thing. On AMD
> hardware, the
> >>> VMMCALL instru
26 matches
Mail list logo
