On the VT-d troubleshooting page, I was informed to shoot you all a
message if Xen had to deactivate my VT-d due to errors in my BIOS (in
this case Coreboot). I am running John Lewis' Coreboot ROM for the
Chromebook Pixel 2 (samus) w/ the i7-5600U processor and Xen 4.4.2 on
Qubes. I downloaded
* Greg KH wrote:
> On Thu, Aug 13, 2015 at 06:38:46PM -0700, Andy Lutomirski wrote:
> > On Thu, Aug 13, 2015 at 5:44 PM, wrote:
> > >
> > > This is a note to let you know that I've just added the patch titled
> > >
> > > x86/ldt: Make modify_ldt synchronous
> >
> > This needs:
> >
> > ht
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 12, 2015 11:06 PM
>
> Tearing down a 1:1 mapping that was never established isn't really nice
> (and in fact hits an ASSERT() in p2m_remove_page()). Convert from a
> wrapper macro to a proper function which then can take care
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 12, 2015 10:17 PM
>
> ... and its callers.
>
> While all non-nested users are made fully honor the semantics of that
> type, doing so in the nested case seemed insane (if doable at all,
> considering VMCS shadowing), and hen
Hi Paul,
On 8/13/2015 6:39 PM, Yu, Zhang wrote:
On 8/13/2015 6:16 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 13 August 2015 11:06
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano
Stabellini; Ian
Campbell; Wei Liu;
Hi Ian,
Please find attached "new" patches for the 'Qemu-dm 3.4 stable branch’
(git://xenbits.xen.org/qemu-xen-3.4-testing.git) with Signed-off-by included:
# sha256sum xsa140-qemut-3.4-?.patch
444b0487b6ae702b13626780b94cfe9d5b7e39c0b6ae26fc162fe93c84c83407
xsa140-qemut-3.4-1.patch
b08ee94533
Hi, I compared the hvm domain start log when using device model stub domain
with that when using dom0 qemu:
the former log:
[2015-08-12 17:11:24] (d1) [ 135.565586] PCI-ISA link 0 routed to IRQ5
[2015-08-12 17:11:24] (d1) [ 135.565648] PCI-ISA link 1 routed to IRQ10
[2015-08-12 17:11:24] (d1) [
On 08/13/2015 12:46 AM, Rafal Mielniczuk wrote:
> On 12/08/15 11:17, Bob Liu wrote:
>> On 08/12/2015 01:32 AM, Jens Axboe wrote:
>>> On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote:
On 11/08/15 07:08, Bob Liu wrote:
> On 08/10/2015 11:52 PM, Jens Axboe wrote:
>> On 08/10/2015 05:03 AM,
On 14/08/15 08:13, fowlsl...@riseup.net wrote:
On the VT-d troubleshooting page, I was informed to shoot you all a
message if Xen had to deactivate my VT-d due to errors in my BIOS (in
this case Coreboot). I am running John Lewis' Coreboot ROM for the
Chromebook Pixel 2 (samus) w/ the i7-5600U
> -Original Message-
> From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 14 August 2015 08:41
> To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini;
> Ian
> Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
> Cc: Kevin Tian; zhiyuan...@int
PCI configuration space is not emulated by the hypervisor. There must be an
external emulator to handle config cycles which, in the general case, is either
QEMU or a stub domain. Either one of these must be running *before* the guest
is unpaused and hence allowed to generate I/O emulation reques
>> Hi all:
>>
>> Now a days, we tested Redhat 6.2(6.4) on Xen(version 4.1.2).
>> If we config the cpu number more than 32, it'll show 32 in
>> the VM, and if we config it 64 cpus, the VM will crash and
>> the log is list below.
>>
>> Can someone tell us why is this happening?
>
> Old RHEL6 kernels
flight 60673 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60673/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 60152
Regressions whic
>>> On 13.08.15 at 19:01, wrote:
> On Thu, 2015-08-13 at 09:29 -0600, Jan Beulich wrote:
>
> A bunch of your questions seem to be about things which have been discussed
> at length in previous postings, it's probably worth reviewing some of those
> discussions.
With the huge amount of mail to be
On 8/14/2015 4:46 PM, Paul Durrant wrote:
-Original Message-
From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 August 2015 08:41
To: Paul Durrant; xen-devel@lists.xen.org; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
As suggested by Jan Beulich, moved struct monitor_write_data from
struct arch_domain to struct arch_vcpu, as well as moving all
vm_event-related data from asm-x86/domain.h to struct vm_event,
and allocating it dynamically only when needed.
Signed-off-by: Razvan Cojocaru
---
xen/arch/x86/domain.c
On Fri, 14 Aug 2015, Shannon Zhao wrote:
> On 2015/8/13 18:29, Christoffer Dall wrote:
> > On Thu, Aug 13, 2015 at 11:22:19AM +0100, Ian Campbell wrote:
> >> > On Thu, 2015-08-13 at 11:13 +0100, Stefano Stabellini wrote:
> >>> > >
> > > > > > For example it is only natural for the kernel to tr
On 07/08/15 18:29, Chris (Christopher) Brand wrote:
> Hi Julien,
>
> Thanks for the review.
>
>> OOI, you win 30MB of RAM but how does this affect the performance?
>
> Fair question. :-) All I can say is that I don't see any noticeable
> difference on my
> system. Are there performance tests th
>>> On 13.08.15 at 21:22, wrote:
> On Mon, Aug 10, 2015 at 03:17:48PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 20, 2015 at 04:29:03PM +0200, Daniel Kiper wrote:
>> > @@ -34,6 +57,42 @@ multiboot1_header_start: /*** MULTIBOOT1 HEADER
>> > /
>> > .long -(MULTIBOOT_HEA
>>> On 14.08.15 at 11:14, wrote:
> flight 60673 xen-4.4-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/60673/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-armhf-armhf-xl-multivcpu 16 guest-start/d
On Fri, 2015-08-14 at 00:38 +0100, Wei Liu wrote:
> On Fri, Aug 14, 2015 at 01:25:45AM +0200, Dario Faggioli wrote:
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -1202,11 +1202,27 @@ static void parse_vnuma_config(const XLU_Config
> > > *config,
> > > }
>
>>> On 14.08.15 at 11:54, wrote:
> @@ -571,7 +571,7 @@ void hvm_do_resume(struct vcpu *v)
> }
>
> /* Inject pending hw/sw trap */
> -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
> +if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
Stray whitespace change to unrelated code.
>>> On 14.08.15 at 05:36, wrote:
> From: Shannon Zhao
>
> Len Brown (1):
> ACPI: disable ACPI cleanly when bad RSDP found
>
> Tomasz Nowicki (1):
> ACPI/table: Always count matched and successfully parsed entries
These look good now, but is there a reason you didn't also port
the third com
Hi Chris,
Sorry for the late reply. The code looks ok, see comment below.
On 07/08/15 21:40, Chris (Christopher) Brand wrote:
> setup_frametable_mappings() rounds frametable_size up to a multiple
> of 32MB. This is wasteful on systems with less than 4GB of RAM,
> although it does allow the "conti
On 08/14/2015 01:21 PM, Jan Beulich wrote:
On 14.08.15 at 11:54, wrote:
>> @@ -571,7 +571,7 @@ void hvm_do_resume(struct vcpu *v)
>> }
>>
>> /* Inject pending hw/sw trap */
>> -if ( v->arch.hvm_vcpu.inject_trap.vector != -1 )
>> +if ( v->arch.hvm_vcpu.inject_trap.vector !
>>> On 31.07.15 at 18:06, wrote:
> On 07/24/2015 05:41 AM, Jan Beulich wrote:
>> @@ -1693,14 +1703,22 @@ int nvmx_handle_vmclear(struct cpu_user_
>> else
>> {
>> /* Even if this VMCS isn't the current one, we must clear it. */
>> -vvmcs = hvm_map_guest_frame_rw(gpa >>
>>> On 14.08.15 at 12:30, wrote:
> On 08/14/2015 01:21 PM, Jan Beulich wrote:
> On 14.08.15 at 11:54, wrote:
>>> @@ -460,6 +459,18 @@ typedef enum __packed {
>>> SMAP_CHECK_DISABLED,/* disable the check */
>>> } smap_check_policy_t;
>>>
>>> +/*
>>> + * Should we emulate the ne
flight 60676 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60676/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 60159
Regress
Hi Shannon,
On 14/08/15 04:36, Shannon Zhao wrote:
> From: Tomasz Nowicki
>
> Ported from Linux commit 4ceacd02f5a1795c5c697e0345ee10beef675290.
>
> acpi_parse_entries() allows to traverse all available table entries (aka
> subtables) by passing max_entries parameter equal to 0, but since its c
flight 37834 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-amd64-sid-netboot-pygrub 9 debian-di-install fail REGR. vs.
37816
test-a
>>> On 14.08.15 at 12:50, wrote:
> Hi Shannon,
>
> On 14/08/15 04:36, Shannon Zhao wrote:
>> From: Tomasz Nowicki
>>
>> Ported from Linux commit 4ceacd02f5a1795c5c697e0345ee10beef675290.
>>
>> acpi_parse_entries() allows to traverse all available table entries (aka
>> subtables) by passing max
On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
> > Every multiboot protocol (regardless of version) compatible image must
> > specify its load address (in ELF or multiboot header). Multiboot protocol
> > compati
On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote:
> > Add multiboot2 protocol support for relocatable images. Only GRUB2
> > with relevant patches understands that feature. Older multiboot
>
> You may want to enume
XenGT leverages ioreq server to track and forward the accesses to
GPU I/O resources, e.g. the PPGTT(per-process graphic translation
tables). Currently, ioreq server uses rangeset to track the BDF/
PIO/MMIO ranges to be emulated. To select an ioreq server, the
rangeset is searched to see if the I/O
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each.
This patch uses a seperate rangeset for the guest
This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubl
"Ouyangzhaowei (Charles)" writes:
>>> Hi all:
>>>
>>> Now a days, we tested Redhat 6.2(6.4) on Xen(version 4.1.2).
>>> If we config the cpu number more than 32, it'll show 32 in
>>> the VM, and if we config it 64 cpus, the VM will crash and
>>> the log is list below.
>>>
>>> Can someone tell us w
On 14/08/15 09:31, Bob Liu wrote:
> On 08/13/2015 12:46 AM, Rafal Mielniczuk wrote:
>> On 12/08/15 11:17, Bob Liu wrote:
>>> On 08/12/2015 01:32 AM, Jens Axboe wrote:
On 08/11/2015 03:45 AM, Rafal Mielniczuk wrote:
> On 11/08/15 07:08, Bob Liu wrote:
>> On 08/10/2015 11:52 PM, Jens Axb
>>> On 14.08.15 at 13:52, wrote:
> On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
>> > diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
>> > index 87b3341..27481ac 100644
>> > --- a/xen/inc
On 11.08.2015 16:12, Jan Beulich wrote:
On 05.08.15 at 16:09, wrote:
>> Todo:
>> * Should be moved to sysctl to only allow Dom0 access
>
> Because of?
The discussion in this thread:
[Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
was:
From: Andy Lutomirski
This patch has been added to the 3.12 stable tree. If you have any
objections, please let us know.
===
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under
On Fri, 14 Aug 2015, Jan Beulich wrote:
> >>> On 13.08.15 at 19:01, wrote:
> > On Thu, 2015-08-13 at 09:29 -0600, Jan Beulich wrote:
> >
> > A bunch of your questions seem to be about things which have been discussed
> > at length in previous postings, it's probably worth reviewing some of those
On 08/14/2015 06:38 AM, Jan Beulich wrote:
On 31.07.15 at 18:06, wrote:
On 07/24/2015 05:41 AM, Jan Beulich wrote:
@@ -1693,14 +1703,22 @@ int nvmx_handle_vmclear(struct cpu_user_
else
{
/* Even if this VMCS isn't the current one, we must clear it. */
-vvmcs =
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 14 August 2015 13:03
> To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini;
> Ian
> Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
> Cc: Kevin Tian; zhiyuan...@inte
On Fri, Aug 14, 2015 at 01:57:01PM +0200, Daniel Kiper wrote:
> On Tue, Aug 11, 2015 at 12:56:58PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jul 20, 2015 at 04:29:18PM +0200, Daniel Kiper wrote:
> > > Add multiboot2 protocol support for relocatable images. Only GRUB2
> > > with relevant patch
> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 14 August 2015 13:03
> To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini;
> Ian
> Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
> Cc: Kevin Tian; zhiyuan...@inte
>>> On 14.08.15 at 14:59, wrote:
> On 11.08.2015 16:12, Jan Beulich wrote:
> On 05.08.15 at 16:09, wrote:
>>> Todo:
>>> * Should be moved to sysctl to only allow Dom0 access
>>
>> Because of?
>
> The discussion in this thread:
>
> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for bu
On 14.08.2015 15:54, Jan Beulich wrote:
On 14.08.15 at 14:59, wrote:
>> On 11.08.2015 16:12, Jan Beulich wrote:
>> On 05.08.15 at 16:09, wrote:
Todo:
* Should be moved to sysctl to only allow Dom0 access
>>>
>>> Because of?
>>
>> The discussion in this thread:
>>
>> [Xen-deve
>>> On 14.08.15 at 15:21, wrote:
> On Fri, 14 Aug 2015, Jan Beulich wrote:
>> it's even less clear how you'd expect to suppress this in other guest
>> OSes (Windows - afaik - being able to run on ARM certainly makes it
>> a candidate guest, even if maybe this doesn't work today), namely
>> such no
On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
> >>> On 14.08.15 at 13:52, wrote:
> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
> >> > diff --git a/xen/include/asm-x86/page.h b/xen/include
On Fri, 14 Aug 2015, Jan Beulich wrote:
> >>> On 14.08.15 at 15:21, wrote:
> > On Fri, 14 Aug 2015, Jan Beulich wrote:
> >> it's even less clear how you'd expect to suppress this in other guest
> >> OSes (Windows - afaik - being able to run on ARM certainly makes it
> >> a candidate guest, even if
On 2015/8/12 17:11, Julien Grall wrote:
On 12/08/2015 08:22, Shannon Zhao wrote:
Hi,
Hi Shannon,
It's not part of the design discussion and we are avoiding to mix
discussion. Can you please create another thread (or at least renaming
the subject)?
I'm working on re-spinning this patchset
On Thu, 2015-08-13 at 15:49 -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Aug 10, 2015 at 09:21:35PM +0300, M. Ivanov wrote:
> > On Mon, 2015-08-10 at 10:47 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Aug 10, 2015 at 05:14:28PM +0300, M. Ivanov wrote:
> > > > On Mon, 2015-08-10 at 09:58 -0400
Hi Jan,
On 2015/8/14 18:24, Jan Beulich wrote:
On 14.08.15 at 05:36, wrote:
From: Shannon Zhao
Len Brown (1):
ACPI: disable ACPI cleanly when bad RSDP found
Tomasz Nowicki (1):
ACPI/table: Always count matched and successfully parsed entries
These look good now, but is there a reaso
(Renaming the subject)
Hi Shannon,
On 14/08/15 15:05, Shannon Zhao wrote:
>
>
> On 2015/8/12 17:11, Julien Grall wrote:
>> On 12/08/2015 08:22, Shannon Zhao wrote:
>>> Hi,
>>
>> Hi Shannon,
>>
>> It's not part of the design discussion and we are avoiding to mix
>> discussion. Can you please cre
>>> On 14.08.15 at 16:16, wrote:
> On 2015/8/14 18:24, Jan Beulich wrote:
> On 14.08.15 at 05:36, wrote:
>>> From: Shannon Zhao
>>>
>>> Len Brown (1):
>>>ACPI: disable ACPI cleanly when bad RSDP found
>>>
>>> Tomasz Nowicki (1):
>>>ACPI/table: Always count matched and successfully pa
>>> On 14.08.15 at 15:59, wrote:
> On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
>> >>> On 14.08.15 at 13:52, wrote:
>> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
>> >> On Mon, Jul 20, 2015 at 04:29:17PM +0200, Daniel Kiper wrote:
>> >> > diff --git a/
>>> On 14.08.15 at 16:03, wrote:
> On Fri, 14 Aug 2015, Jan Beulich wrote:
>> >>> On 14.08.15 at 15:21, wrote:
>> > On Fri, 14 Aug 2015, Jan Beulich wrote:
>> >> it's even less clear how you'd expect to suppress this in other guest
>> >> OSes (Windows - afaik - being able to run on ARM certainly
Hi Julien,
On 2015/8/14 22:17, Julien Grall wrote:
(Renaming the subject)
Hi Shannon,
On 14/08/15 15:05, Shannon Zhao wrote:
On 2015/8/12 17:11, Julien Grall wrote:
On 12/08/2015 08:22, Shannon Zhao wrote:
Hi,
Hi Shannon,
It's not part of the design discussion and we are avoiding to mi
On 2015/8/14 22:29, Jan Beulich wrote:
On 14.08.15 at 16:16, wrote:
On 2015/8/14 18:24, Jan Beulich wrote:
On 14.08.15 at 05:36, wrote:
From: Shannon Zhao
Len Brown (1):
ACPI: disable ACPI cleanly when bad RSDP found
Tomasz Nowicki (1):
ACPI/table: Always count matched and succe
On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote:
> >>> On 14.08.15 at 15:59, wrote:
> > On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
> >> >>> On 14.08.15 at 13:52, wrote:
> >> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rzeszutek Wilk wrote:
> >> >> On Mon, Jul
On Fri, 14 Aug 2015, Jan Beulich wrote:
> >>> On 14.08.15 at 16:03, wrote:
> > On Fri, 14 Aug 2015, Jan Beulich wrote:
> >> >>> On 14.08.15 at 15:21, wrote:
> >> > On Fri, 14 Aug 2015, Jan Beulich wrote:
> >> >> it's even less clear how you'd expect to suppress this in other guest
> >> >> OSes (W
On 14/08/15 15:35, Shannon Zhao wrote:
Do you copy data in the newly allocated memory between 2 xzalloc_bytes?
>>>
>>> No, I just use xzalloc_bytes to allocate some place and copy ACPI to the
>>> allocated place, modify the content, then call
>>> raw_copy_to_guest_flush_dcache to copy the
On 14/08/15 15:37, Stefano Stabellini wrote:
> On Fri, 14 Aug 2015, Jan Beulich wrote:
> On 14.08.15 at 16:03, wrote:
>>> On Fri, 14 Aug 2015, Jan Beulich wrote:
>>> On 14.08.15 at 15:21, wrote:
> On Fri, 14 Aug 2015, Jan Beulich wrote:
>> it's even less clear how you'd expect to
On 2015/8/14 22:41, Julien Grall wrote:
On 14/08/15 15:35, Shannon Zhao wrote:
Do you copy data in the newly allocated memory between 2 xzalloc_bytes?
No, I just use xzalloc_bytes to allocate some place and copy ACPI to the
allocated place, modify the content, then call
raw_copy_to_guest_fl
flight 60674 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60674/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat fail
REGR. vs. 58884
On 14/08/15 15:49, Shannon Zhao wrote:
>> Ok, so it's likely a memory corruption. You need to check the bound you
>> ara using when copying the data to the guest or from the ACPI in
>> general. Or maybe you just didn't allocate enough space.
>>
>
> But it fails at the xzalloc_bytes itself. not at
On 2015/8/14 22:53, Julien Grall wrote:
On 14/08/15 15:49, Shannon Zhao wrote:
Ok, so it's likely a memory corruption. You need to check the bound you
ara using when copying the data to the guest or from the ACPI in
general. Or maybe you just didn't allocate enough space.
But it fails at th
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v2->v3:
* remove the two HVM_PARAMs for grant table and let linux kernel use
xlated_setup_gnttab_pages() to setup grant table.
* don'
>>> On 14.08.15 at 16:37, wrote:
> On Fri, Aug 14, 2015 at 08:32:05AM -0600, Jan Beulich wrote:
>> >>> On 14.08.15 at 15:59, wrote:
>> > On Fri, Aug 14, 2015 at 06:49:18AM -0600, Jan Beulich wrote:
>> >> >>> On 14.08.15 at 13:52, wrote:
>> >> > On Tue, Aug 11, 2015 at 12:48:06PM -0400, Konrad Rz
>>> On 14.08.15 at 16:45, wrote:
> On 14/08/15 15:37, Stefano Stabellini wrote:
>> If you are thinking of Windows for ARM64, there isn't one yet. When/if
>> it will become available, there are going to be a number of issues to
>> address before we can run it as a guest on Xen on ARM with the curr
On 14/08/15 15:59, Shannon Zhao wrote:
> 2. Create minimal DT to pass required information to Dom0
> --
> The minimal DT mainly passes Dom0 bootargs, address and size of initrd
> (if available), address and size of uefi system table, address a
What is the purpose of 'nr_vmemranges < nr_vnodes' test in
xc_domain_setvnuma()? Can't we have nodes with no memory?
If that's the case, this check will still miss configurations when a
node spans multiple memory ranges.
For example, this fails:
vcpus = 4
vnuma = [ [ "pnode=0","size=2048","v
> > > trampoline_bios_setup:
> > > +mov %ebp,%esi
> > > +
> > > +/* Initialise GDT and basic data segments. */
> > > +add %ebp,sym_offset(gdt_boot_descr_addr)(%esi)
> > > +lgdtsym_offset(gdt_boot_descr)(%esi)
> > > +
> > > +mov $BOOT_DS,%ecx
On Fri, 14 Aug 2015, Jan Beulich wrote:
> >>> On 14.08.15 at 16:45, wrote:
> > On 14/08/15 15:37, Stefano Stabellini wrote:
> >> If you are thinking of Windows for ARM64, there isn't one yet. When/if
> >> it will become available, there are going to be a number of issues to
> >> address before we
On Fri, Aug 14, 2015 at 11:19:53AM -0400, Boris Ostrovsky wrote:
> What is the purpose of 'nr_vmemranges < nr_vnodes' test in
> xc_domain_setvnuma()? Can't we have nodes with no memory?
>
> If that's the case, this check will still miss configurations when a node
> spans multiple memory ranges.
>
On 08/14/2015 11:35 AM, Wei Liu wrote:
On Fri, Aug 14, 2015 at 11:19:53AM -0400, Boris Ostrovsky wrote:
What is the purpose of 'nr_vmemranges < nr_vnodes' test in
xc_domain_setvnuma()? Can't we have nodes with no memory?
If that's the case, this check will still miss configurations when a node
On Thu, 13 Aug 2015, Jan Beulich wrote:
>>>> On 13.08.15 at 11:42, wrote:
> > 2.1pci_hostbridge and pci_hostbridge_ops
> >
> > -
> > The init function in the PCI host driver calls to register hos
On Fri, Aug 14, 2015 at 11:38:43AM -0400, Boris Ostrovsky wrote:
> On 08/14/2015 11:35 AM, Wei Liu wrote:
> >On Fri, Aug 14, 2015 at 11:19:53AM -0400, Boris Ostrovsky wrote:
> >>What is the purpose of 'nr_vmemranges < nr_vnodes' test in
> >>xc_domain_setvnuma()? Can't we have nodes with no memory?
On Fri, Aug 14, 2015 at 10:59:19PM +0800, Shannon Zhao wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
> welcome.
>
> Changes v2->v3:
> * remove the two HVM_PARAMs for grant table and let li
On Fri, Aug 14, 2015 at 05:08:32PM +0300, M. Ivanov wrote:
> On Thu, 2015-08-13 at 15:49 -0400, Konrad Rzeszutek Wilk wrote:
> > On Mon, Aug 10, 2015 at 09:21:35PM +0300, M. Ivanov wrote:
> > > On Mon, 2015-08-10 at 10:47 -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Aug 10, 2015 at 05:14:28P
The test for 'nr_vmemranges < nr_vnodes' in xc_domain_setvnuma() was
originally writtten with the idea that number of memory ranges would
at least be equal to number of nodes.
We may want to specify nodes with no memory, however, and thus this
check should be removed.
Signed-off-by: Boris Ostrovs
This title should say "libxc: ..."
On Fri, Aug 14, 2015 at 12:18:52PM -0400, Boris Ostrovsky wrote:
> The test for 'nr_vmemranges < nr_vnodes' in xc_domain_setvnuma() was
> originally writtten with the idea that number of memory ranges would
> at least be equal to number of nodes.
>
> We may want
Hi Julien,
Thanks for the review.
> > /* Create Xen's mappings of memory.
> > - * Base and virt must be 32MB aligned and size a multiple of 32MB.
> > + * Mapping_size must be either 2MB or 32MB.
>
> I would have generalize the function to support any mapping size. But I'm
> also fine with the c
On 08/14/2015 12:26 PM, Wei Liu wrote:
This title should say "libxc: ..."
Ah, of course. Let me know if you want me to re-send it.
-boris
On Fri, Aug 14, 2015 at 12:18:52PM -0400, Boris Ostrovsky wrote:
The test for 'nr_vmemranges < nr_vnodes' in xc_domain_setvnuma() was
originally writtte
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, this
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, thi
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
commit aa1acff356bbedfd03b544051f5b371746735d89 upstream.
The update_va_mapping hypercall can fail if the VA isn't present
in the guest's page tables. Under certain loads, thi
r/0:0]
[14410.728735] Modules linked in:
[14410.728735] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.2.0-rc6-20150814-linus-doflr+ #1
[14410.728735] task: 8221a580 ti: 8220 task.ti:
8220
[14410.728735] RIP: e030:[] []
xen_hypercall_xen_version+0xa/0x20
[14410.728735
On Fri, Aug 14, 2015 at 12:16 AM, Ingo Molnar wrote:
>
> I just sent it to Linus, so barring a catastrophy it should be upstream soon.
Well, I just rejected that pull as completely broken, so I guess the
catastrophy happened... Or, alternatively, I mis-read the code, which
does happen, but my gia
; --
> Sander
Edit: it was clearly running rc6 not rc5.
> NMI watchdog: BUG: soft lockup - CPU#0 stuck for 51s! [swapper/0:0]
> [14410.728735] Modules linked in:
> [14410.728735] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 4.2.0-rc6-20150814-linus-doflr+ #1
> [14410.728735] ta
How about having a short discussion on Monday during Xen Summit to discuss on
the points.
We have a talk tuesday morning and I would update it based on the monday
discussion.
Regards,
Manish Jaggi
From: xen-devel-boun...@lists.xen.org on
behalf of Ste
flight 60675 xen-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60675/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
58892
Regressions
> > @@ -818,10 +819,13 @@ static void xen_pt_unregister_device(PCIDevice *d)
> > {
> > XenPCIPassthroughState *s = XEN_PT_DEVICE(d);
> > uint8_t machine_irq = s->machine_irq;
> > -uint8_t intx = xen_pt_pci_intx(s);
> > +uint8_t intx;
> > int rc;
> >
> > -if (machine_ir
On Fri, Jul 17, 2015 at 05:03:44PM +0100, Stefano Stabellini wrote:
> On Thu, 2 Jul 2015, Konrad Rzeszutek Wilk wrote:
> > It should never happen, but in case it does (an developer adds
> > a new register and the 'init_val' expands past the register
> > size) we want to report. The code will only w
Hi,
This is more-or-less what Julien requested. He noted that pt.contig was never
set to zero. When I looked further, I found other bits that were also never
given a value. Looking at the callsites, they almost all seem to assume a value
of zero, so that's what I went with.
Patch 1 re-orders the
Hi,
This is more-or-less what Julien requested. He noted that pt.contig was never
set to zero. When I looked further, I found other bits that were also never
given a value. Looking at the callsites, they almost all seem to assume a value
of zero, so that's what I went with.
Patch 1 re-orders the
Shuffle lines around so that the assignments in mfn_to_xen_entry()
occur in the same order as the bits are declared in lpae_pt_t.
This makes it easier to see which ones are never given a value.
No change in behaviour.
Also fix a minor comment typo.
Signed-off-by: Chris Brand
---
xen/include/asm
Ensure that every bit has a specific value.
Reported-by: Julien Grall
Signed-off-by: Chris Brand
---
xen/include/asm-arm/page.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 01628f3e96cb..7a56b2cb463a 100644
--- a/xen/incl
On Fri, 2015-08-14 at 12:15 -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Aug 14, 2015 at 05:08:32PM +0300, M. Ivanov wrote:
> > On Thu, 2015-08-13 at 15:49 -0400, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Aug 10, 2015 at 09:21:35PM +0300, M. Ivanov wrote:
> > > > On Mon, 2015-08-10 at 10:47 -0400
1 - 100 of 110 matches
Mail list logo
