On 4/20/22 7:08 AM, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
>> pull requests can flow through more than one tree concurrently. The
>> purpose of the topic branch is to allow all the commits to be in all
>> the trees they need to be in at once.
>>
On Thu, Apr 14, 2022 at 02:25:36PM +, Wang, Zhi A wrote:
> > So drop the '[DONT PULL]' commit and send a PR to the next DRM tree -
> > when that is confirmed send the same PR to vfio,
>
> I updated the branch again, but I am confused. What is the purpose of sending
> the PR to next DRM tree?
On 4/14/22 1:43 PM, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
>
>> git clone https://github.com/intel/gvt-linux -b for-christoph
>
> There are alot of extra commits on there - is it possible to base this
> straight on rc1 not on some
On Thu, 14 Apr 2022, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 01:39:11PM +, Wang, Zhi A wrote:
>> This one belongs to i915, which has already been queued in drm-intel-next,
>> but
>> not yet reached to the top. When it is landed in -rc, I will rebase this
>> branch
>> on it, then we
On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
> >> >> git clone https://github.com/intel/gvt-linux -b for-christoph
> >> >
> >> > There are alot of extra commits on there - is it possible to base this
> >> > straight on rc1 not on some kind of existing DRM tree?
> >> >
> >> > Why
On Thu, Apr 14, 2022 at 01:39:11PM +, Wang, Zhi A wrote:
> On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 14, 2022 at 12:20:42PM +, Wang, Zhi A wrote:
> >> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> >>> On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
> Hi
On Thu, 14 Apr 2022, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 12:20:42PM +, Wang, Zhi A wrote:
>> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
>> > On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
>> >> Hi folks:
>> >>
>> >> Thanks so much for the efforts. I prepared a
On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 12:20:42PM +, Wang, Zhi A wrote:
>> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
>>> On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
Hi folks:
Thanks so much for the efforts. I prepared a branch
On Thu, Apr 14, 2022 at 12:20:42PM +, Wang, Zhi A wrote:
> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> > On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
> >> Hi folks:
> >>
> >> Thanks so much for the efforts. I prepared a branch which contains all our
> >> patches.The aim of
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Thanks so much for the efforts. I prepared a branch which contains all our
>> patches.The aim of the branch is for the VFIO maintainers to pull the whole
>> bunch easily
On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
> Hi folks:
>
> Thanks so much for the efforts. I prepared a branch which contains all our
> patches.The aim of the branch is for the VFIO maintainers to pull the whole
> bunch easily after the drm-intel-next got merged through drm
Hi folks:
Thanks so much for the efforts. I prepared a branch which contains all our
patches.The aim of the branch is for the VFIO maintainers to pull the whole
bunch easily after the drm-intel-next got merged through drm (as one of the
MMIO patches depends on a patch in drm-intel-next).
I
On Wed, 13 Apr 2022, Christoph Hellwig wrote:
> On Wed, Apr 13, 2022 at 01:47:05PM +, Wang, Zhi A wrote:
>> > the GVT code in the i915 is a bit of a mess right now due to strange
>> > abstractions and lots of indirect calls. This series refactors various
>> > bits to clean that up. The main
On 4/11/22 2:13 PM, Christoph Hellwig wrote:
> Hi all,
>
> the GVT code in the i915 is a bit of a mess right now due to strange
> abstractions and lots of indirect calls. This series refactors various
> bits to clean that up. The main user visible change is that almost all
> of the GVT code
Quoting Christoph Hellwig (2021-11-09 09:59:57)
> On Thu, Nov 04, 2021 at 02:59:18PM +0200, Joonas Lahtinen wrote:
> > The minimal we should do is to eliminate the double underscore
> > prefixed functions. But I would prefer to have the symbol exports by
> > default so that we can enable the
-...@lists.freedesktop.org;
intel-gvt-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
linux-ker...@vger.kernel.org
Subject: Re: refactor the i915 GVT support and move to the modern mdev API v2
Hi Zhenyu and Zhi,
Can you have somebody from the GVT team to review the patches that are fully
Hi Zhenyu and Zhi,
Can you have somebody from the GVT team to review the patches that
are fully contained in gvt/ ?
I also started discussion on patch 6 which is about defining the
interface between the modules. I remember there is prior work to shrink
the interface. Do you have links to such
Hi folks:
It seems we haven't reached a possible solution of this refactor patch
series. The current patch series needs to be re-worked because of the
module/symbol dependency(The root cause has been discussed in another
email). I have to get them off from our gvt-next repo so that we can
On 9/29/21 6:55 PM, Jason Gunthorpe wrote:
> On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote:
>> On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
>>> On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
>>>
Yes. I was thinking of the possibility of putting off some work later so
On Wed, Sep 29, 2021 at 06:27:16PM +, Wang, Zhi A wrote:
> On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> > On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> >
> >> Yes. I was thinking of the possibility of putting off some work later so
> >> that we don't need to make a lot of
On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
>
>> Yes. I was thinking of the possibility of putting off some work later so
>> that we don't need to make a lot of changes. GVT-g needs to take a
>> snapshot of GPU registers as the initial
On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
> Yes. I was thinking of the possibility of putting off some work later so
> that we don't need to make a lot of changes. GVT-g needs to take a
> snapshot of GPU registers as the initial virtual states for other vGPUs,
> which
On 9/28/21 2:00 PM, Luis Chamberlain wrote:
> On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
>> Hey guys:
>>
>> After some investigation, I found the root cause this problem ("i915"
>> module loading will be stuck with Christoph's refactor patches), which
>> can be reproduced by
On Tue, Sep 28, 2021 at 07:41:00AM +, Wang, Zhi A wrote:
> Hey guys:
>
> After some investigation, I found the root cause this problem ("i915"
> module loading will be stuck with Christoph's refactor patches), which
> can be reproduced by building both i915 and kvmgt as kernel module and
>
Hey guys:
After some investigation, I found the root cause this problem ("i915"
module loading will be stuck with Christoph's refactor patches), which
can be reproduced by building both i915 and kvmgt as kernel module and
the loading i915.
The root cause is: in Linux kernel loading, before a
On 2021.08.20 12:56:34 -0700, Luis Chamberlain wrote:
> On Fri, Aug 20, 2021 at 04:17:24PM +0200, Christoph Hellwig wrote:
> > On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > > I'm working on below patch to resolve this. But I met a weird issue in
> > > case when building i915 as
On 2021.08.20 16:17:24 +0200, Christoph Hellwig wrote:
> On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > I'm working on below patch to resolve this. But I met a weird issue in
> > case when building i915 as module and also kvmgt module, it caused
> > busy wait on
On 2021.08.19 17:43:43 +0300, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2021-08-19 11:29:29)
> > On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > > Any updates on this? I'd really hate to miss this merge window.
> > > >
>
On Fri, Aug 20, 2021 at 04:17:24PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > I'm working on below patch to resolve this. But I met a weird issue in
> > case when building i915 as module and also kvmgt module, it caused
> > busy wait on
Quoting Zhenyu Wang (2021-08-19 11:29:29)
> On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > > Any updates on this? I'd really hate to miss this merge window.
> > >
> > > I'm still waiting for our validation team's report on
On 2021.08.17 13:22:03 +0800, Zhenyu Wang wrote:
> > On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > > Any updates on this? I'd really hate to miss this merge window.
> >
> > I'm still waiting for our validation team's report on this. I'm afraid
> > it might be missing for next
On 2021.08.17 09:08:55 +0800, Zhenyu Wang wrote:
> On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> > On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> > > On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > > > On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
On 2021.08.16 19:34:58 +0200, Christoph Hellwig wrote:
> On Wed, Aug 04, 2021 at 01:26:06PM +0800, Zhenyu Wang wrote:
> > On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> > > On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> > > > Acked-by: Zhenyu Wang
> > > >
> > > > Thanks a
On 2021.08.03 11:30:58 -0300, Jason Gunthorpe wrote:
> On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> > Acked-by: Zhenyu Wang
> >
> > Thanks a lot for this effort!
>
> Great, do we have a submission plan for this? how much does it clash
> with my open_device/etc patch? ie does
On Tue, Aug 03, 2021 at 05:43:15PM +0800, Zhenyu Wang wrote:
> Acked-by: Zhenyu Wang
>
> Thanks a lot for this effort!
Great, do we have a submission plan for this? how much does it clash
with my open_device/etc patch? ie does the whole thing have to go
through the vfio tree?
Thanks,
Jason
On 2021.07.29 09:20:22 +0200, Christoph Hellwig wrote:
> On Wed, Jul 28, 2021 at 02:59:25PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
> >
> > > I guess those APIs you were talking about are KVM-only. For other
> > > hypervisors, e.g. Xen, ARCN
On 7/28/2021 8:59 PM, Jason Gunthorpe wrote:
> On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
>
>> I guess those APIs you were talking about are KVM-only. For other
>> hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
>> sure if you have already noticed that VFIO is
On Wed, Jul 28, 2021 at 01:38:58PM +, Wang, Zhi A wrote:
> I guess those APIs you were talking about are KVM-only. For other
> hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
> sure if you have already noticed that VFIO is KVM-only right now.
There is very little hard
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I
ts.freedesktop.org;
intel-gvt-...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
dri-devel@lists.freedesktop.org
Subject: Re: refactor the i915 GVT support
On Thu, Jul 22, 2021 at 01:26:36PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu
On Thu, Jul 22, 2021 at 01:26:36PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu/drm/i915/gvt/xengt.c
>
> > But it's hard for some customers to contribute their own "hypervisor"
> > module to the upstream Linux kernel. I am thinking
On Thu, Jul 22, 2021 at 10:49:47AM +, Wang, Zhi A wrote:
> But it's hard for some customers to contribute their own "hypervisor"
> module to the upstream Linux kernel.
What prevents them from doing this? We will take any code that meets
our standards, what format is this external code in?
>
Hi,
> https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu/drm/i915/gvt/xengt.c
> But it's hard for some customers to contribute their own "hypervisor"
> module to the upstream Linux kernel. I am thinking what would be a
> better solution here? The MPT layer in the kernel helps
Hi Christoph:
Thanks so much for the patches and the testing.
The abstraction between i915 and KVMGT module is for our customers who can
easily port GVT-g into their own hypervisors. As you can see, all the
hypervisor related functions were put in "hypervisor" module. The GVT-g module
talks
On 2021.07.21 17:53:34 +0200, Christoph Hellwig wrote:
> Hi all,
>
> the GVT code in the i915 is a bit of a mess right now due to strange
> abstractions and lots of indirect calls. This series refactors various
> bits to clean that up. The main user visible change is that almost all
> of the
45 matches
Mail list logo
