On Fri, Jun 05, 2020 at 06:03:38PM +0800, Jason Wang wrote:
>
> On 2020/6/5 上午12:49, Michael S. Tsirkin wrote:
> > > > 2. Second argument to translate_desc is a GPA, isn't it?
> > > No, it's IOVA, this function will be called only when IOTLB is enabled.
> > >
> > > Thanks
> > Right IOVA. Point st
On 2020/6/5 上午12:49, Michael S. Tsirkin wrote:
2. Second argument to translate_desc is a GPA, isn't it?
No, it's IOVA, this function will be called only when IOTLB is enabled.
Thanks
Right IOVA. Point stands how does it make sense to cast
a userspace pointer to an IOVA? I guess it's just
bec
On Wed, Jun 03, 2020 at 02:36:46PM +0800, Jason Wang wrote:
>
> On 2020/6/3 下午2:30, Michael S. Tsirkin wrote:
> > On Wed, Jun 03, 2020 at 02:23:08PM +0800, Jason Wang wrote:
> > > > BTW now I re-read it I don't understand __vhost_get_user_slow:
> > > >
> > > >
> > > > static void __user *__vhost
On Thu, Jun 04, 2020 at 04:03:35PM +0100, Al Viro wrote:
> On Thu, Jun 04, 2020 at 06:10:23AM -0400, Michael S. Tsirkin wrote:
>
> > stac()
> > for (i = 0; i < 64; ++i) {
> > get_user(flags, desc[i].flags)
> unsafe_get_user(), please.
> > smp_rmb()
> > if (!(flags & VALID))
On Thu, Jun 04, 2020 at 03:59:24PM +0100, Al Viro wrote:
> On Thu, Jun 04, 2020 at 02:10:27PM +0800, Jason Wang wrote:
>
> > > > get_user(flags, desc->flags)
> > > > smp_rmb()
> > > > if (flags & VALID)
> > > > copy_from_user(&adesc, desc, sizeof adesc);
> > > >
> > > > this would be a good candi
On Thu, Jun 04, 2020 at 06:10:23AM -0400, Michael S. Tsirkin wrote:
> stac()
> for (i = 0; i < 64; ++i) {
>get_user(flags, desc[i].flags)
unsafe_get_user(), please.
>smp_rmb()
>if (!(flags & VALID))
> break;
>copy_from_user(&adesc[i], desc
On Thu, Jun 04, 2020 at 02:10:27PM +0800, Jason Wang wrote:
> > > get_user(flags, desc->flags)
> > > smp_rmb()
> > > if (flags & VALID)
> > > copy_from_user(&adesc, desc, sizeof adesc);
> > >
> > > this would be a good candidate I think.
> > Perhaps, once we get stac/clac out of raw_copy_from_use
On Wed, Jun 03, 2020 at 05:52:05PM +0100, Al Viro wrote:
> On Wed, Jun 03, 2020 at 01:29:00AM -0400, Michael S. Tsirkin wrote:
> > On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
> > > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > > So vhost needs to poke at use
On 2020/6/4 上午12:52, Al Viro wrote:
On Wed, Jun 03, 2020 at 01:29:00AM -0400, Michael S. Tsirkin wrote:
On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
So vhost needs to poke at userspace *a lot* in a quick successi
[ Just a re-send without html and a few fixes for mobile editing,
since that email got eaten by the mailing list Gods ]
On Tue, Jun 2, 2020, 23:02 Michael S. Tsirkin wrote:
>
> Right and we do that, but that still sets the segment according to the
> current thread's flags, right?
But that should
On Wed, Jun 03, 2020 at 01:29:00AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
> > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > > is thus benefitia
From: Al Viro On Behalf Of Al Viro
> Sent: 02 June 2020 22:58
> On Tue, Jun 02, 2020 at 08:41:38PM +, David Laight wrote:
>
> > In which case you need a 'user_access_begin' that takes the mm
> > as an additional parameter.
>
> What does any of that have to do with mm? Details, please.
On 2020/6/3 下午2:30, Michael S. Tsirkin wrote:
On Wed, Jun 03, 2020 at 02:23:08PM +0800, Jason Wang wrote:
BTW now I re-read it I don't understand __vhost_get_user_slow:
static void __user *__vhost_get_user_slow(struct vhost_virtqueue *vq,
void __us
On Wed, Jun 03, 2020 at 02:23:08PM +0800, Jason Wang wrote:
> >
> > BTW now I re-read it I don't understand __vhost_get_user_slow:
> >
> >
> > static void __user *__vhost_get_user_slow(struct vhost_virtqueue *vq,
> >void __user *addr, unsigned int
> >
On Wed, Jun 03, 2020 at 05:18:49AM +0100, Al Viro wrote:
> On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
>
> > > How widely do you hope to stretch the user_access areas, anyway?
> >
> >
> > To have best performance for small packets like 64B, if possible, we want to
> > disable STA
On 2020/6/3 下午1:46, Michael S. Tsirkin wrote:
On Wed, Jun 03, 2020 at 01:18:54PM +0800, Jason Wang wrote:
On 2020/6/3 下午12:18, Al Viro wrote:
On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
How widely do you hope to stretch the user_access areas, anyway?
To have best performanc
On Tue, Jun 02, 2020 at 01:43:20PM -0700, Linus Torvalds wrote:
> On Tue, Jun 2, 2020 at 1:33 PM Michael S. Tsirkin wrote:
> >
> > Hmm are you sure we can drop it? access_ok is done in the context
> > of the process. Access itself in the context of a kernel thread
> > that borrows the same mm. IIU
On Wed, Jun 03, 2020 at 01:18:54PM +0800, Jason Wang wrote:
>
> On 2020/6/3 下午12:18, Al Viro wrote:
> > On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
> >
> > > > How widely do you hope to stretch the user_access areas, anyway?
> > >
> > > To have best performance for small packets
On Wed, Jun 03, 2020 at 02:48:15AM +0100, Al Viro wrote:
> On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > is thus benefitial to enable userspace access, do our thing, then
> > disable. Except access_
On 2020/6/3 下午12:18, Al Viro wrote:
On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
How widely do you hope to stretch the user_access areas, anyway?
To have best performance for small packets like 64B, if possible, we want to
disable STAC not only for the metadata access done by
On Tue, Jun 02, 2020 at 11:10:57PM +0100, Al Viro wrote:
> On Tue, Jun 02, 2020 at 04:42:03PM -0400, Michael S. Tsirkin wrote:
> > On Tue, Jun 02, 2020 at 05:30:48PM +0100, Al Viro wrote:
> > > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > > So vhost needs to poke at use
On Wed, Jun 03, 2020 at 11:57:11AM +0800, Jason Wang wrote:
> > How widely do you hope to stretch the user_access areas, anyway?
>
>
> To have best performance for small packets like 64B, if possible, we want to
> disable STAC not only for the metadata access done by vhost accessors but
> also t
On 2020/6/3 上午9:48, Al Viro wrote:
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
So vhost needs to poke at userspace *a lot* in a quick succession. It
is thus benefitial to enable userspace access, do our thing, then
disable. Except access_ok has already been pre-validat
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> So vhost needs to poke at userspace *a lot* in a quick succession. It
> is thus benefitial to enable userspace access, do our thing, then
> disable. Except access_ok has already been pre-validated with all the
> relevant nospec
On Tue, Jun 02, 2020 at 04:42:03PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jun 02, 2020 at 05:30:48PM +0100, Al Viro wrote:
> > On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > > is thus benefitia
On Tue, Jun 02, 2020 at 08:41:38PM +, David Laight wrote:
> In which case you need a 'user_access_begin' that takes the mm
> as an additional parameter.
What does any of that have to do with mm? Details, please.
On Tue, Jun 2, 2020 at 1:33 PM Michael S. Tsirkin wrote:
>
> Hmm are you sure we can drop it? access_ok is done in the context
> of the process. Access itself in the context of a kernel thread
> that borrows the same mm. IIUC if the process can be 32 bit
> while the kernel is 64 bit, access_ok in
On Tue, Jun 02, 2020 at 05:30:48PM +0100, Al Viro wrote:
> On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > is thus benefitial to enable userspace access, do our thing, then
> > disable. Except access_
From: Michael S. Tsirkin
> Sent: 02 June 2020 21:33
> On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote:
> > On Tue, Jun 2, 2020 at 9:33 AM Al Viro wrote:
> > >
> > > >
> > > > It's not clear whether we need a new API, I think __uaccess_being() has
> > > > the
> > > > assumption that
On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote:
> On Tue, Jun 2, 2020 at 9:33 AM Al Viro wrote:
> >
> > >
> > > It's not clear whether we need a new API, I think __uaccess_being() has
> > > the
> > > assumption that the address has been validated by access_ok().
> >
> > __uaccess_
On Tue, Jun 02, 2020 at 06:44:30PM +0100, Al Viro wrote:
> On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote:
>
>
> > You have exactly two cases:
> >
> > (a) the access_ok() would be right above the code and can't be missed
> >
> > (b) not
>
>(c) what you really want is not
On Tue, Jun 02, 2020 at 10:18:09AM -0700, Linus Torvalds wrote:
> You have exactly two cases:
>
> (a) the access_ok() would be right above the code and can't be missed
>
> (b) not
(c) what you really want is not quite access_ok().
Again, that "not quite access_ok()" should be right next
On Tue, Jun 2, 2020 at 9:33 AM Al Viro wrote:
>
> >
> > It's not clear whether we need a new API, I think __uaccess_being() has the
> > assumption that the address has been validated by access_ok().
>
> __uaccess_begin() is a stopgap, not a public API.
Correct. It's just an x86 implementation det
On Tue, Jun 02, 2020 at 06:15:57PM +0800, Jason Wang wrote:
>
> On 2020/6/2 下午4:45, Michael S. Tsirkin wrote:
> > So vhost needs to poke at userspace *a lot* in a quick succession. It
> > is thus benefitial to enable userspace access, do our thing, then
> > disable. Except access_ok has already b
On Tue, Jun 02, 2020 at 04:45:05AM -0400, Michael S. Tsirkin wrote:
> So vhost needs to poke at userspace *a lot* in a quick succession. It
> is thus benefitial to enable userspace access, do our thing, then
> disable. Except access_ok has already been pre-validated with all the
> relevant nospec
On 2020/6/2 下午4:45, Michael S. Tsirkin wrote:
So vhost needs to poke at userspace *a lot* in a quick succession. It
is thus benefitial to enable userspace access, do our thing, then
disable. Except access_ok has already been pre-validated with all the
relevant nospec checks, so we don't need t
So vhost needs to poke at userspace *a lot* in a quick succession. It
is thus benefitial to enable userspace access, do our thing, then
disable. Except access_ok has already been pre-validated with all the
relevant nospec checks, so we don't need that. Add an API to allow
userspace access after a
37 matches
Mail list logo
