Chen, Tiejun wrote on 2015-05-04:
> Yang,
>
> Thanks for your review.
>
> On 2015/5/4 12:07, Zhang, Yang Z wrote:
>> Chen, Tiejun wrote on 2015-05-04:
>>> While initializing VT-D we should mask interrupt message generation
>>> to avoid receiving any interrupt as pending before enable DMA
>>> tran
When checking the ACPI funciton of C-status, after 100 seconds sleep,
the sampling value of C0 status from the xenpm tool decreases.
Because C0=NOW()-C1-C2-C3-C4, when NOW() value is during idle time,
NOW() value is bigger than last C-status update time, and C0 value
is also bigger than ture value.
The virtual address of the linear p2m list should be stored in the
shared info structure read by the Xen tools to be able to support
64 bit pv-domains larger than 512 GB. Additionally the linear p2m
list interface includes a generation count which is changed prior
to and after each mapping change o
In case the Xen tools indicate they don't need the p2m 3 level tree
as they support the virtual mapped linear p2m list, just omit building
the tree.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/xen/p2m.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
di
Check whether the hypervisor supplied p2m list is placed at a location
which is conflicting with the target E820 map. If this is the case
relocate it to a new area unused up to now and compliant to the E820
map.
As the p2m list might by huge (up to several GB) and is required to be
mapped virtuall
Use the newest headers from the xen tree to get some new structure
layouts.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/include/asm/xen/interface.h | 96
include/xen/interface/xen.h | 10 ++--
2 files changed, 93 insertions(+
Instead of using a function local static e820 map in xen_memory_setup()
and calling various functions in the same source with the map as a
parameter use a map directly accessible by all functions in the source.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/xen/setup.c | 96
Support 64 bit pv-domains with more than 512GB of memory.
Tested with 64 bit dom0 on machines with 8GB and 1TB and 32 bit dom0 on a
8GB machine. Conflicts between E820 map and different hypervisor populated
memory areas have been tested via a fake E820 map reserved area on the
8GB machine.
Change
Check whether the initrd is placed at a location which is conflicting
with the target E820 map. If this is the case relocate it to a new
area unused up to now and compliant to the E820 map.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/xen/setup.c | 51
Provide a service routine to check a physical memory area against the
E820 map. The routine will return false if the complete area is RAM
according to the E820 map and true otherwise.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86/xen/setup.c | 23 +++
Cleanup by removing arch/x86/xen/p2m.h as it isn't needed any more.
Most definitions in this file are used in p2m.c only. Move those into
p2m.c.
set_phys_range_identity() is already declared in
arch/x86/include/asm/xen/page.h, add __init annotation there.
MAX_REMAP_RANGES isn't used at all, just
Direct Xen to place the initial P->M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
restriction on the size of the initial mapping limits the amount
of memory a domain can be handed initially.
As the initial P->M table is copied rather early during bo
64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and event
Memory pages in the initial memory setup done by the Xen hypervisor
conflicting with the target E820 map are remapped. In order to do this
those pages are counted and remapped in xen_set_identity_and_remap().
Split the counting from the remapping operation to be able to setup
the needed memory siz
Checks whether the pre-allocated memory of the loaded kernel is in
conflict with the target memory map. If this is the case, just panic
instead of run into problems later, as there is nothing we can do
to repair this situation.
Signed-off-by: Juergen Gross
Reviewed-by: David Vrabel
---
arch/x86
During early boot as Xen pv domain the kernel needs to map some page
tables supplied by the hypervisor read only. This is needed to be
able to relocate some data structures conflicting with the physical
memory map especially on systems with huge RAM (above 512GB).
Provide the function early_memrem
For being able to relocate pre-allocated data areas like initrd or
p2m list it is mandatory to find a contiguous memory area which is
not yet in use and doesn't conflict with the memory map we want to
be in effect.
In case such an area is found reserve it at once as this will be
required to be don
Check whether the page tables built by the domain builder are at
memory addresses which are in conflict with the target memory map.
If this is the case just panic instead of running into problems
later.
Signed-off-by: Juergen Gross
---
arch/x86/xen/mmu.c | 19 ---
arch/x86/xe
Hi Wei,
This is Zhang Yu from Intel graphic virtualization team. Previously
in Xen hackathon, Paul and I mentioned that there're several patch
series for XenGT that need to be tracked on Xen 4.6.
Here, I'd like to confirm with you about these patchsets:
1> 16-byte MMIO emulation fix – ow
On 04/30/2015 06:39 PM, Jeremy Fitzhardinge wrote:
On 04/30/2015 03:53 AM, Juergen Gross wrote:
Paravirtualized spinlocks produce some overhead even if the kernel is
running on bare metal. The main reason are the more complex locking
and unlocking functions. Especially unlocking is no longer jus
Hi Ian,
On Sat, May 2, 2015 at 12:36 AM, Ian Jackson wrote:
> SATA controllers support SATA disks. The kernel should be able to
Do you mean SAS controllers?
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
__
On Sat, May 02, Wei Liu wrote:
> Ergh... George might have an idea of the bug you met.
>
> I'm not in favour of short-circuiting code like this. If this is really
> necessary please either delete dead code or use #ifdef 0 with proper
> comment.
I will drop that change for now.
Olaf
___
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Friday, March 27, 2015 3:29 AM
> To: Wu, Feng
> Cc: xen-devel@lists.xen.org; Zhang, Yang Z; Tian, Kevin; k...@xen.org;
> jbeul...@suse.com
> Subject: Re: [Xen-devel] [RFC v1 05/15] vmx: Initialize V
Yang,
Thanks for your review.
On 2015/5/4 12:07, Zhang, Yang Z wrote:
Chen, Tiejun wrote on 2015-05-04:
While initializing VT-D we should mask interrupt message generation
to avoid receiving any interrupt as pending before enable DMA
translation, and also mask that before disable DMA engine.
flight 53021 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/53021/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 11 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 11 guest-start
Dear all, Xenmaintains an address mapping table. How it works? How to map
independent pfn tomachine dependent frame number (mfn) for each guest VM on
real platform?
if physical page is copied from one to second system as per its same pfn
number then how would we know the same on real Xen set
Chen, Tiejun wrote on 2015-05-04:
> While initializing VT-D we should mask interrupt message generation
> to avoid receiving any interrupt as pending before enable DMA
> translation, and also mask that before disable DMA engine.
>
> Signed-off-by: Tiejun Chen
> ---
> xen/drivers/passthrough/vtd/
Chen, Tiejun wrote on 2015-05-04:
> clflush is a light weight but not serializing instruction, so hence
> memory fence is necessary to make sure all load/store visible before flush
> cache line.
>
> Signed-off-by: Tiejun Chen
Acked-by: Yang Zhang
> ---
> xen/drivers/passthrough/vtd/x86/vtd.c
Introduce helper function irq_data_get_affinity_mask() and
irq_get_affinity_mask() to hide implementation details,
so we could move field 'affinity' from struct irq_data into
struct irq_common_data later.
Signed-off-by: Jiang Liu
---
arch/alpha/kernel/irq.c |2 +-
arch/arm/
While initializing VT-D we should mask interrupt message generation
to avoid receiving any interrupt as pending before enable DMA
translation, and also mask that before disable DMA engine.
Signed-off-by: Tiejun Chen
---
xen/drivers/passthrough/vtd/iommu.c | 31 +++
1
S5 menas we also shut down IOMMU engine as well, so we should
disable IOMMU engine completely before enter S5, otherwise we
still probably receive some interrupts in this period. But
currently VT-D path depends on force_iommu and iommu_intremap
to determine if we should disable translation and queu
clflush is a light weight but not serializing instruction, so
hence memory fence is necessary to make sure all load/store
visible before flush cache line.
Signed-off-by: Tiejun Chen
---
xen/drivers/passthrough/vtd/x86/vtd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/drivers/passth
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, May 01, 2015 7:07 PM
> To: ian.jack...@eu.citrix.com
> Cc: Hu, Robert; Pang, LongtaoX; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH OSSTEST v5 04/24] Debian: refactor code to add
> pres
Just make this readable while debug.
Signed-off-by: Tiejun Chen
---
xen/arch/x86/apic.c | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c
index 3217bdf..0b21ed1 100644
--- a/xen/arch/x86/apic.c
+++ b/
В Fri, 10 Apr 2015 10:32:15 +0800
Fu Wei пишет:
> Hi everybody,
> any suggestion for my patchset?
> Please let me know if there are some place need to be fixed or improved, if
> these patches look good to you, can they be merged?
>
> Any feedback or suggestion is welcome! :-)
> Great thanks !
>
flight 53013 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/53013/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken REGR. vs. 50391
test-amd64-i386-fre
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 01 May 2015 20:19
> To: Andrew Cooper; Paul Durrant
> Cc: xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH v2 1/3] x86/hvm: give HVMOP_set_param and
> HVMOP_get_param their own functions
>
> >>>
Hi
does xen establish a secure (encrypted) channel via ssh to transfer data in
live migration?
I'm using xen 4.4 hypervisor and when trying to live migrate a domU guest
to another physical machine, it establishes ssh connection to the
destination. does it mean that the memory content of the VM tra
38 matches
Mail list logo
