ound that changing NET_SCH_DEFAULT to
DEFAULT_FQ_CODEL mitigated the problem, having no idea why. Maybe you
can also have a try?
Besides, our testing is pretty complex, do you have a quick test to
reproduce it?
--
Thanks,
Jike
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
nuous security-by-obscurity angle to me).
Hi Robin,
DMA writes will be translated (thereby censored) by DMA Remapping hardware,
while MSI/MSI-X will not. Is this different for non-x86?
--
Thanks,
Jike
> Besides, with Type1 IOMMU
> the fact that we've let a device be assigned at all mea
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
if (ret)
> - return;
> + return 0;
>
> - if (dev_cap & PCI_EXP_DEVCAP_EXT_TAG)
> - pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
> - PCI_EXP_DEVCTL_EXT_TAG);
> + if (dev_cap & PCI_EXP_DEVCAP_EXT_TAG) {
> + supported = pcie_bus_exttags_supported(dev->bus);
> +
Maybe checking the version of this endpoint at first? Do you expect a
v1 endpoint
to be working under v2+ ports?
--
Thanks,
Jike
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.
ace where we expect out of tree vendor drivers.
Personally I like this series :)
Side notes: 1) There is also Documentation to be updated; 2) your mail
address in Author field is @nuc.home?
--
Thanks,
Jike
>
> ---
>
> Alex Williamson (4):
> vfio-mdev: Remove an unused str
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
what is going wrong?
The getting kvm instance code is missing in that branch, will be
contained in the new one.
> Has this version any support for exporting the guest display as dma-buf,
> so qemu can show it? Or is this a headless vgpu?
No, this version doesn't have dma-buf support yet, we were using x11vnc
in guest to test it internally. I'll include you in the igvt-g-dev
mailing list for further discussion :)
--
Thanks,
Jike
kefile
>>>> create mode 100644 samples/vfio-mdev/mtty.c
>>>
>>> As discussed, I dropped patch 12, updated the documentation, and added
>>> 'retries' initialization. This is now applied to my next branch for
>>> v4.10. Thanks to the reviewers and Kirti and Neo for your hard work!
>>
>> Really appreciate your help and reviews to allow us reach here, and thanks to
>> various reviewers for their comments and suggestions!
>>
>
> Thanks for your constant guidance and reviews.
> Thanks to all reviewers for reviews and suggestions.
Echo Alex: thanks for your great work, congrats! :-)
--
Thanks,
Jike
3,8 @@ struct parent_ops {
> ssize_t (*ioctl)(struct mdev_device *mdev, unsigned int cmd,
>unsigned long arg);
> int (*mmap)(struct mdev_device *mdev, struct vm_area_struct *vma);
> + int (*notifier)(struct mdev_device *mdev, unsigned long action,
> + void *data);
> };
>
> /* interface for exporting mdev supported type attributes */
>
Hi Alex, Kirti,
Since everyone agreed we should let the vendor driver call
vfio_register_notifier
directly, can you drop this patch from merging? So that I don't need to send a
reverse patch.
Thanks :)
--
Thanks,
Jike
ce *dev, struct notifier_block *nb)
> +{
> + struct vfio_container *container;
> + struct vfio_group *group;
> + struct vfio_iommu_driver *driver;
> + ssize_t ret;
> +
Any reason being 'ssize_t' here (and unregister)?
--
Thanks,
Jike
> + if (!dev ||
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
y kvm instance, the parent->ops->open() should return -ENODEV
to indicate the failure, but to know whether kvm is available in open(), the
notifier registration should be earlier.
Of course I can call vfio_register_notifier() from an earlier place to
workaround it, but it doesn't seem a canonical w
uct task_struct *task = dma->task;
>> +unsigned long limit = task_rlimit(task, RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>> +bool lock_cap = dma->mlock_cap;
>> +struct mm_struct *mm = dma->addr_space->mm;
>> +int ret;
>> +bool rsvd;
>> +
>> +ret = vaddr_get_pfn(mm, vaddr, prot, pfn_base);
>> +if (ret)
>> +return ret;
>> +
>> +rsvd = is_invalid_reserved_pfn(*pfn_base);
>> +
>> +if (!rsvd && !lock_cap && mm->locked_vm + 1 > limit) {
>> +put_pfn(*pfn_base, prot);
>> +pr_warn("%s: Task %s (%d) RLIMIT_MEMLOCK (%ld) exceeded\n",
>> +__func__, task->comm, task_pid_nr(task),
>> +limit << PAGE_SHIFT);
>> +return -ENOMEM;
>> +}
>> +
>> +if (!rsvd && do_accounting)
>> +vfio_lock_acct(mm, 1);
>> +
>> +return 1;
>> +}
>> +
>> +static void __vfio_unpin_page_external(struct vfio_addr_space *addr_space,
>> + unsigned long pfn, int prot,
>> + bool do_accounting)
>> +{
>> +put_pfn(pfn, prot);
>> +
>> +if (do_accounting)
>> +vfio_lock_acct(addr_space->mm, -1);
>
> Can't we batch this like we do elsewhere? Intel folks, AIUI you intend
> to pin all VM memory through this side channel, have you tested the
> scalability and performance of this with larger VMs? Our vfio_pfn
> data structure alone is 40 bytes per pinned page, which means for
> each 1GB of VM memory, we have 10MBs worth of struct vfio_pfn!
> Additionally, unmapping each 1GB of VM memory will result in 256k
> separate vfio_lock_acct() callbacks. I'm concerned that we're not
> being efficient enough in either space or time.
Hi Alex,
Sorry for being confusing, Intel vGPU actually doesn't necessarily need
to pin all guest memory. A vGPU has its page table (GTT), whose access
is trapped. Whenever guest driver wants to specify a page for DMA, it
writes the GTT entry - thereby we could know the event and pin that
page only.
Performance data will be shared once available. Thanks :)
--
Thanks,
Jike
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
nt, -unlocked);
> @@ -344,14 +474,208 @@ static long vfio_unpin_pages(unsigned long pfn, long
> npage,
> return unlocked;
> }
>
> -static void vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma)
> +static long __vfio_pin_page_external(struct vfio_domain *domain,
> + unsigned long vaddr, int prot,
> + unsigned long *pfn_base,
> + bool do_accounting)
> +{
> + unsigned long limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
> + bool lock_cap = capable(CAP_IPC_LOCK);
> + long ret;
> + bool rsvd;
> + struct task_struct *task = domain->external_addr_space->task;
> +
> + if (!task->mm)
> + return -ENODEV;
> +
> + ret = vaddr_get_pfn(task->mm, vaddr, prot, pfn_base);
Hi Kirti,
In your implementation of vaddr_get_pfn, as long as the 1st argument
is not NULL, you will call get_user_pages_remote other than get_user_pages_fast.
But still there is a possibility here @task is actually @current, thereby
task->mm == current->mm. That should not be rare, but probably happen
at most times: the QEMU process emulates MMIO read/write, and call
vfio_pin_pages in its process context.
If I read correctly, current implementation enforces a locked GUP, no
matter which process context it is in.
--
Thanks,
Jike
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
er the example of QEMU process which creates VFIO container, QEMU
>>>>>> in its teardown path would release the container. How could container be
>>>>>> alive when process is gone?
>>>>>
>>>>> do_exit() in kernel/exit.c calls exit_mm() (which sets NULL to tsk->mm)
>>>>> first, and then releases open files by calling exit_files(). So
>>>>> container's release() does not have current->mm.
>>>>>
>>>>
>>>> Incrementing usage count (get_task_struct()) while saving task structure
>>>> and decementing it (put_task_struct()) from release() should work here.
>>>> Updating the patch.
>>>
>>> I cannot see how the task->usage counter prevents do_exit() from performing
>>> the exit, can you?
>>>
>>
>> It will not prevent exit from do_exit(), but that will make sure that we
>> don't have stale pointer of task structure. Then we can check whether
>> the task is alive and get mm pointer in teardown path as below:
>
>
> Or you could just reference and use @mm as KVM and others do. Or there is
> anything else you need from @current than just @mm?
>
I agree. If @mm is the only thing needed, there is really no reason to
refer to the @task :-)
--
Thanks,
Jike
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
e what this is? Mostly drm-next?
> How much of this landed in the 4.9 merge window?
Yes, mostly drm-next, targeting 4.10 merge window. The overwhelming
part is the device-model under drivers/gpu/drm/i915/gvt/.
--
Thanks,
Jike
_sysfs.c
> create mode 100644 drivers/vfio/mdev/vfio_mdev.c
> create mode 100644 include/linux/mdev.h
A side note:
I rebased KVMGT upon v10, with 2 minor changes:
1, get_user_pages_remote has only 7 args
2, vfio iommu notifier calls vendor callback with iova instead of pfn
so far it works pretty well. Thanks!
--
Thanks,
Jike
ontainer(group);
> +
> +err_pin_pages:
> + vfio_group_put(group);
> + return ret;
> +
> +}
> +EXPORT_SYMBOL(vfio_pin_pages);
> +
> +/*
> + * Unpin set of host PFNs for local domain only.
> + * @dev [in] : device
> + * @pfn [in] : array of host PF
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;
>>> +
t;
> + mutex_lock(&parent->lock);
> +
> + ret = mdev_device_remove_ops(mdev, force_remove);
> + if (ret) {
> + mutex_unlock(&parent->lock);
> + return ret;
> + }
> +
> + mdev_remove_sysfs_files(dev, type);
> +
attributes to be provided by vendor driver. 'name',
> + 'description' and other vendor driver specific attributes
> + are optional.
> +
Hi Kirti,
Is there any checking in the mdev framework that mandatory attributes
are actually pro
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
hods are members of vfio_iommu_driver_ops:
pin_pages
unpin_pages
register_notifier
unregister_notifier
the names of exposed VFIO APIs could possibly be clearer:
vfio_iommu_pin_pages
vfio_iommu_unpin_pages
vfio_iommu_register_notifier
vfio_i
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
+
Hi Kirti,
Like I replied to previous version:
http://www.spinics.net/lists/kvm/msg139331.html
You can always check if mdev_bus_compat_class already registered
here, and register it if not yet. Same logic should be adopted to
mdev_init.
Current implementation will simply panic if configured
&domain->external_addr_space->pfn_list_lock);
> +
> + /* Notify any listeners about DMA_UNMAP */
> + if (vpfn)
> + blocking_notifier_call_chain(&iommu->notifier,
> + VFIO_IOMM
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
ot & IOMMU_WRITE), page) == 1) {
> + if (remote_mm) {
> + down_read(&mm->mmap_sem);
> + ret = get_user_pages_remote(NULL, mm, vaddr, 1,
> + !!(prot & IOMMU_WRITE), 0, page, NULL);
Hi Kirti,
It seems that
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
>
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.
The complete intel vGPU device-model is contained.
--
Thanks,
Jike
refering mdev_bus_type directly you are making vfio_iommu_type1.ko depends
on mdev.ko, but in Kconfig doesn't guarantee the dependency. For example,
if CONFIG_VFIO_IOMMU_TYPE1=y and CONFIG_VFIO_MDEV=m, the building will fail.
--
Thanks,
Jike
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
>
ev_bus_unregister();
> +}
> +
> +module_init(mdev_init)
> +module_exit(mdev_exit)
Hi Kirti,
There is a possible issue: mdev_bus_register is called from mdev_init,
a module_init, equal to device_initcall if builtin to vmlinux; however,
the vendor driver, say i915.ko for intel case, have to call
mdev_register_device from its module_init: at that time, mdev_init
is still not called.
Not sure if this issue exists with nvidia.ko. Though in most cases we
are expecting users select mdev as a standalone module, we still won't
break builtin case.
Hi Alex, do you have any suggestion here?
--
Thanks,
Jike
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 P
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
INIT_DELAYED_WORK(&kvm->arch.kvmclock_update_work, kvmclock_update_fn);
INIT_DELAYED_WORK(&kvm->arch.kvmclock_sync_work, kvmclock_sync_fn);
+ kvm_page_track_init(kvm);
+
return 0;
}
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsub
e you a
page
* dma_map_page() receives that page, programs the system IOMMU and
provides an IOVA
* the GPU MMU can then be programmed with the GPA to IOVA
translations
Thanks for such a nice example! I'll do my home work and get back to you
shortly :
en necessary, ioctl into kernel(i915/vgt)
Alex
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
not mandatory? What should we do if user don't specify an UUID
in QEMU cmdline?
Paolo
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/
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
ementation is
currently not even feature complete - we still have PPGTT missing.
Thanks, Daniel
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.
entation,
CC Andy for his advice :)
Paolo
Thanks for review. Would you please also have a look at the issues I mentioned
in the original email? they are most KVM-related: the SRCU trickiness, domid,
and the memslot created in kernel.
Thank you!
--
Thanks,
Jike
--
To unsubscribe from this list: s
we simply use the q35
lpc device here?
Ditto.
more to come after I've read the paper linked above ...
Thanks for review :)
cheers,
Gerd
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
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
.usenix.org/conference/atc14/technical-sessions/presentation/tian
http://events.linuxfoundation.org/sites/events/files/slides/KVMGT-a%20Full%20GPU%20Virtualization%20Solution_1.pdf
Appreciate your comments, BUG reports, and contributions!
--
Thanks,
Jike
--
To unsubscribe from this list:
aming work in this quarter. For your information,
Wei's IOREQ server enhancement(aka "Extend ioreq-server to support page write
protection")
is actually part of the upstreaming effort.
Patches for different components will be sent out later.
Thanks and Regards,
Dario
-
1.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt
The previous update can be found here:
http://lists.xen.org/archives/html/xen-devel/2014-02/msg01848.html
Appreciate your comments!
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
cores. If
I enable "Node Interleaving" in BIOS' Memory Setting, and boot the
kernel, the SRAT table will be invisible to Linux - results the same
topology as you got. If I disable "Node Interleaving" and boot the
kernel, SRAT is present, and the topology is correct.
Hope
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
tchdog=1 work on any other amd64 platform?
>
I booted 2.6.23 on a HP NX6325 laptop with nmi_watchdog=1, and dmesg says,
...
..MP-BIOS bug: 8254 timer not connected to IO-APIC
timer doesn't work through the IO-APIC - disabling NMI Watchdog!
nmi_watchdog remains to be 0, as I read by a si
thout any relationship with its function.
Regards,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 "unsubscri
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 A
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
t;unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
= = = = = = = = = = = = = = = = = = = =
jike Zhou
[EMAIL PROTECTED]
-
To u
100 matches
Mail list logo
