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
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/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
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
+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/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
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
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,
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
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
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/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 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
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 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
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
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/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
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/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
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/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/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
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/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/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
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 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
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/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/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/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
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/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
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
#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/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
301 - 363 of 363 matches
Mail list logo
