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 –
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
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
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
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
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 jgr...@suse.com
---
arch/x86/xen/mmu.c | 19
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 jgr...@suse.com
Reviewed-by: David
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 jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
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 jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
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
Use the newest headers from the xen tree to get some new structure
layouts.
Signed-off-by: Juergen Gross jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/include/asm/xen/interface.h | 96
include/xen/interface/xen.h | 10
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,
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 jgr...@suse.com
Reviewed-by: David Vrabel
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 jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c | 10 +++---
1 file
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.
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
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
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
translation, and
On 30.04.15 at 17:44, david.vra...@citrix.com wrote:
On 23/04/15 13:42, David Vrabel wrote:
On 21/04/15 11:22, Jan Beulich wrote:
On 21.04.15 at 12:11, david.vra...@citrix.com wrote:
We have analysed the affect of this series on interrupt latency (by
measuring the duration of irq
From: Tim Deegan [mailto:t...@xen.org]
Sent: Thursday, April 30, 2015 7:04 PM
At 16:19 +0800 on 24 Apr (1429892368), Kai Huang wrote:
v2-v3:
- Merged v2 patch 02 (document change) to patch 01 as a single patch, and
changed new parameter description as suggested by Andrew.
-
On 04/27/2015 02:56 PM, Jan Beulich wrote:
Kai Huang kaih.li...@gmail.com 04/25/15 5:00 PM
On Fri, Apr 24, 2015 at 10:33 PM, Jan Beulich jbeul...@suse.com wrote:
On 24.04.15 at 10:19, kai.hu...@linux.intel.com wrote:
+}
+
+custom_param(ept, parse_ept_param);
And a superfluous blank line
On 05/04/2015 03:40 PM, Tian, Kevin wrote:
From: Tim Deegan [mailto:t...@xen.org]
Sent: Thursday, April 30, 2015 7:04 PM
At 16:19 +0800 on 24 Apr (1429892368), Kai Huang wrote:
v2-v3:
- Merged v2 patch 02 (document change) to patch 01 as a single patch, and
changed new parameter
While I got a review from Andrew, I'm still waiting for an ack (or nak).
Thanks, Jan
On 22.04.15 at 13:56, jbeul...@suse.com wrote:
Instead saturate the value if the input can't be represented in the
respective struct domain field.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
On 04.05.15 at 09:46, kai.hu...@linux.intel.com wrote:
On 04/27/2015 02:56 PM, Jan Beulich wrote:
Kai Huang kaih.li...@gmail.com 04/25/15 5:00 PM
On Fri, Apr 24, 2015 at 10:33 PM, Jan Beulich jbeul...@suse.com wrote:
On 24.04.15 at 10:19, kai.hu...@linux.intel.com wrote:
+}
+
On 05/04/2015 03:52 PM, Jan Beulich wrote:
On 04.05.15 at 09:46, kai.hu...@linux.intel.com wrote:
On 04/27/2015 02:56 PM, Jan Beulich wrote:
Kai Huang kaih.li...@gmail.com 04/25/15 5:00 PM
On Fri, Apr 24, 2015 at 10:33 PM, Jan Beulich jbeul...@suse.com wrote:
On 24.04.15 at 10:19,
On 04.05.15 at 04:03, tiejun.c...@intel.com wrote:
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1319,28 +1319,37 @@ out: ;
* This interrupt should never happen with our APIC/SMP architecture
*/
+static const char *apic_fault_reasons[] =
If at all, then this should be
On 04.05.15 at 07:32, feng...@intel.com wrote:
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Friday, March 27, 2015 3:29 AM
On Wed, Mar 25, 2015 at 08:31:47PM +0800, Feng Wu wrote:
+v-arch.hvm_vmx.pi_desc.ndm = 0;
+dest = cpu_physical_id(v-processor);
+
+
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, April 23, 2015 10:00 PM
On 23.04.15 at 14:32, tiejun.c...@intel.com wrote:
On 2015/4/16 23:40, Tim Deegan wrote:
At 17:21 +0800 on 10 Apr (1428686518), Tiejun Chen wrote:
@@ -1851,7 +1857,14 @@ static int
Oops, just detected that I missed to send this to lkml, too.
Will resend.
Juergen
On 05/04/2015 08:18 AM, Juergen Gross wrote:
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
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 jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
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 jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/xen/p2m.c | 10 +++---
1 file
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
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.
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
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
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,
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 jgr...@suse.com
Reviewed-by: David
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
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
Jan Beulich wrote on 2015-05-04:
On 04.05.15 at 11:14, andrew.coop...@citrix.com wrote:
On 04/05/2015 09:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@
From: Chen, Tiejun
Sent: Monday, May 04, 2015 7:26 PM
On 2015/5/4 18:52, Tian, Kevin wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, May 04, 2015 6:44 PM
On 04.05.15 at 12:39, tiejun.c...@intel.com wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at
All accepted.
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, May 4, 2015 10:01 PM
To: Han, Huaitong
Cc: xen-devel@lists.xen.org
Subject: Re: [V2] x86/cpuidle: get accurate C0 value with xenpm tool
On 04.05.15 at 15:23, huaitong@intel.com wrote:
On
On 2015/5/4 18:43, Jan Beulich wrote:
On 04.05.15 at 12:39, tiejun.c...@intel.com wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned
-Original Message-
From: Stefan Berger [mailto:stef...@linux.vnet.ibm.com]
Sent: Monday, May 04, 2015 11:36 PM
To: Xu, Quan; stefano.stabell...@eu.citrix.com; ebl...@redhat.com
Cc: qemu-de...@nongnu.org; wei.l...@citrix.com; dgde...@tycho.nsa.gov;
xen-devel@lists.xen.org
Subject:
On 2015/5/4 16:25, Andrew Cooper wrote:
On 04/05/2015 03:03, Tiejun Chen wrote:
Just make this readable while debug.
debugging
Fixed.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
In principle, I fully agree with the change. (I had an item on my todo
list to make a change like
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 jgr...@suse.com
---
arch/x86/xen/mmu.c | 19
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 jgr...@suse.com
Reviewed-by: David Vrabel
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
Use the newest headers from the xen tree to get some new structure
layouts.
Signed-off-by: Juergen Gross jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
arch/x86/include/asm/xen/interface.h | 96
include/xen/interface/xen.h | 10
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 jgr...@suse.com
Reviewed-by: David Vrabel david.vra...@citrix.com
---
On 04/05/2015 06:32, Wu, Feng wrote:
+v-arch.hvm_vmx.pi_desc.ndm = 0;
+dest = cpu_physical_id(v-processor);
+
+if ( x2apic_enabled )
+v-arch.hvm_vmx.pi_desc.ndst = dest;
+else
+v-arch.hvm_vmx.pi_desc.ndst = (dest 8) 0xFF00;
Surely there are some macros
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned int get_cache_line_size(void)
void cacheline_flush(char * addr)
{
+mb();
clflush(addr);
+mb();
}
I
On 04.05.15 at 07:08, tiejun.c...@intel.com wrote:
At first I doubted this is issued by some improper cache behaviors.
Because as you see, root_entry[0] = 80f5001 indicates we already set
that present bit. But Caching Mode bit is zero in BDW so this means
remapping hardware doesn't own
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
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
On 02/05/15 03:00, osstest service user wrote:
flight 52955 rumpuserxen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/52955/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 5 rumpuserxen-build
-Original Message-
From: Andrew Cooper [mailto:am...@hermes.cam.ac.uk] On Behalf Of
Andrew Cooper
Sent: Monday, May 04, 2015 4:36 PM
To: Wu, Feng; Konrad Rzeszutek Wilk
Cc: Tian, Kevin; xen-devel@lists.xen.org; jbeul...@suse.com; Zhang, Yang Z;
k...@xen.org
Subject: Re:
On 04/05/2015 09:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned int get_cache_line_size(void)
void cacheline_flush(char * addr)
{
+mb();
(Thanks for trimming the CC list before hand)
On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote:
Hi Wei,
Hello.
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
Hi Fabio
Discussion on a particular bug should be in a separate thread. This
thread is mainly for Xen 4.6 release.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 30.04.15 at 13:18, t...@xen.org wrote:
At 15:31 +0100 on 24 Apr (1429889471), Jan Beulich wrote:
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -1435,6 +1435,14 @@ void sh_install_xen_entries_in_l4(struct
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned int get_cache_line_size(void)
void cacheline_flush(char * addr)
{
+mb();
On 04.05.15 at 12:39, tiejun.c...@intel.com wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned int get_cache_line_size(void)
Xen L4 entries being uniformly installed into any L4 table and 64-bit
PV kernels running in ring 3 means that user mode was able to see the
read-only M2P presented by Xen to the guests. While apparently not
really representing an exploitable information leak, this still very
certainly was never
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, May 04, 2015 6:44 PM
On 04.05.15 at 12:39, tiejun.c...@intel.com wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++
On 04/05/2015 11:54, Jan Beulich wrote:
Xen L4 entries being uniformly installed into any L4 table and 64-bit
PV kernels running in ring 3 means that user mode was able to see the
read-only M2P presented by Xen to the guests. While apparently not
really representing an exploitable information
On 2015/5/4 16:07, Jan Beulich wrote:
On 04.05.15 at 04:03, tiejun.c...@intel.com wrote:
--- a/xen/arch/x86/apic.c
+++ b/xen/arch/x86/apic.c
@@ -1319,28 +1319,37 @@ out: ;
* This interrupt should never happen with our APIC/SMP architecture
*/
+static const char *apic_fault_reasons[] =
On Thu, Apr 16, 2015 at 12:24:58PM +0100, Stefano Stabellini wrote:
Introduce a configure option to disable the in-tree qemu-traditional
build and use an externally provided qemu-dm binary. The option is very
similar to the existing --with-system-qemu-xen.
^
On Thu, Apr 16, 2015 at 12:24:59PM +0100, Stefano Stabellini wrote:
I run ./autogen.sh and committed the result.
This patch needs to be squashed into previous to keep the tree
bisectable.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On 2015/5/4 16:57, Jan Beulich wrote:
On 04.05.15 at 07:08, tiejun.c...@intel.com wrote:
At first I doubted this is issued by some improper cache behaviors.
Because as you see, root_entry[0] = 80f5001 indicates we already set
that present bit. But Caching Mode bit is zero in BDW so this means
On 2015/5/4 18:52, Tian, Kevin wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, May 04, 2015 6:44 PM
On 04.05.15 at 12:39, tiejun.c...@intel.com wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
---
Hi,
On 04/05/2015 12:44, Riku Voipio wrote:
On 27 April 2015 at 19:32, Julien Grall julien.gr...@citrix.com wrote:
Hi Stefano,
On 27/04/15 16:36, Stefano Stabellini wrote:
On Mon, 27 Apr 2015, Julien Grall wrote:
The commit 569fb6c xen/arm: Data abort exception (R/W) mem_access
events makes
make sure QEMU machine class is initialized and QEMU has registered
Xen stubdom vTPM driver when call tpm_init()
Signed-off-by: Quan Xu quan...@intel.com
Reviewed-by: Stefan Berger stef...@linux.vnet.ibm.com
---
vl.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff
This patch adds infrastructure for xen front drivers living in qemu,
so drivers don't need to implement common stuff on their own. It's
mostly xenbus management stuff: some functions to access XenStore,
setting up XenStore watches, callbacks on device discovery and state
changes, and handle event
*INTRODUCTION*
The goal of virtual Trusted Platform Module (vTPM) is to provide a TPM
functionality to virtual machines (Fedora, Ubuntu, Redhat, Windows .etc). This
allows programs to interact with a TPM in a virtual machine the same way they
interact with a TPM on the physical system. Each
and rename it to tpm_util_is_selftest().
Signed-off-by: Quan Xu quan...@intel.com
--Changes in v6:
-Remove the redundant copy right.
-Reduce the includes to its minimum.
---
hw/tpm/Makefile.objs | 2 +-
hw/tpm/tpm_passthrough.c | 13 +
hw/tpm/tpm_util.c
This Patch provides the glue for the TPM_TIS(Qemu frontend) to Xen
stubdom vTPM domain that provides the actual TPM functionality. It
sends data and TPM commends with xen_vtpm_frontend. It is similar as
another two vTPM backens:
*vTPM passthrough backen Since QEMU 1.5.
*vTPM libtpms-based
This patch adds infrastructure for xen front drivers living in qemu,
so drivers don't need to implement common stuff on their own. It's
mostly xenbus management stuff: some functions to access XenStore,
setting up XenStore watches, callbacks on device discovery and state
changes, and handle event
Hi Wei,
Thanks for your reply.
On 5/4/2015 5:44 PM, Wei Liu wrote:
(Thanks for trimming the CC list before hand)
On Mon, May 04, 2015 at 02:05:49PM +0800, Yu, Zhang wrote:
Hi Wei,
Hello.
This is Zhang Yu from Intel graphic virtualization team. Previously in Xen
hackathon, Paul and I
On Thu, Apr 30, 2015 at 7:59 PM, Julien Grall julien.gr...@citrix.com wrote:
Hi,
On 30/04/15 14:47, Stefano Stabellini wrote:
If the devid is not within this range, the ITS won't recognize the value
and
won't be able to send the interrupt.
So this is clearly not the right value.
Sure,
On 04/05/2015 13:58, Vijay Kilari wrote:
On Thu, Apr 30, 2015 at 7:59 PM, Julien Grall julien.gr...@citrix.com wrote:
Hi,
On 30/04/15 14:47, Stefano Stabellini wrote:
If the devid is not within this range, the ITS won't recognize the value and
won't be able to send the interrupt.
So this
I have forgotten to update gitingore. I will update that in my next
version.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Mon, May 4, 2015 at 6:34 PM, Julien Grall julien.gr...@citrix.com wrote:
On 04/05/2015 13:58, Vijay Kilari wrote:
On Thu, Apr 30, 2015 at 7:59 PM, Julien Grall julien.gr...@citrix.com
wrote:
Hi,
On 30/04/15 14:47, Stefano Stabellini wrote:
If the devid is not within this range, the
Hi Vijay,
On 04/05/2015 14:27, Vijay Kilari wrote:
On Mon, May 4, 2015 at 6:34 PM, Julien Grall julien.gr...@citrix.com wrote:
On 04/05/2015 13:58, Vijay Kilari wrote:
On Thu, Apr 30, 2015 at 7:59 PM, Julien Grall julien.gr...@citrix.com
wrote:
Hi,
On 30/04/15 14:47, Stefano Stabellini
On 04/05/2015 14:44, Julien Grall wrote:
Hi Vijay,
On 04/05/2015 14:27, Vijay Kilari wrote:
On Mon, May 4, 2015 at 6:34 PM, Julien Grall julien.gr...@citrix.com
wrote:
On 04/05/2015 13:58, Vijay Kilari wrote:
On Thu, Apr 30, 2015 at 7:59 PM, Julien Grall julien.gr...@citrix.com
wrote:
On 04.05.15 at 15:23, huaitong@intel.com wrote:
On Mon, 2015-05-04 at 09:33 +0100, Jan Beulich wrote:
On 04.05.15 at 08:27, huaitong@intel.com wrote:
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/acpi/cpu_idle.c
@@ -254,9 +254,10 @@ static char* acpi_cstate_method_name[]
On Thu, Apr 30, 2015 at 02:49:26PM -0400, Waiman Long wrote:
On 04/29/2015 02:11 PM, Peter Zijlstra wrote:
On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote:
In the pv_scan_next() function, the slow cmpxchg atomic operation is
performed even if the other CPU is not even close to
At 11:54 +0100 on 04 May (1430740452), Jan Beulich wrote:
Xen L4 entries being uniformly installed into any L4 table and 64-bit
PV kernels running in ring 3 means that user mode was able to see the
read-only M2P presented by Xen to the guests. While apparently not
really representing an
At 08:49 +0100 on 04 May (1430729386), Jan Beulich wrote:
While I got a review from Andrew, I'm still waiting for an ack (or nak).
Acked-by: Tim Deegan t...@xen.org
I expect Coverity will complain on architectures where this isn't
necessary, but acked nonetheless.
Tim.
I changed it to the below; I've not gotten around to compiling or even
running it yet :-(
The biggest change is the pv_hash/pv_unhash functions, which I've
rewritten to hopefully be clearer (and also hopefully not wrecked them).
I took out the cacheline sized structure which takes out that
Commit 61f01dd941ba (x86_64, asm: Work around AMD SYSRET SS descriptor
attribute issue) makes AMD processors set SS to __KERNEL_DS in
__switch_to() to deal with cases when SS is NULL.
This breaks Xen PV guests who do not want to load SS with__KERNEL_DS.
Since the problem that the commit is
On Mon, May 4, 2015 at 7:24 PM, Julien Grall julien.gr...@citrix.com wrote:
On 04/05/2015 14:44, Julien Grall wrote:
Hi Vijay,
On 04/05/2015 14:27, Vijay Kilari wrote:
On Mon, May 4, 2015 at 6:34 PM, Julien Grall julien.gr...@citrix.com
wrote:
On 04/05/2015 13:58, Vijay Kilari wrote:
On Mon, May 04, 2015 at 06:39:56PM +0800, Chen, Tiejun wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@ -56,7 +56,9 @@ unsigned int
On 05/04/2015 03:23 AM, Quan Xu wrote:
This Patch provides the glue for the TPM_TIS(Qemu frontend) to Xen
stubdom vTPM domain that provides the actual TPM functionality. It
sends data and TPM commends with xen_vtpm_frontend. It is similar as
another two vTPM backens:
*vTPM passthrough backen
On 04/05/2015 16:22, Konrad Rzeszutek Wilk wrote:
On Mon, May 04, 2015 at 06:39:56PM +0800, Chen, Tiejun wrote:
On 2015/5/4 16:52, Jan Beulich wrote:
On 04.05.15 at 04:16, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/x86/vtd.c
+++ b/xen/drivers/passthrough/vtd/x86/vtd.c
@@
On 05/04/2015 03:22 AM, Quan Xu wrote:
and rename it to tpm_util_is_selftest().
Signed-off-by: Quan Xu quan...@intel.com
Reviewed-by: Stefan Berger stef...@linux.vnet.ibm.com
Thanks,
Stefan
--Changes in v6:
-Remove the redundant copy right.
-Reduce the includes to its minimum.
---
On 05/04/2015 03:22 AM, Quan Xu wrote:
This patch adds infrastructure for xen front drivers living in qemu,
so drivers don't need to implement common stuff on their own. It's
mostly xenbus management stuff: some functions to access XenStore,
setting up XenStore watches, callbacks on device
Hi Vijay,
On 04/05/2015 16:19, Vijay Kilari wrote:
How did you implement the interrupt mode? Could it be improve?
1) In physical ITS driver its_device is created with devID 00:00.1
with
256 MSI-x are reserved and is named as completion_dev, which is global.
That's a lot of MSI-x
On 05/04/2015 10:20 AM, Peter Zijlstra wrote:
I changed it to the below; I've not gotten around to compiling or even
running it yet :-(
The biggest change is the pv_hash/pv_unhash functions, which I've
rewritten to hopefully be clearer (and also hopefully not wrecked them).
I took out the
On 05/04/2015 10:05 AM, Peter Zijlstra wrote:
On Thu, Apr 30, 2015 at 02:49:26PM -0400, Waiman Long wrote:
On 04/29/2015 02:11 PM, Peter Zijlstra wrote:
On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote:
In the pv_scan_next() function, the slow cmpxchg atomic operation is
performed
Hello Sander,
Monday, April 27, 2015, 5:48:00 PM, you wrote:
Hi David / Konrad,
Here the other problem i found, which is introduced somewhere in the
4.1 mergewindow:
on 4.1.0-rc1 (with the one revert to get things booting) i get this in
the PV Guest console:
[0.517392]
1 - 100 of 102 matches
Mail list logo
