On Mon, Jun 24, 2019 at 01:22:55AM -0400, Yan Zhao wrote:
> On Thu, Jun 20, 2019 at 09:04:43PM +0800, Peter Xu wrote:
> > On Thu, Jun 20, 2019 at 08:59:55PM +0800, Peter Xu wrote:
> > > On Thu, Jun 20, 2019 at 10:35:29AM +0200, Paolo Bonzini wrote:
> > > > On 20/06/19 06:02, Peter Xu wrote:
> > > >
On Thu, Jun 20, 2019 at 09:04:43PM +0800, Peter Xu wrote:
> On Thu, Jun 20, 2019 at 08:59:55PM +0800, Peter Xu wrote:
> > On Thu, Jun 20, 2019 at 10:35:29AM +0200, Paolo Bonzini wrote:
> > > On 20/06/19 06:02, Peter Xu wrote:
> > > > Seems workable, to be explicit - we can even cut it into chunks w
On Thu, Jun 20, 2019 at 08:59:55PM +0800, Peter Xu wrote:
> On Thu, Jun 20, 2019 at 10:35:29AM +0200, Paolo Bonzini wrote:
> > On 20/06/19 06:02, Peter Xu wrote:
> > > Seems workable, to be explicit - we can even cut it into chunks with
> > > different size to be efficient.
> >
> > Yes, this is no
On Thu, Jun 20, 2019 at 03:14:04PM +0200, Paolo Bonzini wrote:
> On 20/06/19 14:59, Peter Xu wrote:
> > I feel like this can be problematic. I'm imaging:
> >
> > start=0x1000_, size=0x1000_1000
> >
> > This will get size=0x1000 but actually we can do size=0x1000_ as
> > the first.
>
> R
On Thu, Jun 20, 2019 at 08:59:55PM +0800, Peter Xu wrote:
> On Thu, Jun 20, 2019 at 10:35:29AM +0200, Paolo Bonzini wrote:
> > On 20/06/19 06:02, Peter Xu wrote:
> > > Seems workable, to be explicit - we can even cut it into chunks with
> > > different size to be efficient.
> >
> > Yes, this is no
On 20/06/19 14:59, Peter Xu wrote:
> I feel like this can be problematic. I'm imaging:
>
> start=0x1000_, size=0x1000_1000
>
> This will get size=0x1000 but actually we can do size=0x1000_ as
> the first.
Right, we can do:
/*
* If a naturally aligned region starting at "start" ends be
On Thu, Jun 20, 2019 at 10:35:29AM +0200, Paolo Bonzini wrote:
> On 20/06/19 06:02, Peter Xu wrote:
> > Seems workable, to be explicit - we can even cut it into chunks with
> > different size to be efficient.
>
> Yes, this is not hard (completely untested):
>
> diff --git a/hw/i386/intel_iommu.c
On 20/06/19 12:57, Yan Zhao wrote:
> On Thu, Jun 20, 2019 at 04:35:29PM +0800, Paolo Bonzini wrote:
>> On 20/06/19 06:02, Peter Xu wrote:
>>> Seems workable, to be explicit - we can even cut it into chunks with
>>> different size to be efficient.
>>
>> Yes, this is not hard (completely untested):
>
On Thu, Jun 20, 2019 at 04:35:29PM +0800, Paolo Bonzini wrote:
> On 20/06/19 06:02, Peter Xu wrote:
> > Seems workable, to be explicit - we can even cut it into chunks with
> > different size to be efficient.
>
> Yes, this is not hard (completely untested):
>
> diff --git a/hw/i386/intel_iommu.c
On 20/06/19 06:02, Peter Xu wrote:
> Seems workable, to be explicit - we can even cut it into chunks with
> different size to be efficient.
Yes, this is not hard (completely untested):
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 44b1231157..541538bc6c 100644
--- a/hw/i386/int
On Thu, Jun 20, 2019 at 04:14:37PM +0800, Peter Xu wrote:
> On Thu, Jun 20, 2019 at 12:14:00AM -0400, Yan Zhao wrote:
> > On Thu, Jun 20, 2019 at 12:02:30PM +0800, Peter Xu wrote:
> > > On Wed, Jun 19, 2019 at 03:17:41PM +0200, Auger Eric wrote:
> > > > Hi Yan,
> > > >
> > > > [+ Peter]
> > > >
>
On Thu, Jun 20, 2019 at 12:14:00AM -0400, Yan Zhao wrote:
> On Thu, Jun 20, 2019 at 12:02:30PM +0800, Peter Xu wrote:
> > On Wed, Jun 19, 2019 at 03:17:41PM +0200, Auger Eric wrote:
> > > Hi Yan,
> > >
> > > [+ Peter]
> > >
> > > On 6/19/19 10:49 AM, Yan Zhao wrote:
> > > > even if an entry overl
On Thu, Jun 20, 2019 at 12:02:30PM +0800, Peter Xu wrote:
> On Wed, Jun 19, 2019 at 03:17:41PM +0200, Auger Eric wrote:
> > Hi Yan,
> >
> > [+ Peter]
> >
> > On 6/19/19 10:49 AM, Yan Zhao wrote:
> > > even if an entry overlaps with notifier's range, should not map/unmap
> > > out of bound part in
On Wed, Jun 19, 2019 at 03:17:41PM +0200, Auger Eric wrote:
> Hi Yan,
>
> [+ Peter]
>
> On 6/19/19 10:49 AM, Yan Zhao wrote:
> > even if an entry overlaps with notifier's range, should not map/unmap
> > out of bound part in the entry.
>
> I don't think the patch was based on the master as the tr
hi Eric,
Thanks for your reply.
On Wed, Jun 19, 2019 at 09:17:41PM +0800, Auger Eric wrote:
> Hi Yan,
>
> [+ Peter]
>
> On 6/19/19 10:49 AM, Yan Zhao wrote:
> > even if an entry overlaps with notifier's range, should not map/unmap
> > out of bound part in the entry.
>
> I don't think the patch
Hi Yan,
[+ Peter]
On 6/19/19 10:49 AM, Yan Zhao wrote:
> even if an entry overlaps with notifier's range, should not map/unmap
> out of bound part in the entry.
I don't think the patch was based on the master as the trace at the very
end if not part of the upstream code.
>
> This would cause pr
even if an entry overlaps with notifier's range, should not map/unmap
out of bound part in the entry.
This would cause problem in below case:
1. initially there are two notifiers with ranges
0-0xfedf, 0xfef0-0x,
IOVAs from 0x3c00 - 0x3c1f is in shadow page table.
2
17 matches
Mail list logo