On 2014/11/11 17:42, Chen, Tiejun wrote:
On 2014/11/11 17:06, Jan Beulich wrote:
On 11.11.14 at 10:03, jbeul...@suse.com wrote:
On 11.11.14 at 08:49, tiejun.c...@intel.com wrote:
Unless we move all check inside each callback functions.
That's what you should do imo, albeit I realize
#2 flags field in each specific device of new domctl would control
whether this device need to check/reserve its own RMRR range. But its
not dependent on current device assignment domctl, so the user can use
them to control which devices need to work as hotplug later, separately.
And this could
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 would control
whether this device need to check/reserve its own RMRR range. But its
not dependent on current device assignment domctl, so the user can
On 2014/11/12 18:24, Jan Beulich wrote:
On 12.11.14 at 11:18, tiejun.c...@intel.com wrote:
On 2014/11/12 16:55, Jan Beulich wrote:
On 12.11.14 at 04:05, tiejun.c...@intel.com wrote:
I don't see any feedback to this point, so I think you still prefer we
should do all check in the callback
On 2014/11/17 18:05, Jan Beulich wrote:
On 17.11.14 at 08:57, tiejun.c...@intel.com wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -698,10 +698,13 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
-static int get_reserved_device_memory(xen_pfn_t
On 2014/11/17 18:13, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 05:42:12PM +0800, Chen, Tiejun wrote:
On 2014/11/17 17:25, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 04:48:32PM +0800, Chen, Tiejun wrote:
On 2014/11/17 14:10, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 10
On 2014/11/18 16:01, Jan Beulich wrote:
On 18.11.14 at 04:08, tiejun.c...@intel.com wrote:
Here I tried to implement what you want. Note just pick two key
fragments since others have no big deal.
#1:
@@ -898,14 +898,25 @@ int
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void
So without lookuping devices[i], how can we call func() for each sbdf as
you mentioned?
You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.
Yeah, so change this again,
int intel_iommu_get_reserved_device_memory(iommu_grdm_t
Have a second struct acpi_rmrr_unit pointer, starting out as NULL
and getting set to the current one when the callback returns a
positive value. Skip further iterations as long as both pointers
match.
Great!
int intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void *ctxt)
{
On 2014/11/3 18:02, Jan Beulich wrote:
On 03.11.14 at 10:55, tiejun.c...@intel.com wrote:
On 2014/11/3 17:45, Jan Beulich wrote:
On 03.11.14 at 10:32, tiejun.c...@intel.com wrote:
On 2014/11/3 16:53, Jan Beulich wrote:
On 03.11.14 at 03:22, tiejun.c...@intel.com wrote:
On 2014/10/31 16:14,
On 2014/11/21 15:54, Jan Beulich wrote:
On 21.11.14 at 08:43, kevin.t...@intel.com wrote:
From: Chen, Tiejun
Sent: Friday, November 21, 2014 2:26 PM
On 2014/11/3 18:02, Jan Beulich wrote:
On 03.11.14 at 10:55, tiejun.c...@intel.com wrote:
On 2014/11/3 17:45, Jan Beulich wrote:
On 03.11.14
On 2014/12/2 16:33, Tian, Kevin wrote:
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
On 2014/12/3 3:39, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:20PM +0800, Tiejun Chen wrote:
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
On 2014/12/4 23:33, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -34,6 +34,7 @@
#include xen/tasklet.h
#include xsm/xsm.h
#include asm/msi.h
+#include xen/stdbool.h
Please don't - we use
On 2014/12/3 3:47, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:21PM +0800, Tiejun Chen wrote:
From: Jan Beulich jbeul...@suse.com
This is a prerequisite for punching holes into HVM and PVH guests' P2M
to allow passing through devices that are associated with (on VT-d)
RMRRs.
On 2014/12/2 16:46, Tian, Kevin wrote:
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
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -22,27 +22,66 @@ struct get_reserved_device_memory {
unsigned int used_entries;
};
-static int
On 2014/12/3 4:01, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.
We need to call reserved device memory maps hypercall
On 2014/12/8 16:09, Chen, Tiejun wrote:
On 2014/12/3 4:01, Konrad Rzeszutek Wilk wrote:
On Mon, Dec 01, 2014 at 05:24:25PM +0800, Tiejun Chen wrote:
We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.
We need to call reserved
On 2014/12/4 23:52, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
We need to use reserved device memory maps with multiple times, so
provide just one common function should be friend.
I'm not going to repeat earlier comments; the way this is done right
now it's neither
On 2014/12/2 17:11, Tian, Kevin wrote:
From: Chen, Tiejun
Sent: Monday, December 01, 2014 5:24 PM
We need to make sure all mmio allocation don't overlap
any rdm, reserved device memory. Here we just skip
all reserved device memory range in mmio space.
Signed-off-by: Tiejun Chen tiejun.c
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -34,6 +34,7 @@
#include xen/tasklet.h
#include xsm/xsm.h
#include asm/msi.h
+#include xen/stdbool.h
struct pci_seg {
struct list_head alldevs_list;
@@ -1553,6 +1554,44 @@ int iommu_do_pci_domctl(
}
On 2014/12/8 16:43, Jan Beulich wrote:
On 08.12.14 at 07:06, tiejun.c...@intel.com wrote:
On 2014/12/4 23:33, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
Looks this could be fine,
d-arch.hvm_domain.pci_force = xdsr-flags PCI_DEV_RDM_CHECK;
Which is correct only
On 2014/12/8 16:51, Jan Beulich wrote:
On 08.12.14 at 08:11, tiejun.c...@intel.com wrote:
On 2014/12/4 23:50, Jan Beulich wrote:
On 01.12.14 at 10:24, tiejun.c...@intel.com wrote:
-if ( __copy_to_compat_offset(grdm-map.buffer, grdm-used_entries,
-
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, tiejun.c...@intel.com wrote:
On 2014/12/8 16:51, Jan Beulich wrote:
The whole if-copy-unlock-and-return-EFAULT-otherwise-increment
is identical and can be factored out pretty easily afaict.
What about this?
struct
On 2014/12/9 17:21, Jan Beulich wrote:
On 09.12.14 at 10:12, tiejun.c...@intel.com wrote:
On 2014/12/9 16:19, Jan Beulich wrote:
On 09.12.14 at 08:47, tiejun.c...@intel.com wrote:
On 2014/12/8 16:51, Jan Beulich wrote:
The whole if-copy-unlock-and-return-EFAULT-otherwise-increment
is
On 2014/12/9 18:22, Jan Beulich wrote:
On 09.12.14 at 11:11, t...@xen.org wrote:
At 08:19 + on 09 Dec (1418109561), Jan Beulich wrote:
Why do you always pick other than the simplest possible solution?
Jan, please don't make personal comments like this in code review. It
can only offend
On 2014/12/19 0:13, Tim Deegan wrote:
Hi Kevin,
At 14:09 +0100 on 11 Dec (1418303386), Tim Deegan wrote:
At 02:03 + on 11 Dec (1418259797), Tian, Kevin wrote:
From: Tim Deegan [mailto:t...@xen.org]
Now since the code's not going to be in 4.5 anyway, it should be
possible to _develop_ it
Jan,
Thanks for your time but I'm not going to address your comments here.
Because I heard this design is totally not satisfied your expectation.
But this really was reviewed with several revisions by Kevin and Yang
before sending in public...
Anyway, I guess the only thing what I can do is
On 2015/2/4 18:41, Ian Campbell wrote:
On Wed, 2015-02-04 at 09:34 +0800, Chen, Tiejun wrote:
-machine xxx,igd-passthru=on, to enable/disable that feature.
And we also remove that old option, -gfx_passthru, just from
the case of LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN since
On 2015/2/3 18:19, Wei Liu wrote:
On Tue, Feb 03, 2015 at 09:01:53AM +0800, Chen, Tiejun wrote:
On 2015/2/2 20:19, Wei Liu wrote:
On Mon, Feb 02, 2015 at 09:17:23AM +0800, Tiejun Chen wrote:
When we're working to support IGD GFX passthrough with qemu
upstream, instead of -gfx_passthru we'd
On 2015/2/6 9:01, Chen, Tiejun wrote:
On 2015/2/5 17:52, Ian Campbell wrote:
On Thu, 2015-02-05 at 09:22 +0800, Chen, Tiejun wrote:
Indeed this is not something workaround, and I think in any type of VGA
devices, we'd like to diminish this sort of thing gradually, right?
This mightn't come
On 2015/1/21 19:56, Ian Campbell wrote:
On Wed, 2015-01-21 at 11:37 +, Ian Jackson wrote:
Tiejun Chen writes ([RFC][PATCH 1/1] libxl: add one machine property to support IGD
GFX passthrough):
When we're working to support IGD GFX passthrough with qemu
upstream, instead of -gfx_passthru
On 2015/1/21 21:48, Gerd Hoffmann wrote:
On Mi, 2015-01-21 at 11:37 +, Ian Jackson wrote:
Tiejun Chen writes ([RFC][PATCH 1/1] libxl: add one machine property to support IGD
GFX passthrough):
When we're working to support IGD GFX passthrough with qemu
upstream, instead of -gfx_passthru
On 2015/1/22 8:51, Chen, Tiejun wrote:
On 2015/1/21 21:48, Gerd Hoffmann wrote:
On Mi, 2015-01-21 at 11:37 +, Ian Jackson wrote:
Tiejun Chen writes ([RFC][PATCH 1/1] libxl: add one machine property
to support IGD GFX passthrough):
When we're working to support IGD GFX passthrough
On 2015/2/9 19:05, Ian Campbell wrote:
On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote:
What about this?
I've not read the code in detail,since I'm travelling but from a quick
glance it looks to be implementing the sort of thing I meant, thanks.
Thanks for your time.
A couple
Ian,
Just ping this, or do you think I should send this as a patch?
Thanks
Tiejun
On 2015/2/11 10:45, Chen, Tiejun wrote:
On 2015/2/9 19:05, Ian Campbell wrote:
On Mon, 2015-02-09 at 14:28 +0800, Chen, Tiejun wrote:
What about this?
I've not read the code in detail,since I'm travelling
On 2015/1/27 22:40, Ian Jackson wrote:
Chen, Tiejun writes (Re: [Qemu-devel] [RFC][PATCH 1/1] libxl: add one machine
property to support IGD GFX passthrough):
On 2015/1/23 8:43, Chen, Tiejun wrote:
On 2015/1/22 8:51, Chen, Tiejun wrote:
At this point I just concern here if we still use
On 2015/1/30 20:26, Wei Liu wrote:
On Fri, Jan 30, 2015 at 08:56:48AM +0800, Chen, Tiejun wrote:
[...]
Just remember to handle old option in libxl if your old option is already
released by some older version of QEMUs.
I just drop that old option, -gfx_passthru, if we're under qemu upstream
I think the _libxl_ message needs to be just Unable to detect graphics
passthru kind. i.e. it can't/shouldn't reference anything to do with xl
config options etc (which would make no sense if libvirt was being
used).
That's not very user friendly though, so you may want to consider adding
a new
On 2015/3/13 18:11, Ian Campbell wrote:
On Fri, 2015-03-13 at 09:39 +0800, Chen, Tiejun wrote:
I don't think you can abort here, since a user can set
b_info-u.hvm.gfx_passthru_kind to default. You would need to
return an error.
Then, looks I should do this,
LOG(ERROR, No supported IGD
If I remember the context correctly this is in the autodetect case,
so I think shouldn't mention IGD. Something like Unable to detect
graphics passthru kind, please set gfx_passthru_kind. See xl.cfg(5)
for more
s/gfx_passthru_kind/gfx_passthru, right? Because actually we always get
This duplicates the code from above. I think this would be best done as:
static int libxl__detect_gfx_passthru_kind(libxl__gc *gc, guest_config)
{
if (b_info-u.hvm.gfx_passthru_kind != LIBXL_GFX_PASSTHRU_KIND_DEFAULT)
return 0;
if (libxl__is_igd_vga_passthru(gc,
On 2015/3/19 18:44, Ian Campbell wrote:
On Thu, 2015-03-19 at 10:07 +0800, Chen, Tiejun wrote:
This duplicates the code from above. I think this would be best done as:
static int libxl__detect_gfx_passthru_kind(libxl__gc *gc, guest_config)
{
if (b_info-u.hvm.gfx_passthru_kind
+case LIBXL_GFX_PASSTHRU_KIND_DEFAULT:
+LOG(ERROR, unable to detect required gfx_passthru_kind);
In this case you will now have logged twice. I'd suggest logging only
here and not in the helper.
+default:
And this case is subtly different to
On 2015/3/9 18:17, Wei Liu wrote:
On Mon, Mar 09, 2015 at 02:45:36PM +0800, Chen, Tiejun wrote:
[...]
+exit (1);
+}
+} else if (!xlu_cfg_get_string(config, gfx_passthru, buf, 0)) {
+if (libxl_gfx_passthru_kind_from_string(buf,
b_info
On 2015/3/6 17:08, Tiejun Chen wrote:
Although we already have 'gfx_passthru' in b_info, this doesn' suffice
after we want to handle IGD specifically. Now we define a new field of
type, gfx_passthru_kind, to indicate we're trying to pass IGD. Actually
this means we can benefit this to support
On 2015/3/6 20:28, Wei Liu wrote:
On Fri, Mar 06, 2015 at 05:08:21PM +0800, Tiejun Chen wrote:
When we're working to support IGD GFX passthrough with qemu
upstream, instead of -gfx_passthru we'd like to make that
a machine option, -machine xxx,igd-passthru=on. This need
to bring a change on
On 2015/3/6 23:53, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 06, 2015 at 05:08:21PM +0800, Tiejun Chen wrote:
When we're working to support IGD GFX passthrough with qemu
upstream, instead of -gfx_passthru we'd like to make that
Could you also include in the cover letter an URL link to the
On 2015/3/6 20:40, Wei Liu wrote:
On Fri, Mar 06, 2015 at 05:08:22PM +0800, Tiejun Chen wrote:
While working with qemu, IGD is a specific device in the case of pass through
so we need to identify that to handle more later. Here we define a table to
record all IGD types currently we can support.
On 2015/3/6 20:55, Wei Liu wrote:
On Fri, Mar 06, 2015 at 05:08:23PM +0800, Tiejun Chen wrote:
Although we already have 'gfx_passthru' in b_info, this doesn' suffice
after we want to handle IGD specifically. Now we define a new field of
type, gfx_passthru_kind, to indicate we're trying to pass
I don't think you can abort here, since a user can set
b_info-u.hvm.gfx_passthru_kind to default. You would need to return an
error.
Then, looks I should do this,
LOG(ERROR, No supported IGD to passthru,
or please force set gfx_passthru=\igd\.\n);
+
+if (b_info-u.hvm.gfx_passthru_kind ==
+LIBXL_GFX_PASSTHRU_KIND_DEFAULT) {
+if (libxl__is_igd_vga_passthru(gc, guest_config))
+machinearg = GCSPRINTF(%s,igd-passthru=on, machinearg);
+} else if (b_info-u.hvm.gfx_passthru_kind ==
+
On 2015/3/24 18:20, Ian Campbell wrote:
On Tue, 2015-03-24 at 18:15 +0800, Chen, Tiejun wrote:
On 2015/3/24 17:51, Ian Campbell wrote:
On Tue, 2015-03-24 at 16:47 +0800, Chen, Tiejun wrote:
All guys,
Thanks for your reply.
Sorry to bother you.
I have a question to two files, tools
On 2015/3/24 22:50, Ian Campbell wrote:
On Mon, 2015-03-23 at 09:17 +0800, Tiejun Chen wrote:
Although we already have 'gfx_passthru' in b_info, this doesn' suffice
Fixed.
^t
after we want to handle IGD specifically. Now
On 2015/3/24 18:40, Ian Campbell wrote:
On Tue, 2015-03-24 at 18:31 +0800, Chen, Tiejun wrote:
NB, the libxl ones are broken and not even compiled right now, you can
ignore them.
Looks this is still compiled now.
xc is, xl is not, I am sure of that.
Indeed, you're right :)
I don't
On 2015/3/27 17:54, Ian Campbell wrote:
On Fri, 2015-03-27 at 09:29 +0800, Chen, Tiejun wrote:
On 2015/3/26 18:06, Ian Campbell wrote:
On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote:
Hrm, OK. I suppose we can live with autodetect and igd both meaning igd
and whoever adds a new type
On 2015/3/30 17:19, Ian Campbell wrote:
On Mon, 2015-03-30 at 09:28 +0800, Chen, Tiejun wrote:
Sounds it should be a legacy fix to qemu-xen-tranditional :) So lets do
it now,
@@ -326,6 +326,10 @@ static char **
libxl__build_device_model_args_old(libxl__gc *gc
Perhaps add With qemu-xen-traditional IGD is always assumed and other
options than autodetect or explicit IGD will result in an error?
Will do.
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index a8b08f2..4fd6310 100644
--- a/tools/libxl/libxl_dm.c
+++
Campbell,
Are you free to look at my reply?
Thanks
Tiejun
On 2015/3/2 9:20, Chen, Tiejun wrote:
Here I just mean when Qemu realizes IGD is passed through but without
that appropriate option set, Qemu can post something to explicitly
notify user that this option is needed in his case
On 2015/2/27 0:17, Ian Campbell wrote:
On Thu, 2015-02-26 at 14:35 +0800, Chen, Tiejun wrote:
If we are going to do this then I think we need to arrange for the
interface to be able to express the need to force the workarounds for a
particular device. IOW a boolean will not suffice since
Here I just mean when Qemu realizes IGD is passed through but without
that appropriate option set, Qemu can post something to explicitly
notify user that this option is needed in his case. But it may be a lazy
idea.
In any case I think the additions of such warnings in qemu are a
separate to
On 2015/3/26 18:06, Ian Campbell wrote:
On Thu, 2015-03-26 at 08:53 +0800, Chen, Tiejun wrote:
Hrm, OK. I suppose we can live with autodetect and igd both meaning igd
and whoever adds a new type will have to remember to add a check for
qemu-trad then.
When we really have to introduce a new
All guys,
Sorry to bother you.
I have a question to two files, tools/python/xen/lowlevel/xc/xc.c and
tools/python/xen/lowlevel/xl/xl.c. Who is a caller to those methods like
pyxc_methods[] and pyxl_methods[]? And how should we call these approaches?
In my specific case, I'm trying to
On 2015/3/25 18:26, Ian Campbell wrote:
On Wed, 2015-03-25 at 09:18 +0800, Chen, Tiejun wrote:
Actually my problem is that, I need to add a new parameter, 'flag', like
this, xc_assign_device(xxx,xxx,flag). So if I don't refine xc.c, tools
can't be compiled successfully. Or maybe you're
On 2015/3/25 18:32, Ian Campbell wrote:
On Wed, 2015-03-25 at 09:10 +0800, Chen, Tiejun wrote:
+But when given as a string the Bgfx_passthru option describes the type
+of device to enable. Not this behavior is only supported with upstream
Note and the upstream...
Fixed.
+=item igd
On 2015/4/13 19:02, Wei Liu wrote:
On Mon, Apr 13, 2015 at 10:09:51AM +0800, Chen, Tiejun wrote:
[...]
Hardcoded value?
Yes. Actually, we intend to use this to present that lowmem entry,
tools/firmware/hvmloader/e820.c:
/* Low RAM goes here. Reserve space for special pages
On 2015/4/23 20:59, Jan Beulich wrote:
On 23.04.15 at 14:32, tiejun.c...@intel.com wrote:
But if you already have one just please ignore this and tell me
Here's what I currently have:
Could you resend me this as an attached file? Then I can apply that
properly without any miss?
Thanks
On 2015/4/15 21:10, Ian Jackson wrote:
Tiejun Chen writes ([RFC][PATCH 04/13] 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
On 2015/4/16 23:05, Tim Deegan wrote:
Hi,
At 17:21 +0800 on 10 Apr (1428686516), Tiejun Chen wrote:
@@ -862,6 +862,36 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long
gfn, mfn_t mfn,
return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct, access);
}
+int
@@ -121,6 +121,8 @@ void iommu_dt_domain_destroy(struct domain *d);
struct page_info;
+typedef int iommu_grdm_t(xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt);
This needs a comment describing what the return values are.
Will do.
I'm not sure if yourself determine providing
On 2015/4/16 23:40, Tim Deegan wrote:
Hi,
At 17:21 +0800 on 10 Apr (1428686518), Tiejun Chen wrote:
+/*
+ * In some cases, e.g. add a device to hwdomain, and remove a device from
+ * user domain, 'try' is fine enough since this is always safe to hwdomain.
+ */
+#define
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
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
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
On 2015/5/5 17:24, Jan Beulich wrote:
On 05.05.15 at 04:45, tiejun.c...@intel.com wrote:
Does this work for everyone?
Please first of all explain why the interfaces in asm/flushtlb.h can't
be used here (at least when flushing entire pages). Because - as
I also don't understand any reason we
On 2015/5/5 23:46, Boris Ostrovsky wrote:
On 05/04/2015 05:14 AM, Andrew Cooper 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 @@ unsigned
On 2015/5/6 15:12, Jan Beulich wrote:
On 05.05.15 at 18:11, boris.ostrov...@oracle.com wrote:
On 05/05/2015 11:58 AM, Jan Beulich wrote:
On 05.05.15 at 17:46, boris.ostrov...@oracle.com wrote:
On 05/04/2015 05:14 AM, Andrew Cooper wrote:
On 04/05/2015 09:52, Jan Beulich wrote:
On 04.05.15
Campbell, Jackson, Wei and Stefano,
Any consideration?
I can follow up Jan's idea but I need you guys make sure I'm going to do
this properly.
Thanks
Tiejun
On 2015/5/7 10:22, Chen, Tiejun wrote:
On 2015/5/6 23:34, Jan Beulich wrote:
On 06.05.15 at 17:00, tiejun.c...@intel.com wrote
On 2015/5/7 14:04, Jan Beulich wrote:
Chen, Tiejun tiejun.c...@intel.com 05/07/15 4:22 AM
On 2015/5/6 23:34, Jan Beulich wrote:
On 06.05.15 at 17:00, tiejun.c...@intel.com wrote:
On 2015/4/20 19:13, Jan Beulich wrote:
On 10.04.15 at 11:21, tiejun.c...@intel.com wrote
On 2015/5/8 2:58, Michael Dexter wrote:
Hello all,
Are you running IGD passthrough with guest OS?
On 5/6/15 7:47 PM, Chen, Tiejun wrote:
#1. Disable interrupt message generation
#2. Please add 'cpuidle=0 msi=1'
With another try, get the same with the patched kernel:
What is your CPU
On 2015/5/7 0:46, Michael Dexter wrote:
Hello all,
(Resend: I cropped out too much and have added 'pciconf -lv' output)
I have been working with Roger Pau Monne to bring FreeBSD Dom0 support
to a production-ready state but we appear to have hit an IOMMU issue.
Hardware: Lenovo ThinkPad T420
On 2015/5/6 23:34, Jan Beulich wrote:
On 06.05.15 at 17:00, tiejun.c...@intel.com wrote:
On 2015/4/20 19:13, Jan Beulich wrote:
On 10.04.15 at 11:21, tiejun.c...@intel.com wrote:
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1665,6 +1665,46 @@ int xc_assign_device(
On 2015/5/8 21:04, Wei Liu wrote:
Sorry for the late review.
Really thanks for taking your time :)
On Fri, Apr 10, 2015 at 05:21:52PM +0800, Tiejun Chen wrote:
This patch introduces user configurable parameters to specify RDM
resource and according policies,
Global RDM parameter:
rdm
On 2015/5/8 13:21, Michael Dexter wrote:
On 5/7/15 7:59 PM, Chen, Tiejun wrote:
Are you running IGD passthrough with guest OS?
Only as far as the PVH Xen kernel is passing through all hardware to
Dom0. Roger can elaborate as needed.
What is your CPU? BDW? HSW? And what is your FreeBSD Linux
On 2015/5/8 23:13, Wei Liu wrote:
On Fri, May 08, 2015 at 09:24:56AM +0800, Chen, Tiejun wrote:
Campbell, Jackson, Wei and Stefano,
Any consideration?
I can follow up Jan's idea but I need you guys make sure I'm going to do
this properly.
Look at my earlier reply.
Thanks for your reply
On 2015/5/8 21:07, Wei Liu wrote:
On Fri, Apr 10, 2015 at 05:21:54PM +0800, Tiejun Chen wrote:
We will introduce the hypercall xc_reserved_device_memory_map
approach to libxc. This helps us get rdm entry info according to
different parameters. If flag == PCI_DEV_RDM_ALL, all entries
should be
On 2015/5/8 22:43, Wei Liu wrote:
Sorry for the late review. This series fell through the crack.
Thanks for your review.
On Fri, Apr 10, 2015 at 05:21:55PM +0800, Tiejun Chen wrote:
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it
On 2015/5/9 0:07, Julien Grall wrote:
Hi,
On 10/04/15 10:21, Tiejun Chen wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index ca0e51e..e5ba7cb 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -493,6 +493,10 @@
Sorry for this delay response.
On 2015/4/20 21:36, Jan Beulich wrote:
On 10.04.15 at 11:21, tiejun.c...@intel.com wrote:
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1793,8 +1793,14 @@ static void iommu_set_pgd(struct domain *d)
On 2015/4/20 21:39, Jan Beulich wrote:
On 10.04.15 at 11:21, tiejun.c...@intel.com wrote:
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1654,13 +1654,15 @@ int xc_domain_setdebugging(xc_interface *xch,
int xc_assign_device(
xc_interface *xch,
uint32_t domid,
-
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 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 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:
---
On 2015/5/5 14:02, Andrew Cooper wrote:
On 05/05/2015 05:46, Chen, Tiejun wrote:
A better approach might be:
printk(KERN_DEBUG APIC error on CPU%u: %02lx(%02lx), ...)
for ( i = (17); i; i = 1 )
if ( v1 i )
printk(, %s, apic_fault_reasons[i]);
I guess this should
On 2015/4/20 19:13, Jan Beulich wrote:
On 10.04.15 at 11:21, tiejun.c...@intel.com wrote:
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1665,6 +1665,46 @@ int xc_assign_device(
return do_domctl(xch, domctl);
}
+struct xen_reserved_device_memory
On 2015/5/15 14:56, Jan Beulich wrote:
On 15.05.15 at 08:39, tiejun.c...@intel.com wrote:
On 2015/5/15 14:25, Jan Beulich wrote:
On 15.05.15 at 08:11, tiejun.c...@intel.com wrote:
Even we may separate the
low memory to construct memory_map.map[]...
???
Sorry I just mean that the low
On 2015/5/15 15:34, Jan Beulich wrote:
On 15.05.15 at 09:11, tiejun.c...@intel.com wrote:
On 2015/5/15 14:56, Jan Beulich wrote:
On 15.05.15 at 08:39, tiejun.c...@intel.com wrote:
On 2015/5/15 14:25, Jan Beulich wrote:
On 15.05.15 at 08:11, tiejun.c...@intel.com wrote:
Even we may separate
On 2015/5/15 14:16, Jan Beulich wrote:
On 15.05.15 at 04:57, tiejun.c...@intel.com wrote:
On 2015/4/20 21:51, Jan Beulich wrote:
On 10.04.15 at 11:22, tiejun.c...@intel.com wrote:
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -787,6 +787,70 @@ out:
return rc;
}
1 - 100 of 363 matches
Mail list logo
