On 2015/6/7 19:06, Wei Liu wrote:
On Wed, Jun 03, 2015 at 09:35:16AM +0800, Chen, Tiejun wrote:
[...]
+reserved regions explicitly. And using "host" to include all reserved regions
+reported on this platform which is good to handle hotplug scenario. In the
+future this parame
On 2015/6/7 19:20, Wei Liu wrote:
On Wed, Jun 03, 2015 at 10:25:47AM +0800, Chen, Tiejun wrote:
[...]
+static struct xen_reserved_device_memory
+*xc_device_get_rdm(libxl__gc *gc,
+ uint32_t flag,
+ uint16_t seg,
+ uint8_t bus
On 2015/6/7 19:27, Wei Liu wrote:
On Wed, Jun 03, 2015 at 10:58:31AM +0800, Chen, Tiejun wrote:
On 2015/6/3 0:36, Wei Liu wrote:
On Fri, May 22, 2015 at 05:35:08PM +0800, Tiejun Chen wrote:
This patch passes rdm reservation policy to xc_assign_device() so the policy
is checked when assigning
On 2015/6/11 15:33, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
We will create this sort of identity mapping as follows:
If the gfn space is unoccupied, we just set the mapping. If the space
is already occupied by 1:1 mappings, do nothing. Failed for any
other cases.
Signed-off-by: Tiejun
On 2015/6/11 16:42, Tian, Kevin wrote:
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: Thursday, June 11, 2015 3:28 PM
On 11.06.15 at 03:15, wrote:
v3:
* Rearrange all patches orderly as Wei suggested
* Rebase on the latest tree
* Address some Wei's comments on tools side
* Two changes fo
On 2015/6/11 17:00, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
We will create this sort of identity mapping as follows:
If the gfn space is unoccupied, we just set the mapping. If the space
is already occupied by 1:1 mappings, do nothing. Failed for any
other
On 2015/6/11 17:23, Jan Beulich wrote:
On 11.06.15 at 10:23, wrote:
On 2015/6/11 15:33, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
We will create this sort of identity mapping as follows:
If the gfn space is unoccupied, we just set the mapping. If the space
is already occupied by 1:1 m
On 2015/6/11 17:14, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
RMRR reserved regions must be setup in the pfn space with an identity
mapping to reported mfn. However existing code has problem to setup
correct mapping when VT-d shares EPT page table, so lead to
On 2015/6/11 20:52, Tim Deegan wrote:
Hi,
At 09:15 +0800 on 11 Jun (1434014109), Tiejun Chen wrote:
* Two changes for runtime cycle
patch #2,xen/x86/p2m: introduce set_identity_p2m_entry, on hypervisor side
a>. Introduce paging_mode_translate()
Otherwise, we'll see this error when bo
On 2015/6/11 22:07, Tim Deegan wrote:
At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
while ( base_pfn < end_pfn )
{
-int err = intel_iommu_map_page(d, base_pfn, base_pfn,
- IOMMUF_readable|IOMMUF_writable);
+int
On 2015/6/12 10:43, Chen, Tiejun wrote:
On 2015/6/11 22:07, Tim Deegan wrote:
At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
while ( base_pfn < end_pfn )
{
-int err = intel_iommu_map_page(d, base_pfn, base_pfn,
-
IOMMUF_readable|IOMMUF_writable);
+
On 2015/6/12 13:59, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Friday, June 12, 2015 1:58 PM
On 2015/6/12 10:43, Chen, Tiejun wrote:
On 2015/6/11 22:07, Tim Deegan wrote:
At 17:31 +0800 on 11 Jun (1434043916), Chen, Tiejun wrote:
while ( base_pfn < end_pfn )
{
-
On 2015/6/11 17:28, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
This patch extends the existing hypercall to support rdm reservation policy.
We return error or just throw out a warning message depending on whether
the policy is "strict" or &quo
On 2015/6/11 17:38, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Now we get this map layout by call XENMEM_memory_map then
save them into one global variable memory_map[]. It should
include lowmem range, rdm range and highmem range. Note
rdm range and highmem
On 2015/6/11 17:51, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
When allocating mmio address for PCI bars, we need to make
sure they don't overlap with reserved regions.
Signed-off-by: Tiejun Chen
---
tools/firmware/hvmloader/pci.c
On 2015/6/11 17:59, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Now we can use that memory map to build our final
e820 table but it may need to reorder all e820
entries.
Signed-off-by: Tiejun Chen
---
tools/firmware/hvmloader/e820.c | 62
On 2015/6/12 16:04, Jan Beulich wrote:
On 12.06.15 at 04:10, wrote:
On 2015/6/11 20:52, Tim Deegan wrote:
which would be better handeld explicitly:
if ( p2mt == p2m_invalid || p2mt == p2m_mmio_dm )
...
So if I'm correct, we should do this check explicitly,
i
On 2015/6/11 18:02, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
This patch passes rdm reservation policy to xc_assign_device() so the policy
is checked when assigning devices to a VM.
Signed-off-by: Tiejun Chen
---
tools/libxc/include/xenctrl.h | 3
On 2015/6/11 18:19, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloader, low_mem_pgend and
On 2015/6/11 18:25, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Currently we're intending to cover this kind of devices
we're -> we're not?
I mean currently we want to handle this shared case *simply* so I think
its still "we'
On 2015/6/11 18:22, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
region so we always ignore USB RMRR.
If USB RMRR conflicts with guest bios, the conflict is always there
before and after your
On 2015/6/12 16:45, Jan Beulich wrote:
On 12.06.15 at 08:31, wrote:
On 2015/6/11 17:28, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
@@ -1940,7 +1942,8 @@ static int intel_iommu_remove_device(u8 devfn, struct
pci_dev
*pdev)
PCI_DEVFN2(bdf
On 2015/6/12 23:43, Wei Liu wrote:
On Thu, Jun 11, 2015 at 09:15:19AM +0800, Tiejun Chen wrote:
[...]
-static int next_bdf(char **str, int *seg, int *bus, int *dev, int *func)
+static int next_bdf(char **str, int *seg, int *bus, int *dev, int *func,
+int *flag)
This is unr
On 2015/6/13 0:02, Wei Liu wrote:
On Thu, Jun 11, 2015 at 09:15:20AM +0800, Tiejun Chen wrote:
This patch introduces user configurable parameters to specify RDM
resource and according policies,
Global RDM parameter:
rdm = "type=none/host,reserve=strict/relaxed"
Per-device RDM parameter:
On 2015/6/13 0:17, Wei Liu wrote:
On Thu, Jun 11, 2015 at 09:15:21AM +0800, Tiejun Chen wrote:
This patch passes our rdm reservation policy inside libxl
when we assign a device or attach a device.
Signed-off-by: Tiejun Chen
---
docs/man/xl.pod.1 | 7 ++-
tools/libxl/libxl_pci.c
On 2015/6/13 0:39, Wei Liu wrote:
On Thu, Jun 11, 2015 at 09:15:22AM +0800, Tiejun Chen wrote:
[...]
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "xg_private.h"
#include "xc_private.h"
@@ -270,7 +271,7 @@ static int setup_gue
On 2015/6/13 0:43, Wei Liu wrote:
On Thu, Jun 11, 2015 at 09:15:23AM +0800, Tiejun Chen wrote:
Here we'll construct a basic guest e820 table via
XENMEM_set_memory_map. This table includes lowmem, highmem
and RDMs if they exist. And hvmloader would need this info
later.
Signed-off-by: Tiejun Che
On 2015/6/12 17:20, Chen, Tiejun wrote:
On 2015/6/12 16:45, Jan Beulich wrote:
On 12.06.15 at 08:31, wrote:
On 2015/6/11 17:28, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
@@ -1940,7 +1942,8 @@ static int intel_iommu_remove_device(u8
devfn, struct pci_dev
Please ignore this email and sorry for any inconvenience.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On 2015/6/15 23:01, Wei Liu wrote:
On Mon, Jun 15, 2015 at 09:50:49AM +0800, Chen, Tiejun wrote:
[...]
+ uint32_t flag,
+ uint16_t seg,
+ uint8_t bus,
+ uint8_t devfn,
+ unsigned int *nr_entries
On 2015/6/15 22:58, Wei Liu wrote:
On Mon, Jun 15, 2015 at 09:12:17AM +0800, Chen, Tiejun wrote:
On 2015/6/12 23:43, Wei Liu wrote:
On Thu, Jun 11, 2015 at 09:15:19AM +0800, Tiejun Chen wrote:
[...]
-static int next_bdf(char **str, int *seg, int *bus, int *dev, int *func)
+static int
On 2015/6/16 13:58, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Friday, June 12, 2015 5:00 PM
On 2015/6/11 18:22, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Thursday, June 11, 2015 9:15 AM
Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
region so we always ignore USB
On 2015/6/16 13:47, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Friday, June 12, 2015 3:54 PM
bar_data |= (uint32_t)base;
bar_data_upper = (uint32_t)(base >> 32);
+for ( j = 0; j < memory_map.nr_map ; j++ )
+{
+if ( memory_map.ma
On 2015/6/16 17:40, Jan Beulich wrote:
On 16.06.15 at 11:29, wrote:
I'm trying to walk into this direction:
/*
* We'll skip all space overlapping with reserved memory later,
* so we need to increase mmio_total to compensate them.
*/
for ( j = 0; j < memory_map.
On 2015/6/17 15:19, Jan Beulich wrote:
On 17.06.15 at 09:10, wrote:
On 2015/6/16 17:40, Jan Beulich wrote:
On 16.06.15 at 11:29, wrote:
I'm trying to walk into this direction:
/*
* We'll skip all space overlapping with reserved memory later,
* so we need to increase m
On 2015/6/17 16:05, Jan Beulich wrote:
On 17.06.15 at 09:54, wrote:
On 2015/6/17 15:19, Jan Beulich wrote:
On 17.06.15 at 09:10, wrote:
Yeah, this may waste some spaces in this worst case but I this think
this can guarantee our change don't impact on the original expectation,
right?
"Some
On 2015/6/17 16:26, Chen, Tiejun wrote:
On 2015/6/17 16:05, Jan Beulich wrote:
On 17.06.15 at 09:54, wrote:
On 2015/6/17 15:19, Jan Beulich wrote:
On 17.06.15 at 09:10, wrote:
Yeah, this may waste some spaces in this worst case but I this think
this can guarantee our change don't impa
On 2015/6/17 17:02, Jan Beulich wrote:
On 17.06.15 at 10:26, wrote:
Something hits me to generate another idea,
#1. Still allocate all devices as before.
#2. Lookup all actual bars to check if they're conflicting RMRR
We can skip these bars to keep zero. Then later it would make lookup easily
On 2015/6/17 17:24, Jan Beulich wrote:
On 17.06.15 at 11:18, wrote:
On 2015/6/17 17:02, Jan Beulich wrote:
On 17.06.15 at 10:26, wrote:
Something hits me to generate another idea,
#1. Still allocate all devices as before.
#2. Lookup all actual bars to check if they're conflicting RMRR
We c
On 2015/6/17 18:03, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -927,10 +927,16 @@ int set_identity_p2m_entry(struct domain *d, unsigned
long gfn,
}
gfn_unlock(p2m, gfn, 0);
-return ret;
}
+el
On 2015/6/18 14:29, Jan Beulich wrote:
On 18.06.15 at 08:17, wrote:
On 2015/6/17 17:24, Jan Beulich wrote:
On 17.06.15 at 11:18, wrote:
On 2015/6/17 17:02, Jan Beulich wrote:
On 17.06.15 at 10:26, wrote:
Something hits me to generate another idea,
#1. Still allocate all devices as before
On 2015/6/17 18:11, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
@@ -899,7 +899,7 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn,
mfn_t mfn,
}
int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
- p2m_access_t p2ma)
+
On 2015/6/18 15:53, Jan Beulich wrote:
On 18.06.15 at 09:14, wrote:
On 2015/6/17 18:11, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
@@ -1577,9 +1578,10 @@ int iommu_do_pci_domctl(
seg = machine_sbdf >> 16;
bus = PCI_BUS(machine_sbdf);
devfn = PCI_DEVFN2(m
On 2015/6/17 18:14, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
This patch enables XENMEM_memory_map in hvm. So we can use it to
setup the e820 mappings.
I think saying "hvmloader" instead of "we" would make things more
explicit. In the context here, "we" would be the hypervisor, and
Fi
On 2015/6/17 18:22, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -107,6 +107,8 @@ asm (
".text \n"
);
+struct e820map memory_map;
Imo this should live in e820.c.
On 2015/6/17 18:28, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2277,13 +2277,37 @@ static int intel_iommu_assign_device(
if ( list_empty(&acpi_drhd_units) )
return -ENODEV;
+seg = p
On 2015/6/18 17:13, Jan Beulich wrote:
On 18.06.15 at 10:48, wrote:
On 2015/6/18 15:53, Jan Beulich wrote:
On 18.06.15 at 09:14, wrote:
On 2015/6/17 18:11, Jan Beulich wrote:
On 11.06.15 at 03:15, wrote:
@@ -1577,9 +1578,10 @@ int iommu_do_pci_domctl(
seg = machine_sbdf >> 16;
On 2015/6/18 18:07, Tim Deegan wrote:
At 14:13 +0800 on 12 Jun (1434118407), Chen, Tiejun wrote:
could you explain why existing guest_physmap_remove_page can't
serve the purpose so you need invent a new identity mapping
specific one? For unmapping suppose it should be common regardle
On 2015/6/18 16:05, Jan Beulich wrote:
On 18.06.15 at 09:01, wrote:
On 2015/6/18 14:29, Jan Beulich wrote:
On 18.06.15 at 08:17, wrote:
On 2015/6/17 17:24, Jan Beulich wrote:
On 17.06.15 at 11:18, wrote:
On 2015/6/17 17:02, Jan Beulich wrote:
On 17.06.15 at 10:26, wrote:
Something hits
On 2015/6/19 10:02, Chen, Tiejun wrote:
On 2015/6/18 16:05, Jan Beulich wrote:
On 18.06.15 at 09:01, wrote:
On 2015/6/18 14:29, Jan Beulich wrote:
On 18.06.15 at 08:17, wrote:
On 2015/6/17 17:24, Jan Beulich wrote:
On 17.06.15 at 11:18, wrote:
On 2015/6/17 17:02, Jan Beulich wrote:
On
On 2015/6/23 18:12, Jan Beulich wrote:
On 23.06.15 at 11:57, wrote:
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1839,7 +1839,7 @@ static int rmrr_identity_mapping(struct domain *d, bool_t
map,
while ( base_pfn < end_pfn )
Note actually we just need p2m_remove_page() to unmap these mapping on
both ept and vt-d sides, and guest_physmap_remove_page is really a
wrapper of p2m_remove_page().
And I agree with Tim regarding the desire to avoid code duplication.
Yet that's no reason to do it asymmetrically:
clear_identit
On 2015/6/25 19:08, Wei Liu wrote:
On Tue, Jun 23, 2015 at 05:57:24PM +0800, Tiejun Chen wrote:
After commit 5dff8e9eedc7, "libxc/libxl: fill xc_hvm_build_args in
libxl" is introduced, we won't check to set args.mmio_size inside
xc_hvm_build as before. So instead, we need to do this before call
On 2015/6/25 19:23, Wei Liu wrote:
On Tue, Jun 23, 2015 at 05:57:25PM +0800, Tiejun Chen wrote:
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloader, low_mem_pgend and high_mem_pgen
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 638b350..079465f 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -767,6 +767,27 @@ to a given device, and "strict" is default here.
Note this would override global B option.
+=item B
+
+Number of megabytes to se
On 2015/6/25 19:33, Wei Liu wrote:
The subject line should be changed. You're not extending that hypercall.
libxl: construct e820 map with RDM information for HVM guest
Agreed.
On Tue, Jun 23, 2015 at 05:57:27PM +0800, Tiejun Chen wrote:
Here we'll construct a basic guest e820 table via
XE
Thanks for your all corrections.
+=item B
+
+Currently we just have two types:
"Currently there are only two types". Although I would probably just say
"Valid types are"
So let say "Currently there are only two valid types".
+"host" means all reserved device memory on this platform shou
B is the PCI Bus/Device/Function of the physical device to pass-through.
+B is about how to handle conflict between reserving reserved device
s/is about/specifies/
Okay.
and I think s/between/while/
+memory and guest address space. "strict" means an unsolved conflict leads to
I think y
I will delete this last sentence and add this,
Please refer "reserve" option to the rdm option in xl.cfg.5.txt.
Say "xl.cfg(5)" which is a neutral reference to the manpage in any form.
I'm trying to follow an existing example here, so
This is same as "reserve" option to the rdm option, plea
TODO: in the future this parameter may be further extended to allow
specifying arbitrary regions, e.g. even those belonging to another
platform as a preparation for live migration with passthrough devices.
I don't think this needs to be explained in this document at all.
Whenever someone does th
Just let me rephrase this,
"none" means we don't check any reserved regions and then all rdm
policies would be ignored, so guest just work as before.
When or why would I write:
rdm = "none"
in my configuration file instead of just not saying anything?
As you know we just have two opt
static int
libxl__xc_device_get_rdm(libxl__gc *gc,
uint32_t flag,
uint16_t seg,
uint8_t bus,
uint8_t devfn,
unsigned int *nr_entries,
struct x
+B is about how to handle conflict between reserving reserved device
+memory and guest address space. "strict" means an unsolved conflict leads to
+immediate VM crash, while "relaxed" allows VM moving forward with a warning
+message thrown out. Here "strict" is default.
Surely it would be better
On 2015/6/25 20:31, Ian Jackson wrote:
Tiejun Chen writes ("[v4][PATCH 11/19] tools: introduce some new parameters to set
rdm policy"):
This patch introduces user configurable parameters to specify RDM
resource and according policies,
...
Global RDM parameter, "type", allows user to specify r
Having read all these docs I now know what all the options are, but I
still don't really know what I should write. I think an example or two
of real world usage would be helpful.
Here I picked some code fragments to help you understand this,
I meant an example or two in the documentation.
T
The code fragment didn't answer my question either, but that's not
really the point.
Do you mean I should write two example, respectively?
I meant an example or two of actual concrete uses (ideally the most
common ones) of the rdm parameter and what they mean in practical terms.
What about t
It's a matter of taste to some degree. Unless patches are really
involved, I prefer them not to add dead code. Apart from
eliminating the case of the code remaining dead (perhaps for
extended periods of time) if only parts of a series get applied, it
also generally helps review if one can see the
+#define XEN_DOMCTL_DEV_NO_RDM 0
+#define XEN_DOMCTL_DEV_RDM_RELAXED 1
+#define XEN_DOMCTL_DEV_RDM_STRICT 2
+uint32_t flag; /* flag of assigned device */
Normally flags would be bit fields, not values like this.
Also, what's the distinction between RDM and RMRR, and
On 2015/6/30 22:20, George Dunlap wrote:
On 06/30/2015 12:24 PM, Chen, Tiejun wrote:
+#define XEN_DOMCTL_DEV_NO_RDM 0
+#define XEN_DOMCTL_DEV_RDM_RELAXED 1
+#define XEN_DOMCTL_DEV_RDM_STRICT 2
+uint32_t flag; /* flag of assigned device */
Normally flags would be
On 2015/6/30 23:54, George Dunlap wrote:
On Tue, Jun 23, 2015 at 10:57 AM, Tiejun Chen wrote:
@@ -1450,6 +1458,11 @@ static void domcreate_attach_pci(libxl__egc *egc,
libxl__multidev *multidev,
}
for (i = 0; i < d_config->num_pcidevs; i++) {
+/*
+ * If the rdm glob
@@ -988,6 +988,14 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
out:
if (!libxl_is_stubdom(ctx, domid, NULL)) {
+if (pcidev->rdm_reserve == LIBXL_RDM_RESERVE_FLAG_RELAXED) {
+flag = XEN_DOMCTL_DEV_RDM_RELAXED;
+} else if (
On 2015/7/1 0:11, George Dunlap wrote:
On Tue, Jun 23, 2015 at 10:57 AM, Tiejun Chen wrote:
This patch passes our rdm reservation policy inside libxl
when we assign a device or attach a device.
Actually, it looks like what you need to do here, both for this patch
and the previous one is to ad
Global RDM parameter:
rdm = "type=none/host,reserve=strict/relaxed"
Per-device RDM parameter:
pci = [ 'sbdf, rdm_reserve=strict/relaxed' ]x
Oh, right -- I see you did add this here. In which case I think you
don't need the extra xl parameter you added in patch 12/19, right? As
I said
* RMRR fix (fair)
RFC posted
Wei,
I think this should be ok or good based on current status, and also
should remove "RFC" here.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
1. By default, the domain policy is RELAXED (See above,
libxl__rdm_setdefault()).
2. By default, the policy for individual devices is STRICT (see
libxl_pci.c:libxl__device_pci_setdefault())
3. If the domain policy is set to STRICT, this overrides per-device
policy
4. If the domain policy is set
On 2015/7/1 18:02, George Dunlap wrote:
On 07/01/2015 02:11 AM, Chen, Tiejun wrote:
On 2015/6/30 22:20, George Dunlap wrote:
On 06/30/2015 12:24 PM, Chen, Tiejun wrote:
+#define XEN_DOMCTL_DEV_NO_RDM 0
+#define XEN_DOMCTL_DEV_RDM_RELAXED 1
+#define XEN_DOMCTL_DEV_RDM_STRICT
This is trying to covert LIBXL_XXX to XEN_XXX passed this policy as a
hypercall, so I still think this is better to live here. Instead, the
previous patch is just defining something.
The entire rest of this patch is about xl. It doesn't make any sense at
all for the previous patch to modify lib
On 2015/7/1 18:57, George Dunlap wrote:
On 07/01/2015 11:26 AM, Chen, Tiejun wrote:
1. By default, the domain policy is RELAXED (See above,
libxl__rdm_setdefault()).
2. By default, the policy for individual devices is STRICT (see
libxl_pci.c:libxl__device_pci_setdefault())
3. If the domain
If I'm correct, then #3 means it's not possible to have devices for a
domain *default* to strict, but to be relaxed in individual
instances.
If you had five devices you wanted strict, and only one device you
wanted to be relaxed (because you knew it didn't matter), you'd have
to set reserved=stric
I don't happen to think these "override" semantics are actually going to
turn out to be that useful; I do think a "default" semantic would be
useful. But I'd be content if the name of the current setting were
switched to "override" to make the semantics more clear. We can always
add in "default"
When you say "not tools", I take it to mean that you're not exposing
that option through the libxl interface?
Yes.
tools/libxc/xc_domain.c:xc_assign_dt_device() most certainly does pass
it in, and that's the level I'm talking about. Someone reviewing this
patch series needs to know, when xc
@@ -1898,7 +1899,13 @@ static int intel_iommu_add_device(u8 devfn, struct
pci_dev *pdev)
PCI_BUS(bdf) == pdev->bus &&
PCI_DEVFN2(bdf) == devfn )
{
-ret = rmrr_identity_mapping(pdev->domain, 1, rmrr);
+/*
+ * RMRR is alway
I'm not only suggesting changing the layout of the patches; I'm
Sorry for this misunderstanding.
suggesting modifying the functionality.
In patch 12 you add a new command-line parameter to xl; so that you have
to type something like this:
# xl pci-attach ubuntu01 01:00.1,msitranslate=1 relax
in high level I have to say Yes. If you really read that v2 design and
its associated discussion, you should notice I didn't put any response
right there.
Look, I'm getting a bit angry at your continual implication that I
Sorry to this.
haven't put in enough work reading the background for t
On 2015/7/2 18:28, George Dunlap wrote:
On 07/02/2015 11:01 AM, Chen, Tiejun wrote:
1. After spending yet another half hour doing research, I haven't found
any discussion that concluded we should have the global policy override
the local policy
I also took some time to go back checking
Yes, this demonstrates my point. Each of these is a single-bit boolean
value that takes up a single bit -- either on or off. But here you have
three values -- NO_DRM, RELAXED, and STRICT, that take up two bits. If
Is this fine to you?
#define _XEN_DOMCTL_DEV_NO_RDM 0
#define XEN_DOM
I think we should go back here.
I was involved in the design discussion, and from the very beginning I
probably saw your plan but misunderstood it. I wouldn't be surprised if
some others didn't quite understand what they were agreeing to.
This way of doing things is different than the way we d
This way of doing things is different than the way we do it with most
other options relating to pci devices (e.g., pci_permissive,
pci_msitranslate, pci_sieze, &c). All of those options use a "default"
semantic: the domain-wide setting takes effect only if it's not set
locally. If the syntax loo
On 2015/7/6 22:34, Jan Beulich wrote:
On 06.07.15 at 16:29, wrote:
It sounds like part of the problem here is a matter of domains.
Jan cares mostly about what happens in the hypervisor. At the
hypervisor level, there is only the per-device configurations, and he is
keen that rmrrs be "strict"
Any comment to this?
Thanks
Tiejun
On 2015/7/2 16:49, Chen, Tiejun wrote:
@@ -1898,7 +1899,13 @@ static int intel_iommu_add_device(u8 devfn,
struct pci_dev *pdev)
PCI_BUS(bdf) == pdev->bus &&
PCI_DEVFN2(bdf) == devfn )
{
-
* for dt devices:
- Ignore this flag entirely
But we still a flag to assign_device() like this,
diff --git a/xen/drivers/passthrough/device_tree.c
b/xen/drivers/passthrough/device_tree.c
index 5d3842a..a182487 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/de
Just please go to review the new revision directly.
Thanks
Tiejun
On 2015/7/6 22:52, Chen, Tiejun wrote:
Any comment to this?
Thanks
Tiejun
On 2015/7/2 16:49, Chen, Tiejun wrote:
@@ -1898,7 +1899,13 @@ static int intel_iommu_add_device(u8 devfn,
struct pci_dev *pdev)
PCI_BUS
Just please go to review the new revision directly.
Thanks
Tiejun
On 2015/7/6 22:55, Chen, Tiejun wrote:
* for dt devices:
- Ignore this flag entirely
But we still a flag to assign_device() like this,
diff --git a/xen/drivers/passthrough/device_tree.c
b/xen/drivers/passthrough
Global RDM parameter, "type", allows user to specify reserved regions
explicitly, e.g. using 'host' to include all reserved regions reported
As I understand this feature, I don't think the name `type' is right.
This is a method for handling or overriding/ignoring the RDM problem.
Perhaps `handl
[Later:]
As I discussed with Campbell we'd like not to expose "none" in xl level
since this is equivalent to that case we don't set anything.
I think this observation of mine applies to the libxl API level too.
Sorry I don't know what I should do at this point.
Default per-device RDM pol
On 2015/7/7 21:26, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v5][PATCH 10/16] tools: introduce some new parameters to
set rdm policy"):
[Later:]
As I discussed with Campbell we'd like not to expose "none" in xl level
since this is equivalent to that case we don&
On 2015/7/7 19:57, Ian Jackson wrote:
Tiejun Chen writes ("[v5][PATCH 11/16] tools/libxl: detect and avoid conflicts with
RDM"):
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloade
On 2015/7/7 22:40, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v5][PATCH 10/16] tools: introduce some new parameters to
set rdm policy"):
On 2015/7/7 21:26, Ian Jackson wrote:
Is "none" not "hoping the user can ignore the problem" ?
Its impossible since
On 2015/7/7 22:57, Ian Jackson wrote:
Chen, Tiejun writes ("Re: [v5][PATCH 11/16] tools/libxl: detect and avoid conflicts
with RDM"):
On 2015/7/7 19:57, Ian Jackson wrote:
I think the error handling here is wrong. Certainly `rc' should not
be used for a libxc return.
Nope,
I mean if you don't set these mappings, these devices can't work at all
and then crash VM like IGD passthrough. But I'm also saying we don't
pass through any devices in most cases, and those devices which own RDM
are very rare. So why should we set 'none' to Xen by default?
One typo, s/should/sh
1 - 100 of 419 matches
Mail list logo
