From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, November 12, 2014 5:57 PM
On 12.11.14 at 10:13, tiejun.c...@intel.com wrote:
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45, tiejun.c...@intel.com wrote:
#2 flags field in each specific device of new domctl
From: Tian, Kevin
Sent: Wednesday, November 19, 2014 4:18 PM
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, November 12, 2014 5:57 PM
On 12.11.14 at 10:13, tiejun.c...@intel.com wrote:
On 2014/11/12 17:02, Jan Beulich wrote:
On 12.11.14 at 09:45, tiejun.c
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, November 20, 2014 4:04 PM
On 20.11.14 at 08:45, kevin.t...@intel.com wrote:
Yang and I did some discussion here. We understand your point to
avoid introducing new interface if we can leverage existing code.
However it's not a
From: Tian, Kevin
Sent: Thursday, November 20, 2014 4:51 PM
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, November 20, 2014 4:04 PM
On 20.11.14 at 08:45, kevin.t...@intel.com wrote:
Yang and I did some discussion here. We understand your point to
avoid introducing
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
This should be based on a new parameter globally, 'pci_rdmforce'.
pci_rdmforce = 1 = Of course this should be 0 by default.
'1' means we should force check to reserve all ranges. If failed
VM wouldn't be created successfully.
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
After we intend to expost that hypercall explicitly based on
XEN_DOMCTL_set_rdm, we need this rebase. I hope we can squash
this into that previous patch once Jan Ack this.
better to merge together, since it's the right thing to do
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
In case of reserved device memory overlapping with ram, it also probably
overlap with modules space so we need to check these reserved device
memory as well.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
Reviewed-by: Kevin
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
We need to check to reserve all reserved device memory maps in e820
to avoid any potential guest memory conflict.
Currently, if we can't insert RDM entries directly, we may need to handle
several ranges as follows:
a. Fixed
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
In some cases like igd_opregion_pgbase, guest will use mem_hole_alloc
to allocate some memory to use in runtime cycle, so we alsoe need to
make sure all reserved device memory don't overlap such a region.
OK, seems you meant to use
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
We need to reject to populate reserved device memory mapping, and
then make sure all reserved device memory can't be accessed by any
!iommu approach.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/arch/x86/mm/p2m.c
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:25 PM
We always reserve these ranges since we never allow any stuff to
poke them.
But in theory some untrusted VM can maliciously access them. So we
need to intercept this approach. But we just don't want to leak
anything or introduce
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:25 PM
We will create RMRR mapping as follows:
If gfn space unoccupied, we just set that. If
space already occupy by 1:1 RMRR mapping do thing. Others
should be failed.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
Reviewed-by:
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:25 PM
intel_iommu_map_page() does nothing if VT-d shares EPT page table.
So rmrr_identity_mapping() never create RMRR mapping but in some
cases like some GFX drivers it still need to access RMRR.
Here we will create those RMRR mappings
From: Fabio Fantoni [mailto:fabio.fant...@m2r.biz]
Sent: Thursday, December 04, 2014 6:20 PM
Il 04/12/2014 03:45, Jike Song ha scritto:
Hi all,
We're pleased to announce a public release to Intel Graphics
Virtualization Technology (Intel GVT-g, formerly known as XenGT).
Intel GVT-g
From: Donald D. Dugger
Sent: Friday, November 21, 2014 1:12 PM
Currently the quirk code for SandyBridge uses the VTd timeout value when
writing to an IGD register. This is the wrong timeout to use and, at
1000 msec., is also much too large. This patch changes the quirk code
to use a
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, December 05, 2014 12:20 AM
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
We need to check to reserve all reserved device memory maps in e820
to avoid any potential guest memory conflict.
Currently, if we can't insert RDM
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, December 09, 2014 6:50 PM
On 09.12.14 at 11:37, yu.c.zh...@linux.intel.com wrote:
On 12/9/2014 6:19 PM, Paul Durrant wrote:
I think use of an raw mfn value currently works only because dom0 is using
a
1:1 IOMMU mapping
From: Tim Deegan [mailto:t...@xen.org]
Sent: Tuesday, December 09, 2014 6:47 PM
At 18:10 +0800 on 09 Dec (1418145055), Yu, Zhang wrote:
Hi all,
As you can see, we are pushing our XenGT patches to the upstream. One
feature we need in xen is to translate guests' gfn to mfn in XenGT
From: Malcolm Crossley
Sent: Tuesday, December 09, 2014 6:52 PM
On 09/12/14 10:37, Yu, Zhang wrote:
On 12/9/2014 6:19 PM, Paul Durrant wrote:
I think use of an raw mfn value currently works only because dom0 is
using a 1:1 IOMMU mapping scheme. Is my understanding correct, or do
From: Paul Durrant [mailto:paul.durr...@citrix.com]
Sent: Tuesday, December 09, 2014 7:44 PM
-Original Message-
From: Ian Campbell
Sent: 09 December 2014 11:29
To: Paul Durrant
Cc: Tim (Xen.org); Yu, Zhang; Kevin Tian; Keir (Xen.org); jbeul...@suse.com;
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, December 08, 2014 5:13 PM
PVH guests accessing I/O ports via string ops is not supported yet.
Reported-by: Roger Pau Monnéroger@citrix.com
Signed-off-by: Jan Beulich jbeul...@suse.com
Acked-by: Kevin Tian kevin.t...@intel.com
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, December 10, 2014 4:39 PM
On 10.12.14 at 02:07, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, December 09, 2014 6:50 PM
On 09.12.14 at 11:37, yu.c.zh...@linux.intel.com wrote:
From: Tian, Kevin
Sent: Wednesday, December 10, 2014 4:48 PM
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, December 10, 2014 4:39 PM
On 10.12.14 at 02:07, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, December 09, 2014 6
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, December 10, 2014 5:17 PM
On 10.12.14 at 09:47, kevin.t...@intel.com wrote:
two translation paths in assigned case:
1. [direct CPU access from VM], with partitioned PCI aperture
resource, every VM can access a portion of
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, December 10, 2014 5:01 PM
On 10.12.14 at 04:39, kevin.t...@intel.com wrote:
1. It's more efficient for new people to start from a small, well-defined
task
in one area, and then spanning to adjacent areas gradually. Patience
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, December 10, 2014 6:36 PM
On 10.12.14 at 02:14, kevin.t...@intel.com wrote:
From: Tim Deegan [mailto:t...@xen.org]
It's been suggested before that we should revive this hypercall, and I
don't think it's a good idea.
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: Wednesday, December 10, 2014 6:11 PM
On Wed, 2014-12-10 at 01:48 +, Tian, Kevin wrote:
I'm not familiar with Arm architecture, but based on a brief reading it's
for the assigned case where the MMU is exclusive owned by a VM, so
From: Tim Deegan [mailto:t...@xen.org]
Sent: Wednesday, December 10, 2014 7:12 PM
Hi Kevin,
Thanks for taking the time to work through this.
At 03:39 + on 10 Dec (1418179184), Tian, Kevin wrote:
1. It's more efficient for new people to start from a small, well-defined
task
From: Tim Deegan
Sent: Friday, December 12, 2014 12:47 AM
Hi,
At 01:41 + on 11 Dec (1418258504), Tian, Kevin wrote:
From: Tim Deegan [mailto:t...@xen.org]
It is Xen's job to isolate VMs from each other. As part of that, Xen
uses the MMU, nested paging, and IOMMUs to control
From: Tian, Kevin
Sent: Friday, December 12, 2014 2:30 PM
Conclusion
--
That's enough rambling from me -- time to come back down to earth.
While I think it's useful to think about all these things, we don't
want to get carried away. :) And as I said, for some things we can
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, December 12, 2014 6:54 PM
On 12.12.14 at 08:24, kevin.t...@intel.com wrote:
- is there existing _map_ call for this purpose per your knowledge, or
a new one is required? If the latter, what's the additional logic to be
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, December 15, 2014 5:23 PM
On 15.12.14 at 10:05, kevin.t...@intel.com wrote:
yes, definitely host RAM is the upper limit, and what I'm concerning here
is how to reserve (at boot time) or allocate (on-demand) such large PFN
I'll work out a new design proposal based on below content and previous
discussions. Thanks Tiejun for your hard-working and Jan for your careful
reviews so far.
For below comment:
Also there's clearly an alternative proposal: Drop support for sharing
page tables. Your colleagues will surely
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, December 19, 2014 7:26 PM
This can (and will) be legitimately the case when sharing page tables
with EPT (more of a problem before p2m_access_rwx became zero, but
still possible even now when other than that is the default for a
From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
Sent: Friday, January 30, 2015 5:47 AM
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control
mechanism
is introduced via the domctl hypercall:
From: Li, Liang Z
Sent: Wednesday, February 04, 2015 11:28 AM
Flushing cache is needed only when guest has IOMMU device, using
need_iommu(d) can minimize the impact to guest with device assigned,
since a guest may be hot plugged with a device thus there may be dirty
cache lines before
From: Tamas K Lengyel [mailto:tamas.leng...@zentific.com]
Sent: Friday, January 30, 2015 5:47 AM
To avoid growing hvm.c these functions can be stored
separately.
Signed-off-by: Tamas K Lengyel tamas.leng...@zentific.com
VMX changes are clearly renaming:
Acked-by: Kevin Tian
From: Zhang, Yang Z
Sent: Wednesday, February 04, 2015 1:54 PM
Tian, Kevin wrote on 2015-02-04:
From: Li, Liang Z
Sent: Wednesday, February 04, 2015 11:28 AM
Flushing cache is needed only when guest has IOMMU device, using
need_iommu(d) can minimize the impact to guest with device
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 19, 2015 9:52 PM
On 19.01.15 at 13:23, t...@xen.org wrote:
At 11:41 + on 19 Jan (1421664109), Jan Beulich wrote:
On 19.01.15 at 12:33, t...@xen.org wrote:
FWIW, I don't like adding hypervisor state (and even more
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 4:43 PM
On 20.01.15 at 01:52, kevin.t...@intel.com wrote:
We may make a reasonable simplification to treat all RMRRs 1MB as
conflicts (all real observations so far are in BIOS region).
I'm not really agreeing
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 3:29 PM
On 20.01.15 at 01:45, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
The proposed new hypercall represents _only_ reserved regions.
But it was said several times that making
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 21, 2015 6:31 PM
Yes, it's true. But I still don't understand why to do the flush_all just
when
iommu_enable is true. Could you explain why ?
The question you raise doesn't reflect what the function does: It
From: Li, Liang Z
Sent: Thursday, January 22, 2015 12:29 PM
-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 21, 2015 7:22 PM
To: Li, Liang Z
Cc: Andrew Cooper; Dong, Eddie; Tian, Kevin; Zhang, Yang Z; xen-
de...@lists.xen.org; k
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 7:08 PM
..., yielding better code.
Signed-off-by: Jan Beulich jbeul...@suse.com
Acked-by: Kevin Tian kevin.t...@intel.com
___
Xen-devel mailing list
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 7:08 PM
Most of them have been unused since the dropping of 32-bit support, and
the few remaining cases are more efficiently dealt with using a generic
macro (and probably things should have been done that way from
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 7:07 PM
A few relevant control state fields did not get dumped so far; in
particular, VM_ENTRY_INSTRUCTION_LEN got printed twice (instead of also
printing VM_EXIT_INSTRUCTION_LEN). Where suitable (to reduce the
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 7:06 PM
A few host state fields did not get dumped so far. Where suitable (to
reduce the amount of output) make some of the dumping conditional upon
guest settings (this isn't required for correctness as vmr()
From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
Sent: Thursday, January 22, 2015 4:53 AM
need_iommu has to be set earler for dom0 pvh specific init
functions. If not enabled, mmio regions are not mapped with iommu
during domain construction.
This was discovered when working on
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 19, 2015 5:33 PM
On 18.01.15 at 09:58, kevin.t...@intel.com wrote:
still one open to hear suggestion though, regarding to how we want
to pass the reserved regions to domain builder and hvmloader (for Xen
we will extend
From: George Dunlap [mailto:george.dun...@eu.citrix.com]
Sent: Thursday, January 15, 2015 2:22 AM
On 01/14/2015 02:42 PM, Jan Beulich wrote:
On 14.01.15 at 13:29, george.dun...@eu.citrix.com wrote:
On 01/14/2015 08:06 AM, Tian, Kevin wrote:
We discussed earlier there are two reasons
From: George Dunlap [mailto:george.dun...@eu.citrix.com]
Sent: Wednesday, January 14, 2015 8:23 PM
On 01/14/2015 12:14 PM, Ian Campbell wrote:
On Wed, 2015-01-14 at 06:52 +, Tian, Kevin wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 12:06 AM
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Thursday, January 15, 2015 4:43 AM
On Wed, Jan 14, 2015 at 08:13:14AM +, Tian, Kevin wrote:
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Wednesday, January 14, 2015 12:46 AM
Perhaps
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 11:08 PM
On 14.01.15 at 13:17, ian.campb...@citrix.com wrote:
On Wed, 2015-01-14 at 08:06 +, Tian, Kevin wrote:
- RMRRs conflicting with guest BIOS in 1MB area, as an example of
hard conflicts
OOI
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, January 15, 2015 4:38 PM
On 14.01.15 at 19:29, george.dun...@eu.citrix.com wrote:
Just to be clear -- what we're talking about here is that at the
do_domain_create() level (called by libxl_domain_create_new()), it will
take a
From: Li, Liang Z
Sent: Friday, January 23, 2015 1:55 PM
On 22.01.15 at 08:44, yang.z.zh...@intel.com wrote:
Tian, Kevin wrote on 2015-01-22:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 21, 2015 6:31 PM
Yes, it's true. But I still don't understand
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, January 22, 2015 10:01 PM
... making the code better document itself. No functional change
intended.
Signed-off-by: Jan Beulich jbeul...@suse.com
Acked-by: Kevin Tian kevin.t...@intel.com
From: George Dunlap
Sent: Tuesday, January 20, 2015 8:57 PM
On Tue, Jan 20, 2015 at 12:52 AM, Tian, Kevin kevin.t...@intel.com wrote:
For RMRRs in the BIOS area, libxl will already need to know where that
area is (to know that it doesn't need to fit it into the MMIO hole); if
we just
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 20, 2015 6:49 PM
On 20.01.15 at 11:38, ian.campb...@citrix.com wrote:
On Tue, 2015-01-20 at 09:10 +, Jan Beulich wrote:
On 20.01.15 at 09:59, kevin.t...@intel.com wrote:
From: Jan Beulich
From: George Dunlap
Sent: Thursday, January 15, 2015 7:45 PM
If above high level flow can be agreed, then we can move forward to
discuss next level detail e.g. how to pass the rmrr list cross different
components. :-)
I think we're definitely ready to move on. There are a bunch of
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, January 15, 2015 6:06 PM
The composed reserved region list is then passed to domain builder,
which tries to detect and avoid conflicts when populating guest RAM.
To avoid breaking lowmem/highmem layout, we can define a
From: Kai Huang [mailto:kai.hu...@linux.intel.com]
Sent: Thursday, February 12, 2015 10:39 AM
PML needs to be enabled (allocate PML buffer, initialize PML index,
PML base address, turn PML on VMCS, etc) for all vcpus of the domain,
as PML buffer and PML index are per-vcpu, but EPT table
From: Kai Huang [mailto:kai.hu...@linux.intel.com]
Sent: Thursday, February 12, 2015 2:46 PM
On 02/12/2015 02:25 PM, Tian, Kevin wrote:
From: Kai Huang [mailto:kai.hu...@linux.intel.com]
Sent: Thursday, February 12, 2015 10:35 AM
On 02/11/2015 09:13 PM, Jan Beulich wrote
From: Tim Deegan [mailto:t...@xen.org]
Sent: Thursday, February 12, 2015 8:42 PM
At 07:08 + on 12 Feb (1423721283), Tian, Kevin wrote:
for general log dirty, ept_invalidate_emt is required because there is
access permission change (dirtied page becomes rw after 1st fault,
so need
From: Don Slutz [mailto:dsl...@verizon.com]
Sent: Tuesday, January 27, 2015 4:31 AM
The question is about the VM-exit instruction length field.
This is accessed in xen via:
__vmread(VM_EXIT_INSTRUCTION_LEN, inst_len);
an example of which is in routine get_instruction_length().
From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
Sent: Tuesday, January 27, 2015 1:31 AM
On Mon, Jan 26, 2015 at 05:06:12PM +, Jan Beulich wrote:
On 26.01.15 at 17:57, elena.ufimts...@oracle.com wrote:
On Fri, Jan 23, 2015 at 10:50:23AM +, Jan Beulich wrote:
On
From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
Sent: Tuesday, January 27, 2015 11:06 PM
On Tue, Jan 27, 2015 at 06:41:39AM +, Tian, Kevin wrote:
From: Elena Ufimtseva [mailto:elena.ufimts...@oracle.com]
Sent: Tuesday, January 27, 2015 1:31 AM
On Mon, Jan 26, 2015
From: George Dunlap
Sent: Monday, January 05, 2015 11:50 PM
On Fri, Dec 12, 2014 at 6:29 AM, Tian, Kevin kevin.t...@intel.com wrote:
We're not there in the current design, purely because XenGT has to be
in dom0 (so it can trivially DoS Xen by rebooting the host).
Can we really
From: Tim Deegan [mailto:t...@xen.org]
Sent: Thursday, December 18, 2014 11:47 PM
Hi,
At 07:24 + on 12 Dec (1418365491), Tian, Kevin wrote:
I'm afraid not. There's nothing worrying per se in a backend knowing
the MFNs of the pages -- the worry is that the backend can pass
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 5:33 PM
On 12.01.15 at 09:46, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, January 09, 2015 6:35 PM
On 09.01.15 at 11:10, kevin.t...@intel.com wrote:
From: Jan
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, January 09, 2015 6:46 PM
On 09.01.15 at 11:26, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
On 09.01.15 at 07:57, kevin.t...@intel.com wrote:
1.1) per-device 'warn' vs. global 'warn'
Both
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, January 09, 2015 6:35 PM
On 09.01.15 at 11:10, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Boot time device assignment is different: The question isn't whether
an assigned device works, instead the
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Saturday, January 10, 2015 4:28 AM
On Thu, Jan 08, 2015 at 06:02:04PM +, George Dunlap wrote:
On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich jbeul...@suse.com wrote:
On 08.01.15 at 16:59, dunl...@umich.edu wrote:
On
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: Monday, January 12, 2015 9:42 PM
On Fri, 2015-01-09 at 06:57 +, Tian, Kevin wrote:
3) report-sel vs. report-all
One thing I'm not clear on is whether you are suggesting to reserve RMRR
(either -all or -sel) for every domain
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 5:51 PM
On 12.01.15 at 10:41, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 5:33 PM
On 12.01.15 at 09:46, kevin.t...@intel.com wrote:
From: Jan
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 7:37 PM
On 12.01.15 at 12:22, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 6:23 PM
One of my main problems with all you recent argumentation here
is
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 8:03 PM
On 12.01.15 at 12:41, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 7:37 PM
On 12.01.15 at 12:22, kevin.t...@intel.com wrote:
From: Jan
From: Tian, Kevin
Sent: Monday, January 12, 2015 8:29 PM
From: George Dunlap
Sent: Monday, January 12, 2015 8:14 PM
On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin kevin.t...@intel.com
wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 6:23 PM
From: Stefano Stabellini
Sent: Monday, January 12, 2015 7:36 PM
On Wed, 24 Dec 2014, Liang Li wrote:
Use the 'xl pci-attach $DomU $BDF' command to attach more then
one PCI devices to the guest, then detach the devices with
'xl pci-detach $DomU $BDF', after that, re-attach these PCI
From: George Dunlap
Sent: Monday, January 12, 2015 8:14 PM
On Mon, Jan 12, 2015 at 11:22 AM, Tian, Kevin kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Monday, January 12, 2015 6:23 PM
On 12.01.15 at 11:12, kevin.t...@intel.com wrote:
From: Jan
From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Thursday, January 08, 2015 11:39 PM
Use the standard do { } while ( 0 ) semantics, and don't hide the break
statement, incase this macro wants to be used anywhere outside of a switch.
No functional change, but it is now clear
From: George Dunlap
Sent: Friday, January 09, 2015 12:00 AM
3.3 Policies
An intuitive thought is to fail immediately upon a confliction, however
it is not flexible regarding to different requirments:
a) it's not appropriate to fail libxc domain builder just because such
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, January 08, 2015 8:59 PM
On 08.01.15 at 13:49, george.dun...@eu.citrix.com wrote:
One question: where are these RMRRs typically located in memory? Are
they normally up in the MMIO region? Or can they occur anywhere (even
in
From: George Dunlap
Sent: Friday, January 09, 2015 2:02 AM
On Thu, Jan 8, 2015 at 4:10 PM, Jan Beulich jbeul...@suse.com wrote:
On 08.01.15 at 16:59, dunl...@umich.edu wrote:
On Thu, Jan 8, 2015 at 1:54 PM, Jan Beulich jbeul...@suse.com wrote:
the 1st invocation of this interface will
with above major opens. will include them in next version
after above high level opens are closed)
Thanks
Kevin
From: Tian, Kevin
Sent: Friday, December 26, 2014 7:23 PM
(please note some proposal is different from last sent version after more
discussions. But I tried to summarize previous
From: Tim Deegan [mailto:t...@xen.org]
Sent: Thursday, January 08, 2015 8:43 PM
Hi,
Not really. The IOMMU tables are also 64-bit so there must be enough
addresses to map all of RAM. There shouldn't be any need for these
mappings to be _contiguous_, btw. You just need to have one
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, January 09, 2015 5:46 PM
On 09.01.15 at 07:57, kevin.t...@intel.com wrote:
1) 'fail' vs. 'warn' upon gfn confliction
Assigning device which fails RMRR confliction check (i.e. intended gfns
already allocated for other
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Tuesday, January 06, 2015 12:33 AM
On Thu, Dec 18, 2014 at 01:06:40PM -0500, Boris Ostrovsky wrote:
We need to make sure that last_vcpu is not pointing to VCPU whose
VPMU is being destroyed. Otherwise we may try to
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 12:06 AM
On 13.01.15 at 17:00, george.dun...@eu.citrix.com wrote:
Another option I was thinking about: Before assigning a device to a
guest, you have to unplug the device and assign it to pci-back (e.g.,
From: George Dunlap [mailto:george.dun...@eu.citrix.com]
Sent: Tuesday, January 13, 2015 11:59 PM
On 01/13/2015 03:52 PM, Jan Beulich wrote:
On 13.01.15 at 13:03, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 13, 2015 7:56 PM
On
From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
Sent: Wednesday, January 14, 2015 12:46 AM
Perhaps an easier way of this is to use the existing
mechanism we have - that is the XENMEM_memory_map (which
BTW e820_host uses). If all of this is done in the libxl (which
already
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Tuesday, January 13, 2015 7:56 PM
On 13.01.15 at 12:03, kevin.t...@intel.com wrote:
Then I hope you understand now about our discussion in libxl/xen/
hvmloader, based on the fact that conflict may not be avoided.
That's the major open
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, January 09, 2015 5:21 PM
On 09.01.15 at 03:27, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, January 08, 2015 9:55 PM
On 26.12.14 at 12:23, kevin.t...@intel.com wrote:
3)
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, January 08, 2015 9:55 PM
On 26.12.14 at 12:23, kevin.t...@intel.com wrote:
[Issue-2] Being lacking of goal-b), existing device assignment with
RMRR works only when reserved regions happen to not conflicting with
other valid
+ on 26 Dec (1419589382), Tian, Kevin wrote:
c) in Xen hypervisor it is reasonable to fail upon confliction, where
device is actually assigned. But due to the same requirement on USB
controller, sometimes we might want it succeed just w/ warnings.
Can you explain more concretely why we
From: George Dunlap
Sent: Thursday, January 08, 2015 8:55 PM
On Thu, Jan 8, 2015 at 12:49 PM, George Dunlap
george.dun...@eu.citrix.com wrote:
If RMRRs almost always happen up above 2G, for example, then a simple
solution that wouldn't require too much work would be to make sure
that
From: George Dunlap
Sent: Thursday, January 08, 2015 8:50 PM
On Fri, Dec 26, 2014 at 11:23 AM, Tian, Kevin kevin.t...@intel.com wrote:
(please note some proposal is different from last sent version after more
discussions. But I tried to summarize previous discussions and explained why
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 6:24 PM
On 14.01.15 at 10:43, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 5:00 PM
On 14.01.15 at 09:06, kevin.t...@intel.com wrote:
Now
From: George Dunlap [mailto:george.dun...@eu.citrix.com]
Sent: Wednesday, January 14, 2015 8:02 PM
On 01/14/2015 10:24 AM, Jan Beulich wrote:
On 14.01.15 at 10:43, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 14, 2015 5:00 PM
On
From: Kai Huang [mailto:kai.hu...@linux.intel.com]
Sent: Thursday, February 12, 2015 10:35 AM
On 02/11/2015 09:13 PM, Jan Beulich wrote:
On 11.02.15 at 12:52, andrew.coop...@citrix.com wrote:
On 11/02/15 08:28, Kai Huang wrote:
With PML, we don't have to use write protection but just
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Wednesday, January 07, 2015 6:16 PM
On 23.12.14 at 07:52, kevin.t...@intel.com wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Friday, December 19, 2014 7:26 PM
This can (and will) be legitimately the case when sharing
1 - 100 of 876 matches
Mail list logo
