Hi Josh,
On Fri, Jul 3, 2020 at 2:14 AM Josh Hunt wrote:
{snip}
> Initial results with Cong's patch look promising, so far no stalls. We
> will let it run over the long weekend and report back on Tuesday.
>
> Paolo - I have concerns about possible performance regression with the
> change as well.
Commit-ID: 8d56eff266f3e41a6c39926269c4c3f58f881a8e
Gitweb: https://git.kernel.org/tip/8d56eff266f3e41a6c39926269c4c3f58f881a8e
Author: Jike Song
AuthorDate: Tue, 9 Jan 2018 00:03:41 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 8 Jan 2018 17:42:13 +0100
x86/mm/pti: Remove dead
t; Now that it is all single-threaded, there is no chance of a collision,
> no need for a lock, and no need for the re-check.
v3: mark functions __init; add first-hand explanation
v2: add commit message.
Signed-off-by: Jike Song
Cc: David Woodhouse
Cc: Alan Cox
Cc: Jiri Koshina
Cc: Linus T
On Sun, Jan 7, 2018 at 5:48 PM, Thomas Gleixner wrote:
> On Sun, 7 Jan 2018, Jike Song wrote:
>> On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner wrote:
>> > On Sun, 7 Jan 2018, Jike Song wrote:
>> >
>> > Care to explain why you think this is not needed?
>&g
.
v2: add the commit message above.
Signed-off-by: Jike Song
Cc: David Woodhouse
Cc: Alan Cox
Cc: Jiri Koshina
Cc: Linus Torvalds
Cc: Tim Chen
Cc: Andi Lutomirski
Cc: Andi Kleen
Cc: Peter Zijlstra
Cc: Paul Turner
Cc: Tom Lendacky
Cc: Greg KH
Cc: Dave Hansen
Cc: Kees Coo
On Sun, Jan 7, 2018 at 4:03 AM, Willy Tarreau wrote:
> On Sun, Jan 07, 2018 at 01:50:59AM +0800, Jike Song wrote:
>> Signed-off-by: Jike Song
>
> It would be nice to have a commit message, particularly in this quite
> sensitive series...
Yes that's useful, will add
On Sun, Jan 7, 2018 at 3:33 AM, Thomas Gleixner wrote:
> On Sun, 7 Jan 2018, Jike Song wrote:
>
> Care to explain why you think this is not needed?
>
Hi Thomas,
Look at one of the original code snippets:
162 if (pgd_none(*pgd)) {
163 unsigned long
Signed-off-by: Jike Song
---
arch/x86/mm/pti.c | 28
1 file changed, 4 insertions(+), 24 deletions(-)
diff --git a/arch/x86/mm/pti.c b/arch/x86/mm/pti.c
index 43d4a4a29037..dc611d039bd5 100644
--- a/arch/x86/mm/pti.c
+++ b/arch/x86/mm/pti.c
@@ -164,12 +164,7
On 08/14/2017 09:12 PM, Robin Murphy wrote:
> On 14/08/17 10:45, Alexey Kardashevskiy wrote:
>> Folks,
>>
>> Is there anything to change besides those compiler errors and David's
>> comment in 5/5? Or the while patchset is too bad? Thanks.
>
> While I now understand it's not the low-level thing I
On 08/15/2017 09:33 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2017-08-15 at 09:16 +0800, Jike Song wrote:
>>> Taking a step back, though, why does vfio-pci perform this check in the
>>> first place? If a malicious guest already has control of a device, any
>>> kind
On Wed, Jul 5, 2017 at 9:19 PM, Sinan Kaya wrote:
> According to extended tags ECN document, all PCIe receivers are expected
> to support extended tags support. It should be safe to enable extended
> tags on endpoints without checking compatibility.
>
> This assumption seems to be working fine exc
the spinlock from the invalid reference, but
> other failure modes are clearly possible. Hold a reference to avoid
> this.
>
> Signed-off-by: Alex Williamson
> Cc: sta...@vger.kernel.org #v4.10
> Cc: Jike Song
> Cc: Paolo Bonzini
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> -
Williamson
> ---
>
> This should really be fixed before initial release in v4.10
Acked-by: Jike Song
Thanks for finding this!
--
Thanks,
Jike
>
> drivers/gpu/drm/i915/gvt/kvmgt.c |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/driver
has_capability() is sometimes needed by modules to test capability
for specified task other than current, so export it.
Cc: Alex Williamson
Cc: Kirti Wankhede
Acked-by: Serge Hallyn
Signed-off-by: Jike Song
---
kernel/capability.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel
is, in a specified namespace.
Fix it by using has_capability() instead, which tests the cap for
specified task in init_user_ns, the same namespace as capable().
Cc: Alex Williamson
Cc: Kirti Wankhede
Cc: Gerd Hoffmann
Signed-off-by: Jike Song
---
drivers/vfio/vfio_iommu_type1.c | 3 +--
1
process
Hi Alex,
I kept EXPORT_SYMBOL other than EXPORT_SYMBOL_GPL, since I'm still
worry about changing the type of existing exports in 'capability.c'.
I'm new to open-source fearing of violating GPL :)
Jike Song (2):
capability: export has_capability
vfio iommu type1: fix the t
On 01/12/2017 02:47 AM, Alex Williamson wrote:
> On Thu, 22 Dec 2016 00:10:15 +0800
> Jike Song wrote:
>
>> has_capability() is sometimes needed by modules to test capability
>> for specified task other than current, so export it.
>>
>> Cc: Alex Williamson
>
On 12/22/2016 08:20 PM, Kirti Wankhede wrote:
> On 12/21/2016 9:40 PM, Jike Song wrote:
>> Before the mdev enhancement type1 iommu used capable() to test the
>> capability of current task; in the course of mdev development a
>> new requirement, testing for another task ot
Not sure if this is appropriate, but if not having the Documentation considered,
for patch 2-4:
Reviewed-by: Jike Song
--
Thanks,
Jike
On 12/22/2016 07:27 AM, Alex Williamson wrote:
> From: Alex Williamson
>
> Add an mdev_ prefix so we're not poluting the namespace so much.
On 12/22/2016 07:27 AM, Alex Williamson wrote:
> Cleanup the namespace a bit by prefixing structures with mdev_ and
> also more concretely define the mdev interface. Structs with comments
> defining which fields are private vs public tempts poor behavior,
> especially for an interface where we exp
has_capability() is sometimes needed by modules to test capability
for specified task other than current, so export it.
Cc: Alex Williamson
Cc: Kirti Wankhede
Signed-off-by: Jike Song
---
kernel/capability.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/capability.c b/kernel
is, in a specified namespace.
Fix it by using has_capability() instead, which tests the cap for
specified task in init_user_ns, the same namespace as capable().
Cc: Alex Williamson
Cc: Kirti Wankhede
Cc: Gerd Hoffmann
Signed-off-by: Jike Song
---
drivers/vfio/vfio_iommu_type1.c | 6 ++
1
symbols allows a specified task. So here has_capability()
is exported then used in the vfio iommu type1 driver.
Jike Song (2):
capability: export has_capability
vfio iommu type1: fix the testing of capability for remote task
drivers/vfio/vfio_iommu_type1.c | 6 ++
kernel/capability.c
On 12/06/2016 01:44 AM, Gerd Hoffmann wrote:
> Hi,
>
>> Just want to share that we have published a KVMGT implementation
>> based on this v9 patchset, to:
>>
>> https://github.com/01org/gvt-linux/tree/gvt-next-kvmgt
>>
>> It doesn't utilize common routines introduced by 05+ patches yet.
>>
On 11/18/2016 10:00 AM, Kirti Wankhede wrote:
> On 11/18/2016 3:35 AM, Neo Jia wrote:
>> On Thu, Nov 17, 2016 at 02:25:15PM -0700, Alex Williamson wrote:
>>> On Thu, 17 Nov 2016 02:16:12 +0530
>>> Kirti Wankhede wrote:
Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111 ++
Docume
On 11/17/2016 04:46 AM, Kirti Wankhede wrote:
> Add a notifier calback to parent's ops structure of mdev device so that per
> device notifer for vfio module is registered through vfio_mdev module.
>
> Signed-off-by: Kirti Wankhede
> Signed-off-by: Neo Jia
> Change-Id: Iafa6f1721aecdd6e50eb93b153
On 11/17/2016 04:46 AM, Kirti Wankhede wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Notifier should be registered, if external user wants to use
> vfio_pin_pages()/vf
On 11/15/2016 11:19 PM, Alex Williamson wrote:
> On Tue, 15 Nov 2016 14:45:42 +0800
> Jike Song wrote:
>
>> On 11/14/2016 11:42 PM, Kirti Wankhede wrote:
>>> Add a notifier calback to parent's ops structure of mdev device so that per
>>> device notifer
On 11/15/2016 04:11 PM, Kirti Wankhede wrote:
>
>
> On 11/15/2016 12:15 PM, Jike Song wrote:
>> On 11/14/2016 11:42 PM, Kirti Wankhede wrote:
>>> Add a notifier calback to parent's ops structure of mdev device so that per
>>> device notifer for vfio module
On 11/14/2016 11:42 PM, Kirti Wankhede wrote:
> Add a notifier calback to parent's ops structure of mdev device so that per
> device notifer for vfio module is registered through vfio_mdev module.
>
> Signed-off-by: Kirti Wankhede
> Signed-off-by: Neo Jia
> Change-Id: Iafa6f1721aecdd6e50eb93b153
On 11/08/2016 07:16 AM, Alex Williamson wrote:
> On Sat, 5 Nov 2016 02:40:44 +0530
> Kirti Wankhede wrote:
>
>> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
>> Mediated device only uses IOMMU APIs, the underlying hardware can be
>> managed by an IOMMU domain.
>>
>> Aim
uct nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 07/20/2016 12:52 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for KVM.
>
> Intel GVT-g f
work in progress. As such it is
not a complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 07/22/2016 01:42 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another
rship provides privilege, if the group
> + * list is empty, the domain goes away. If it's the
> + * last domain, then all the mappings go away too.
> + */
> + if (list_empty(&domain->group_list)) {
> + if (list_is_singular(&iommu->domain_list))
> + vfio_iommu_unmap_unpin_all(iommu);
> + iommu_domain_free(domain->domain);
> + list_del(&domain->next);
> + kfree(domain);
> }
> + goto done;
> }
>
> done:
>
Reviewed-by: Jike Song
--
Thanks,
Jike
On 11/02/2016 09:18 PM, Kirti Wankhede wrote:
> On 11/2/2016 6:30 PM, Jike Song wrote:
>> On 11/02/2016 08:41 PM, Kirti Wankhede wrote:
>>> On 11/2/2016 5:51 PM, Jike Song wrote:
>>>> On 11/02/2016 12:09 PM, Alexey Kardashevskiy wrote:
>>>>> Or yo
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
> Mediated device only uses IOMMU APIs, the underlying hardware can be
> managed by an IOMMU domain.
>
> Aim of this change is:
> - To use most of the code of TYPE1 IOMMU driver
On 11/02/2016 08:41 PM, Kirti Wankhede wrote:
> On 11/2/2016 5:51 PM, Jike Song wrote:
>> On 11/02/2016 12:09 PM, Alexey Kardashevskiy wrote:
>>> Or you could just reference and use @mm as KVM and others do. Or there is
>>> anything else you need from @current than just
On 11/02/2016 12:09 PM, Alexey Kardashevskiy wrote:
> On 02/11/16 14:29, Kirti Wankhede wrote:
>>
>>
>> On 11/2/2016 6:54 AM, Alexey Kardashevskiy wrote:
>>> On 02/11/16 01:01, Kirti Wankhede wrote:
On 10/28/2016 7:48 AM, Alexey Kardashevskiy wrote:
> On 27/10/16 23:31, Kirti Wan
ner_users);
> - return ERR_PTR(-EPERM);
> - }
> -
> - if (!group->container->iommu_driver ||
> - !vfio_group_viable(group)) {
> - atomic_dec(&group->container_users);
> - return ERR_PTR(-EINVAL);
> - }
> + ret = vfio_group_add_container_user(group);
> + if (ret)
> + return ERR_PTR(ret);
>
> vfio_group_get(group);
>
Reviewed-by: Jike Song
--
Thanks,
Jike
iommu_group_get(dev);
> - if (!iommu_group)
> - return NULL;
> -
> - group = vfio_group_get_from_iommu(iommu_group);
> - iommu_group_put(iommu_group);
> + group = vfio_group_get_from_dev(dev);
> if (!group)
> return NULL;
>
Reviewed-by: Jike Song
--
Thanks,
Jike
_mdev_dev_ops, mdev);
> +}
> +
> +void vfio_mdev_remove(struct device *dev)
> +{
> + vfio_del_group_dev(dev);
> +}
> +
> +struct mdev_driver vfio_mdev_driver = {
> + .name = "vfio_mdev",
> + .probe = vfio_mdev_probe,
> + .remove = vfio_mdev_remove,
> +};
> +
> +static int __init vfio_mdev_init(void)
> +{
> + return mdev_register_driver(&vfio_mdev_driver, THIS_MODULE);
> +}
> +
> +static void __exit vfio_mdev_exit(void)
> +{
> + mdev_unregister_driver(&vfio_mdev_driver);
> +}
> +
> +module_init(vfio_mdev_init)
> +module_exit(vfio_mdev_exit)
> +
> +MODULE_VERSION(DRIVER_VERSION);
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
>
Reviewed-by: Jike Song
--
Thanks,
Jike
On 11/02/2016 03:59 PM, Kirti Wankhede wrote:
> On 10/29/2016 11:41 PM, Jike Song wrote:
>> On 10/29/2016 06:06 PM, Kirti Wankhede wrote:
>>>
>>>
>>> On 10/29/2016 10:00 AM, Jike Song wrote:
>>>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
&g
On 11/01/2016 11:24 PM, Gerd Hoffmann wrote:
>> I rebased KVMGT upon v10, with 2 minor changes:
>>
>> 1, get_user_pages_remote has only 7 args
>
> Appears to be a 4.9 merge window change. v10 as-is applies and builds
> fine against 4.8, after rebasing to 4.9-rc3 it stops building due to
> th
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> This series adds Mediated device support to Linux host kernel. Purpose
> of this series is to provide a common interface for mediated device
> management that can be used by different devices. This series introduces
> Mdev core module that creates and
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added two new callback functions to struct vfio_iommu_driver_ops. Backend
> IOMMU module that supports pining and unpinning pages for mdev devices
> should provide these functions.
> Added APIs for pining and unpining pages to VFIO module. These calls
On 11/01/2016 11:44 AM, Alex Williamson wrote:
> On Tue, 01 Nov 2016 11:08:15 +0800
> Jike Song wrote:
>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
>>> +static int mdev_attach_iommu(struct mdev_device *mdev)
>>> +{
>>> + int ret;
>>> +
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Design for Mediated Device Driver:
> Main purpose of this driver is to provide a common interface for mediated
> device management that can be used by different drivers of different
> devices.
>
> This module provides a generic interface to create th
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added details of sysfs ABI for mediated device framework
>
> Signed-off-by: Kirti Wankhede
> Signed-off-by: Neo Jia
> Change-Id: Icb0fd4ed58a2fa793fbcb1c3d5009a4403c1f3ac
> ---
> Documentation/ABI/testing/sysfs-bus-vfio-mdev | 111
> +
On 10/31/2016 01:59 PM, Kirti Wankhede wrote:
> On 10/31/2016 9:20 AM, Jike Song wrote:
>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
>>> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
>>> about DMA_UNMAP.
>>> Exported t
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Vendor driver should register notifer using these APIs.
> Vendor driver should use
On 10/29/2016 06:06 PM, Kirti Wankhede wrote:
>
>
> On 10/29/2016 10:00 AM, Jike Song wrote:
>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
>>> +int mdev_register_device(struct device *dev, const struct parent_ops *ops)
>>> +{
>>> + int
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> +int mdev_register_device(struct device *dev, const struct parent_ops *ops)
> +{
> + int ret;
> + struct parent_device *parent;
> +
> + /* check for mandatory ops */
> + if (!ops || !ops->create || !ops->remove || !ops->supported_type_
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Added blocking notifier to IOMMU TYPE1 driver to notify vendor drivers
> about DMA_UNMAP.
> Exported two APIs vfio_register_notifier() and vfio_unregister_notifier().
> Vendor driver should register notifer using these APIs.
> Vendor driver should use
On 10/27/2016 08:24 PM, Kirti Wankhede wrote:
>
>
> On 10/27/2016 5:41 PM, Jike Song wrote:
>> On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
>>> Update arguments of vaddr_get_pfn() to take struct mm_struct *mm as input
>>> argument.
>>>
>>> Si
On 10/27/2016 05:29 AM, Kirti Wankhede wrote:
> Update arguments of vaddr_get_pfn() to take struct mm_struct *mm as input
> argument.
>
> Signed-off-by: Kirti Wankhede
> Signed-off-by: Neo Jia
> Change-Id: I885fd4cd4a9f66f4ee2c1caf58267464ec239f52
> ---
> drivers/vfio/vfio_iommu_type1.c | 25 ++
On 10/21/2016 01:12 AM, Alex Williamson wrote:
> On Thu, 20 Oct 2016 15:23:53 +0800
> Jike Song wrote:
>
>> On 10/18/2016 05:22 AM, Kirti Wankhede wrote:
>>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
>>> new file mode 100644
>
On 10/18/2016 05:22 AM, Kirti Wankhede wrote:
> This series adds Mediated device support to Linux host kernel. Purpose
> of this series is to provide a common interface for mediated device
> management that can be used by different devices. This series introduces
> Mdev core module that creates and
On 10/18/2016 05:22 AM, Kirti Wankhede wrote:
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 2ba19424e4a1..5d67058a611d 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
[snip]
> static int vfio_iommu_type1_attach_group
On 10/21/2016 01:12 AM, Alex Williamson wrote:
> On Thu, 20 Oct 2016 15:23:53 +0800
> Jike Song wrote:
>
>> On 10/18/2016 05:22 AM, Kirti Wankhede wrote:
>>> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
>>> new file mode 100644
>
On 10/18/2016 05:22 AM, Kirti Wankhede wrote:
> diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
> new file mode 100644
> index ..7db5ec164aeb
> --- /dev/null
> +++ b/drivers/vfio/mdev/mdev_core.c
> @@ -0,0 +1,372 @@
> +/*
> + * Mediated device Core Driver
> +
complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 04/28/2016 01:29 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
&
be taken
when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 04/16/2016 02:31 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for KVM.
>
> Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualiza
product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 01/27/2016 02:21 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
>
> Intel GVT
ote:
The KVMGT project should be considered a work in progress. As such it is not a
complete product nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 01/27/2016 02:32 PM, Jike Song wrote:
> Hi all,
&
On 02/23/2016 06:01 PM, Paolo Bonzini wrote:
> - Original Message -
>> From: "Jike Song"
>> To: "Xiao Guangrong"
>> Cc: "Paolo Bonzini" , g...@kernel.org,
>> mtosa...@redhat.com, k...@vger.kernel.org,
>> linux-kernel@vger.ke
+Kevin
On 02/22/2016 06:05 PM, Xiao Guangrong wrote:
>
> On 02/19/2016 08:00 PM, Paolo Bonzini wrote:
>>
>> I still have a doubt: how are you going to handle invalidation of GPU
>> shadow page tables if a device (emulated in QEMU or even vhost) does DMA
>> to the PPGTT?
>
> I think Jike is the b
such it is
not a complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 10/27/2015 05:36 PM, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-
/blogs/srclarkx/2013/graphics-virtualization-xengt
Note: The XenGT project should be considered a work in progress. As such it is
not a complete product nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 12/01/2015 02:26 AM, Xiao Guangrong wrote:
Notifier list is introduced so that any node wants to receive the track
event can register to the list
Two APIs are introduced here:
- kvm_page_track_register_notifier(): register the notifier to receive
track event
- kvm_page_track_unregister_no
On 11/21/2015 01:25 AM, Alex Williamson wrote:
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
Here is a more concrete example:
KVMGT doesn't require IOMMU. All DMA targets are already replaced with
HPA thru shadow GTT. So DMA requests from GPU all contain HPAs.
When IOMMU is enabled, o
On 11/21/2015 12:40 AM, Alex Williamson wrote:
Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
if we take XenGT to consider, it will be a bit more complex: with Xen
hypervisor and Dom0 kernel running in different level, it's not a straight-
forward way for QEMU to do
On 11/20/2015 12:22 PM, Alex Williamson wrote:
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM an
On 11/19/2015 07:09 PM, Paolo Bonzini wrote:
On 19/11/2015 09:40, Gerd Hoffmann wrote:
But this code should be
minor to be maintained in libvirt.
As far I know libvirt only needs to discover those devices. If they
look like sr/iov devices in sysfs this might work without any changes to
libvirt
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about h
configuring a system to use the KVMGT project.
--
Thanks,
Jike
On 12/04/2014 10:24 AM, Jike Song wrote:
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is the
implementation of Intel GVT-g technology, a full GPU virtualization solution.
Under Intel GVT-g, a virtual
uch it is not
a complete product nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 07/07/2015 10:49 AM, Jike Song wrote:
Hi all,
We're pleased to announce a public update to Intel Graphics Virtuali
t nor should it be considered one. Extra care should be
taken when testing and configuring a system to use the XenGT project.
--
Thanks,
Jike
On 04/10/2015 09:23 PM, Jike Song wrote:
Hi all,
We're pleased to announce a public update to Intel Graphics Virtualization
Technology (I
Whoops. Changed the title from "2015-Q1" to be "2014-Q4" :)
--
Thanks,
Jike
On 01/09/2015 04:51 PM, Jike Song wrote:
Hi all,
We're pleased to announce a public update to Intel Graphics Virtualization
Technology (Intel GVT-g, formerly known as XenGT). Intel
ments!
--
Thanks,
Jike
On 12/04/2014 10:45 AM, Jike Song wrote:
Hi all,
We're pleased to announce a public release to Intel Graphics Virtualization
Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete
vGPU solution with mediated pass-through, supported today on 4th
CC Kevin.
On 12/09/2014 05:54 PM, Jan Kiszka wrote:
On 2014-12-04 03:24, Jike Song wrote:
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is
the implementation of Intel GVT-g technology, a full GPU virtualization
solution. Under Intel GVT-g, a virtual GPU
CC Kevin.
On 12/09/2014 05:54 PM, Jan Kiszka wrote:
On 2014-12-04 03:24, Jike Song wrote:
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is
the implementation of Intel GVT-g technology, a full GPU virtualization
solution. Under Intel GVT-g, a virtual GPU
On 12/05/2014 09:54 PM, Daniel Vetter wrote:
Yeah done a quick read-through of just the i915 bits too, same comment. I
guess this is just the first RFC and the redesign we've discussed about
already with xengt is in progress somewhere?
Yes, it's marching on with Xen now. The KVM implementation
CC Andy :)
On 12/05/2014 09:03 PM, Paolo Bonzini wrote:
On 05/12/2014 09:50, Gerd Hoffmann wrote:
A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).
* Noticed the kernel bits don't even compile when configured as
mo
On 12/05/2014 04:50 PM, Gerd Hoffmann wrote:
A few comments on the kernel stuff (brief look so far, also
compile-tested only, intel gfx on my test machine is too old).
* Noticed the kernel bits don't even compile when configured as
module. Everything (vgt, i915, kvm) must be compiled into
phics-virtualization-xengt
The previous update can be found here:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg03248.html
Appreciate your comments!
--
Thanks,
Jike
On 07/25/2014 04:31 PM, Jike Song wrote:
Hi all,
We're pleased to announce an update to Intel Graphics Virt
Hi all,
We are pleased to announce the first release of KVMGT project. KVMGT is the
implementation of Intel GVT-g technology, a full GPU virtualization solution.
Under Intel GVT-g, a virtual GPU instance is maintained for each VM, with part
of performance critical resources directly assigned.
On 07/29/2014 06:09 PM, Dario Faggioli wrote:
Perhaps the info is available somewhere already (in which case, sorry),
but what's the (if any) upstreaming plan/status/ETA?
I think this info could well be part of these updates. :-)
Thanks for your opinion :-)
We plan to start the upstreaming wo
Hi all,
We're pleased to announce an update to Intel Graphics Virtualization Technology
(Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution
with mediated pass-through, supported today on 4th generation Intel Core(TM)
processors with Intel Graphics processors. A virt
On Tue, Sep 18, 2012 at 2:00 AM, Linda Walsh wrote:
> Does the kernel support scheduling based on the different speed of
> memory between "on die" vs. "off die"? I was surprised to see
> that it viewed my system as 1 NUMA node with all 12 on 1 node -- when
> I know that it is physically organize
On Fri, Jul 13, 2012 at 9:04 PM, Chris Webb wrote:
> Commit c2c20ef43d00 "bnx2: Update driver to use new mips firmware"
> updated the bnx2 driver to use bnx2-mips-09-6.2.1b in place of
> bnx2-mips-09-6.2.1a, but didn't replace the copy of bnx2-mips-09-6.2.1a
> in firmware/bnx2/ with the new versio
On Tue, Oct 16, 2007 at 10:12 AM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
> just found my on hand ck804, and mcp55 based AMD servers:
> nmi_watchdog=1 doesn't work
> but nmi_watchdog=2 does work
>
> =1, it say: IOAPIC 8259A virtual wire mode...
>
> Did nmi_watchdog=1 work on any other amd64 platf
On 2/8/08, Max Krasnyansky <[EMAIL PROTECTED]> wrote:
> Hi Rusty,
>
> I was hopping you could answer a couple of questions about module
> loading/unloading
> and the stop machine.
I'm curious to know why it is called `stop machine', which is a queer
name without any relationship with its function
On 2/1/08, Andi Kleen <[EMAIL PROTECTED]> wrote:
> There are right no CPUs shipping which implement x2apic.
Thanks for your information.
> "Jike Song" <[EMAIL PROTECTED]> writes:
> > Maybe. I have a question as well, what about the status of I/O
> &g
On 2/1/08, Rijndael Cosque <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I found the x2APIC spec via http://www.intel.com/products/processor/manuals/.
>
> Looks at present there is no x2APIC support in Linux kernel 2.6.24?
>
> Is there any experimental patch available for Linux kernel? -- I
> googled "x
Hello Jeff,
I'm sorry for the previous patch, which was mangled by gmail, with
some broken lines.
I'm trying to resend it by git-send-email. Please let me know in case
of any problems.
Thanks a lot.
Best Regards,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
The pci-skeleton.c has several problems with compilation, such as missing args
when calling synchronize_irq(). Fix it.
Signed-off-by: Jike Song <[EMAIL PROTECTED]>
---
drivers/net/pci-skeleton.c | 49 ++-
1 files changed, 25 insertions(+), 24 del
On 1/23/08, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> ACK but git-am (everybody's patch import tool) says the patch is corrupted
>
Hi Jeff,
Thank you very much for your acknowledgement! This is my first patch
for Linux kernel, sorry for the corruption. I'll resend it ASAP.
Regards,
Jike
--
To
Hello Jeff,
The pci-skeleton.c has several problems with compilation, such as missing args
when calling synchronize_irq(). Fix it.
Signed-off-by: Jike Song <[EMAIL PROTECTED]>
---
drivers/net/pci-skeleton.c | 49 ++-
1 files changed, 25 inse
99 matches
Mail list logo
