Sep 2015, Chen, Tiejun wrote:
Stefano,
I have two questions,
#1. Which qemu version is this igd stuff going into? 2.6?
#2. Is this igd stuff going into qemu-xen inside xen? Any plan to go into xen
4.6?
Thanks
Tiejun
On 9/9/2015 1:21 AM, Stefano Stabellini wrote:
> The following changes si
Ping...
Thanks
Tiejun
On 9/18/2015 4:30 PM, Tiejun Chen wrote:
Ian,
As we discussed previously,
http://patchwork.ozlabs.org/patch/457055/
now it's time to push this into on xen/tools side since all qemu stuffs
have been merged.
Stefano,
I have two questions,
#1. Which qemu version is this igd stuff going into? 2.6?
#2. Is this igd stuff going into qemu-xen inside xen? Any plan to go
into xen 4.6?
Thanks
Tiejun
On 9/9/2015 1:21 AM, Stefano Stabellini wrote:
The following changes since commit
On 9/15/2015 7:00 PM, Paolo Bonzini wrote:
On 15/09/2015 11:55, Stefano Stabellini wrote:
On Mon, 14 Sep 2015, Paolo Bonzini wrote:
> On 10/09/2015 12:29, Stefano Stabellini wrote:
> > +if (lseek(config_fd, pos, SEEK_SET) != pos) {
> > +return -errno;
> > +}
> > do {
>
As you see this short log, "hw/pci-assign: split pci-assign.c", so this
means I just extract something from the original hw/i386/kvm/pci-assign.c,
and here so I just keep those original head files residing
hw/i386/kvm/pci-assign.c, and I didn't introduce anything new.
hw/i386/kvm/pci-assign.c
xen-host-pci-device.c is only compiled if CONFIG_XEN_PCI_PASSTHROUGH
was set by configure. That won't be the case on OSX or Windows, where
the Xen headers don't exist.
Okay. This actually shouldn't be enabled on Windows so what about this?
diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
Thanks! I'll fold it the offending patch
(http://marc.info/?l=qemu-devel=144174596628052=2) and resend.
Reviewed-by: Michael S. Tsirkin
Michale and Stefano,
Thanks a lot :)
Tiejun
On 9/10/2015 12:10 AM, Stefano Stabellini wrote:
On Wed, 9 Sep 2015, Stefano Stabellini wrote:
On Tue, 8 Sep 2015, Peter Maydell wrote:
> On 8 September 2015 at 18:21, Stefano Stabellini
> wrote:
> > The following changes since commit
On 9/9/2015 9:06 PM, Stefano Stabellini wrote:
On Tue, 8 Sep 2015, Peter Maydell wrote:
On 8 September 2015 at 18:21, Stefano Stabellini
wrote:
> The following changes since commit 8611280505119e296757a60711a881341603fa5a:
>
> target-microblaze: Use setcond
On 2015/7/15 20:38, Stefano Stabellini wrote:
On Wed, 15 Jul 2015, Michael S. Tsirkin wrote:
On Wed, Jul 15, 2015 at 12:46:29PM +0100, Stefano Stabellini wrote:
Thanks Tiejun, the patch series looks OK to me now.
It looks like it has all the required acks.
Michael, are you OK with it? If so,
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 4356af4..703148e 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -51,4 +51,5 @@ void xen_register_framebuffer(struct MemoryRegion *mr);
# define HVM_MAX_VCPUS 32
#endif
+extern void
Michael Acked them :)
Note once you're fine to my replies to your previous comments, I'd like
to rebase them on the latest and then send out the last revision adding
Acked-by with you and Michael.
Thanks
Tiejun
On Wed, 1 Jul 2015, Chen, Tiejun wrote:
Ping...
Thanks
Tiejun
On 2015/6/5 16
+static void
+xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
+ XenHostPCIDevice *dev)
+{
+uint16_t gpu_dev_id;
+PCIDevice *d = s-dev;
+
+if (!is_igd_vga_passthrough(dev)) {
+return;
+}
I would rather move the if into
#ifdef CONFIG_XEN
+static void igd_passthrough_pc_init_pci(MachineState *machine)
+{
+pc_init1(machine,
+ TYPE_I440FX_PCI_HOST_BRIDGE,
+ TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE);
+}
+
+static void pc_init_pci(MachineState *machine)
+{
+pc_init1(machine,
+
Ping...
Thanks
Tiejun
On 2015/6/5 16:44, Tiejun Chen wrote:
v8:
* Rebase on the latest qemu tree
* Cleanup one xen leftover in patch #3
v7:
* Instead of -gfx_passthru we'd like to make that a machine
option, -machine xxx,igd-passthru=on
* try to make something as common shared by others
On 2015/6/2 17:17, Michael S. Tsirkin wrote:
On Tue, Jun 02, 2015 at 08:50:58AM +0800, Chen, Tiejun wrote:
On 2015/6/1 2:11, Michael S. Tsirkin wrote:
On Thu, Mar 19, 2015 at 09:01:27AM +0800, Chen, Tiejun wrote:
On 2015/3/18 18:21, Gerd Hoffmann wrote:
On Mi, 2015-03-18 at 17:06 +0800
Sorry, just please ignore this series because looks some patches are not
sent out.
Tiejun
On 2015/6/5 16:31, Tiejun Chen wrote:
v8:
* Rebase on the latest qemu tree
* Cleanup one xen leftover in patch #3
v7:
* Instead of -gfx_passthru we'd like to make that a machine
option, -machine
On 2015/6/1 2:11, Michael S. Tsirkin wrote:
On Thu, Mar 19, 2015 at 09:01:27AM +0800, Chen, Tiejun wrote:
On 2015/3/18 18:21, Gerd Hoffmann wrote:
On Mi, 2015-03-18 at 17:06 +0800, Tiejun Chen wrote:
Implement a pci host bridge specific to passthrough. Actually
this just inherits the standard
On 2015/3/26 16:15, Michael S. Tsirkin wrote:
On Thu, Mar 26, 2015 at 03:57:18PM +0800, Chen, Tiejun wrote:
Michael and Gerd,
I don't see any more comments for this revision, so what's next that I
should do?
Thanks
Tiejun
On 2015/3/19 9:01, Chen, Tiejun wrote:
It's only been a week, and we
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
+++
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
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/26 16:15, Michael S. Tsirkin wrote:
On Thu, Mar 26, 2015 at 03:57:18PM +0800, Chen, Tiejun wrote:
Michael and Gerd,
I don't see any more comments for this revision, so what's next that I
should do?
Thanks
Tiejun
On 2015/3/19 9:01, Chen, Tiejun wrote:
It's only been a week, and we
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
Michael and Gerd,
I don't see any more comments for this revision, so what's next that I
should do?
Thanks
Tiejun
On 2015/3/19 9:01, Chen, Tiejun wrote:
On 2015/3/18 18:21, Gerd Hoffmann wrote:
On Mi, 2015-03-18 at 17:06 +0800, Tiejun Chen wrote:
Implement a pci host bridge specific
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 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/python/xen/lowlevel/xc/xc.c and
tools/python/xen/lowlevel/xl/xl.c. Who is a caller to those methods
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
On 2015/3/20 18:11, Ian Campbell wrote:
On Fri, 2015-03-20 at 18:08 +0800, Chen, Tiejun wrote:
+if (!xlu_cfg_get_string(config, gfx_passthru_kind, buf, 0)) {
+if (libxl_gfx_passthru_kind_from_string(buf,
+
b_info-u.hvm.gfx_passthru_kind)) {
+fprintf(stderr
+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
On 2015/3/18 18:21, Gerd Hoffmann wrote:
On Mi, 2015-03-18 at 17:06 +0800, Tiejun Chen wrote:
Implement a pci host bridge specific to passthrough. Actually
this just inherits the standard one. And we also just expose
a minimal real host bridge pci configuration subset.
+/* Here we just
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 20:59, Wei Liu wrote:
On Fri, Mar 06, 2015 at 05:18:36PM +0800, Chen, Tiejun wrote:
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
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
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/11 11:46, Peter Maydell wrote:
On 11 February 2015 at 02:50, Chen, Tiejun tiejun.c...@intel.com wrote:
On 2015/2/11 10:03, Peter Maydell wrote:
The linux-headers/ directory contains header files which can only
validly be included if the host we're compiling on is Linux. Some
of them
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/10 3:56, Michael S. Tsirkin wrote:
It doesn't make sense to copy values manually:
the only issue with getting headers from linux
seems to be dealing with linux/types, we
can easily fix that automatically while importing.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
FYI this
On 2015/2/11 10:03, Peter Maydell wrote:
On 11 February 2015 at 01:36, Chen, Tiejun tiejun.c...@intel.com wrote:
On 2015/2/10 3:56, Michael S. Tsirkin wrote:
It doesn't make sense to copy values manually:
the only issue with getting headers from linux
seems to be dealing with linux/types, we
On 2015/2/6 20:14, Cornelia Huck wrote:
On Fri, 6 Feb 2015 13:41:26 +0800
Tiejun Chen tiejun.c...@intel.com wrote:
Actually we define these device IDs in virtio standard, so
we'd better put them into one common place to manage conveniently.
Here I also add VIRTIO_ID_RESERVE according to
On 2015/2/7 0:28, Stefan Hajnoczi wrote:
On Fri, Feb 06, 2015 at 01:41:26PM +0800, Tiejun Chen wrote:
Actually we define these device IDs in virtio standard, so
we'd better put them into one common place to manage conveniently.
Here I also add VIRTIO_ID_RESERVE according to virtio spec.
On 2015/2/8 18:48, Michael S. Tsirkin wrote:
On Fri, Feb 06, 2015 at 01:14:46PM +0100, Cornelia Huck wrote:
On Fri, 6 Feb 2015 13:41:26 +0800
Tiejun Chen tiejun.c...@intel.com wrote:
Actually we define these device IDs in virtio standard, so
we'd better put them into one common place to
On 2015/2/9 15:02, Michael S. Tsirkin wrote:
On Mon, Feb 09, 2015 at 03:01:15PM +0800, Chen, Tiejun wrote:
On 2015/2/8 18:48, Michael S. Tsirkin wrote:
On Fri, Feb 06, 2015 at 01:14:46PM +0100, Cornelia Huck wrote:
On Fri, 6 Feb 2015 13:41:26 +0800
Tiejun Chen tiejun.c...@intel.com wrote
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
Sorry please ignore this to review another revision.
Thanks
Tiejun
On 2015/2/6 13:24, Tiejun Chen wrote:
Actually we define these device IDs in virtio standard, so
we'd better put them into one common place to manage conveniently.
Here I also add VIRTIO_ID_RESERVE according to virtio spec.
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 true in real world :)
It's not really
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/3 19:07, Ian Campbell wrote:
On Tue, 2015-02-03 at 09:04 +0800, Chen, Tiejun wrote:
On 2015/2/2 20:54, Ian Jackson wrote:
Wei Liu writes (Re: [v2][PATCH] libxl: add one machine property to support IGD GFX
passthrough):
On Mon, Feb 02, 2015 at 09:17:23AM +0800, Tiejun Chen 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 like to make that
a machine option, -machine xxx,-igd-passthru=on. This need
to bring a change on
On 2015/2/2 19:08, Ian Campbell wrote:
On Mon, 2015-02-02 at 09:17 +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/2/2 20:54, Ian Jackson wrote:
Wei Liu writes (Re: [v2][PATCH] libxl: add one machine property to support IGD GFX
passthrough):
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
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/29 18:50, Wei Liu wrote:
On Thu, Jan 29, 2015 at 08:41:24AM +0800, Chen, Tiejun wrote:
On 2015/1/28 19:12, Wei Liu wrote:
On Wed, Jan 28, 2015 at 08:42:56AM +0800, Chen, Tiejun wrote:
On 2015/1/27 22:40, Ian Jackson wrote:
Chen, Tiejun writes (Re: [Qemu-devel] [RFC][PATCH 1/1
On 2015/1/28 19:12, Wei Liu wrote:
On Wed, Jan 28, 2015 at 08:42:56AM +0800, Chen, Tiejun wrote:
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
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/23 8:43, Chen, Tiejun wrote:
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
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 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/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
+
+if (pch_dev_id == 0x) {
+fprintf(stderr, unsupported PCH!\n);
I would drop this fprintf: this likely means a newer
card, so the bridge is not necessary.
Okay.
+return;
+}
+
+/* Currently IGD drivers always need to access PCH by 1f.0. */
+pci_dev =
+static void
+xen_igd_passthrough_isa_bridge_create(XenPCIPassthroughState *s,
+ XenHostPCIDevice *dev)
+{
I suggest this implementation, and the table, are moved
to the same file where igd-passthrough-isa-bridge
is implemented. The function can get
+uint32_t xen_igd_pci_read(PCIDevice *pci_dev, uint32_t config_addr, int len)
+{
+XenHostPCIDevice dev;
+uint32_t val;
+int r;
+
+/* IGD read/write is through the host bridge.
+ */
+assert(pci_dev-devfn == 0x00);
+
+if (!is_igd_passthrough(pci_dev)) {
+goto
On 2015/1/20 16:14, Gerd Hoffmann wrote:
On Di, 2015-01-20 at 11:14 +0800, Chen, Tiejun wrote:
On 2015/1/19 19:45, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
+DEF(gfx_passthru, 0, QEMU_OPTION_gfx_passthru,
+-gfx_passthru enable Intel IGD passthrough by XEN
CCed Stefano.
Thanks
Tiejun
On 2015/1/21 15:19, 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,gfx_passthru=on. This need
to bring several changes on tool side.
On 2015/1/19 19:36, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
From: Michael S. Tsirkin m...@redhat.com
Xen wants to supply a different pci and host devices,
inheriting i440fx devices. Make types configurable.
Description is misleading, this isn't about xen but
On 2015/1/19 19:40, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
+static void xen_igd_passthrough_i440fx_class_init(ObjectClass *klass,
+ void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc-desc = IGD
On 2015/1/19 21:58, Michael S. Tsirkin wrote:
On Mon, Jan 19, 2015 at 12:57:18PM +0100, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
Currently IGD drivers always need to access PCH by 1f.0. But we
Obvious question: q35?
q35 already has a isa bridge @ 0x1f.0.
On 2015/1/19 19:36, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
From: Michael S. Tsirkin m...@redhat.com
Xen wants to supply a different pci and host devices,
inheriting i440fx devices. Make types configurable.
Description is misleading, this isn't about xen but
On 2015/1/20 12:28, Jike Song wrote:
On 01/20/2015 10:52 AM, Chen, Tiejun wrote:
On 2015/1/19 19:40, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
+static void xen_igd_passthrough_i440fx_class_init(ObjectClass *klass
On 2015/1/19 19:45, Gerd Hoffmann wrote:
On Mo, 2015-01-19 at 17:28 +0800, Tiejun Chen wrote:
+DEF(gfx_passthru, 0, QEMU_OPTION_gfx_passthru,
+-gfx_passthru enable Intel IGD passthrough by XEN\n,
+QEMU_ARCH_ALL)
+STEXI
+@item -gfx_passthru
+@findex -gfx_passthru
+Enable Intel IGD
On 2015/1/6 14:20, Shannon Zhao wrote:
On 2015/1/6 10:37, Chen, Tiejun wrote:
On 2015/1/5 20:14, Marcel Apfelbaum wrote:
On 01/05/2015 01:50 PM, Stefan Hajnoczi wrote:
On Mon, Jan 5, 2015 at 11:37 AM, Jan Kiszka jan.kis...@siemens.com
wrote:
On 2015-01-05 12:22, Stefan Hajnoczi wrote
On 2015/1/6 22:56, Stefan Hajnoczi wrote:
On Tue, Jan 06, 2015 at 10:39:13AM +0800, Chen, Tiejun wrote:
On 2015/1/6 9:21, Chen, Tiejun wrote:
On 2015/1/6 1:13, Eric Blake wrote:
On 01/04/2015 10:35 PM, Tiejun Chen wrote:
After one commit 49d2e648e808, machine: remove qemu_machine_opts
global
On 2015/1/6 1:13, Eric Blake wrote:
On 01/04/2015 10:35 PM, Tiejun Chen wrote:
After one commit 49d2e648e808, machine: remove qemu_machine_opts
global list, is introduced, QEMU doesn't keep a global list of
options but set desc lately. Then we can see the following,
$
On 2015/1/6 9:21, Chen, Tiejun wrote:
On 2015/1/6 1:13, Eric Blake wrote:
On 01/04/2015 10:35 PM, Tiejun Chen wrote:
After one commit 49d2e648e808, machine: remove qemu_machine_opts
global list, is introduced, QEMU doesn't keep a global list of
options but set desc lately. Then we can see
On 2015/1/5 20:14, Marcel Apfelbaum wrote:
On 01/05/2015 01:50 PM, Stefan Hajnoczi wrote:
On Mon, Jan 5, 2015 at 11:37 AM, Jan Kiszka jan.kis...@siemens.com
wrote:
On 2015-01-05 12:22, Stefan Hajnoczi wrote:
Commit 49d2e648e8087d154d8bf8b91f27c8e05e79d5a6 (machine: remove
qemu_machine_opts
On 2014/12/27 22:52, Paolo Bonzini wrote:
On 26/12/2014 18:59, Peter Maydell wrote:
Mm, but once you're into such microoptimisations as this you really
need to have a good justification for the effort, in the form of
profiling measurements that indicate that this is a hot path.
In this case
On 2014/11/23 18:10, Michael S. Tsirkin wrote:
On Tue, Aug 12, 2014 at 05:49:13PM +0800, Tiejun Chen wrote:
v5:
* Simplify to make sure its really inherited from the standard one in patch #3
* Then drop the original patch #3
I carried
i440fx: make types configurable at run-time
On 2014/11/17 14:10, Michael S. Tsirkin wrote:
On Mon, Nov 17, 2014 at 10:47:56AM +0800, Chen, Tiejun wrote:
On 2014/11/5 22:09, Michael S. Tsirkin wrote:
On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
Currently IGD drivers always need to access PCH by 1f.0, and
PCH vendor
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:47:56AM +0800, Chen, Tiejun wrote:
On 2014/11/5 22:09, Michael S. Tsirkin wrote:
On Wed, Nov 05, 2014 at 03
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/5 22:09, Michael S. Tsirkin wrote:
On Wed, Nov 05, 2014 at 03:22:59PM +0800, Tiejun Chen wrote:
Currently IGD drivers always need to access PCH by 1f.0, and
PCH vendor/device id is used to identify the card.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
hw/i386/pc_piix.c |
On 2014/11/3 21:10, Michael S. Tsirkin wrote:
On Mon, Nov 03, 2014 at 01:01:03PM +0100, Paolo Bonzini wrote:
On 03/11/2014 12:47, Chen, Tiejun wrote:
On 2014/11/3 19:36, Chen, Tiejun wrote:
On 2014/11/3 19:35, Paolo Bonzini wrote:
On 03/11/2014 08:48, Chen, Tiejun wrote:
I think the point
1 - 100 of 257 matches
Mail list logo