t only takes care of its own request.
>
> On Thu, Sep 19, 2019 at 5:36 AM Guo Ren wrote:
>>
>> From: Guo Ren
>>
>> The patch is for https://github.com/riscv/riscv-isa-manual
>>
>> The proposal has been talked in LPC-2019 RISC-V MC ref [1]. Here is t
t can't support is assigning partitions of a PCI
function (VF or PF) to multiple Virtual Machines" are conflict and I
don't want to play naming game :)
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
___
kvmarm mailing list
kvmarm@lists.c
e to do with that? It's an awful lot of
> > effort to
> > review this sort of stuff and given that Guo Ren is talking about sharing
> > page
> > tables between the CPU and an accelerator, maybe you're better off
> > stabilising Linux for the platforms that you ca
Hi,
On Mon, Sep 16, 2019 at 8:57 PM Jean-Philippe Brucker
wrote:
> On 13/09/2019 09:13, Guo Ren wrote:
> > Another idea is seperate remote TLB invalidate into two instructions:
> >
> > - sfence.vma.b.asyc
> > - sfence.vma.b.barrier // wait all async TLB invalid
Here is the presentation, any comments is welcome.
https://docs.google.com/presentation/d/1sc295JznVAfDIPieAqzjcyUkcHnNFQsK8FFqdoCY854/edit?usp=sharing
On Fri, Sep 13, 2019 at 3:13 PM Guo Ren wrote:
>
> Another idea is seperate remote TLB invalidate into two instru
?)
Actually, I never consider asyc TLB invalidate before, because current our
light iommu did not need it.
Thx all people attend the session :) Let's continue the talk.
Guo Ren 于 2019年9月12日周四 22:59写道：
> Thx Will for reply.
>
> On Thu, Sep 12, 2019 at 3:03 PM Will Deacon wrote:
> >
>
Thx Will for reply.
On Thu, Sep 12, 2019 at 3:03 PM Will Deacon wrote:
>
> On Sun, Sep 08, 2019 at 07:52:55AM +0800, Guo Ren wrote:
> > On Mon, Jun 24, 2019 at 6:40 PM Will Deacon wrote:
> > > > I'll keep my system use the same ASID for SMP + IOMMU :P
> > &g
oin our disscusion:
"Introduce an implementation of IOMMU in linux-riscv"
9 Sep 2019, 10:45 Jade-room-I (Corinthia Hotel Lisbon) RISC-V MC
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
___
kvmarm mailing list
kvmarm
. So this problem has been bypassed
from the design.
I saw arm64 to prevent speculation by temporarily setting TTBR0.el1 to
a zero page table. Is that used to prevent speculative execution user
space code or just prevent ld/st in copy_use_* ?
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Marinas,
Thx for the reply
On Mon, Jun 24, 2019 at 11:38 PM Catalin Marinas
wrote:
>
> On Mon, Jun 24, 2019 at 12:35:35AM +0800, Guo Ren wrote:
> > On Fri, Jun 21, 2019 at 10:16 PM Catalin Marinas
> > wrote:
> > > BTW, if you find the algorithm fairly straightfor
Thx Catalin,
On Fri, Jun 21, 2019 at 10:16 PM Catalin Marinas
wrote:
>
> On Wed, Jun 19, 2019 at 07:51:03PM +0800, Guo Ren wrote:
> > On Wed, Jun 19, 2019 at 4:54 PM Julien Grall wrote:
> > > On 6/19/19 9:07 AM, Guo Ren wrote:
> > > > Move arm asid allocator
On Wed, Jun 19, 2019 at 8:39 PM Will Deacon wrote:
>
> On Wed, Jun 19, 2019 at 08:18:04PM +0800, Guo Ren wrote:
> > On Wed, Jun 19, 2019 at 5:12 PM Will Deacon wrote:
> > > This is one place where I'd actually prefer not to go down the route of
> > > making the c
On Wed, Jun 19, 2019 at 5:12 PM Will Deacon wrote:
>
> On Wed, Jun 19, 2019 at 09:54:21AM +0100, Julien Grall wrote:
> > On 6/19/19 9:07 AM, Guo Ren wrote:
> > > You forgot CCing C-SKY folks :P
> >
> > I wasn't aware you could be interested :).
> >
> >
On Wed, Jun 19, 2019 at 4:54 PM Julien Grall wrote:
>
>
>
> On 6/19/19 9:07 AM, Guo Ren wrote:
> > Hi Julien,
>
> Hi,
>
> >
> > You forgot CCing C-SKY folks :P
>
> I wasn't aware you could be interested :).
>
> >
> > Move arm asid al
it into generic one, I could co-work with you.
Or I'll bring asid code into csky subsystem first and you can cleanup
them later.
Best Regards
Guo Ren
ML: linux-c...@vger.kernel.org
On Thu, Jun 6, 2019 at 12:56 AM Julien Grall wrote:
>
> Hi,
>
> I am CCing RISC-V folks to see if there are an inter
15 matches
Mail list logo
