On Mon, May 17, 2021 at 05:55:12PM +0800, Xie Yongji wrote:
> + case VDUSE_IOTLB_GET_FD: {
> + struct vduse_iotlb_entry entry;
> + struct vhost_iotlb_map *map;
> + struct vdpa_map_file *map_file;
> + struct vduse_iova_domain *domain = dev->domain
On Mon, May 17, 2021 at 05:55:03PM +0800, Xie Yongji wrote:
> Export receive_fd() so that some modules can use
> it to pass file descriptor between processes without
> missing any security stuffs.
Which tree is that against? Because in mainline this won't even build, let
alone work.
> --- a/fs/f
On Mon, May 17, 2021 at 05:55:01PM +0800, Xie Yongji wrote:
> This series introduces a framework, which can be used to implement
> vDPA Devices in a userspace program. The work consist of two parts:
> control path forwarding and data path offloading.
>
> In the control path, the VDUSE driver will
On Thu, May 20, 2021 at 01:25:16PM +0800, Yongji Xie wrote:
> On Wed, May 19, 2021 at 10:42 PM Dan Carpenter
> wrote:
> >
> > On Wed, May 19, 2021 at 09:39:20PM +0800, Yongji Xie wrote:
> > > On Mon, May 17, 2021 at 5:56 PM Xie Yongji
> > > wrote:
> > > >
> > > > This ensures that we will not u
On Wed, May 19, 2021 at 09:13:08PM +0200, Joerg Roedel wrote:
> Hi Peter,
>
> thanks for your review.
>
> On Wed, May 19, 2021 at 07:54:50PM +0200, Peter Zijlstra wrote:
> > On Wed, May 19, 2021 at 03:52:48PM +0200, Joerg Roedel wrote:
> > > --- a/arch/x86/kernel/sev.c
> > > +++ b/arch/x86/kernel
Hi Peter,
thanks for your review.
On Wed, May 19, 2021 at 07:54:50PM +0200, Peter Zijlstra wrote:
> On Wed, May 19, 2021 at 03:52:48PM +0200, Joerg Roedel wrote:
> > --- a/arch/x86/kernel/sev.c
> > +++ b/arch/x86/kernel/sev.c
> > @@ -1343,9 +1343,10 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_commun
On Wed, May 19, 2021 at 03:52:48PM +0200, Joerg Roedel wrote:
> --- a/arch/x86/kernel/sev.c
> +++ b/arch/x86/kernel/sev.c
> @@ -1343,9 +1343,10 @@ DEFINE_IDTENTRY_VC_SAFE_STACK(exc_vmm_communication)
> return;
> }
>
> + instrumentation_begin();
> +
> irq_state = irqe
On Wed, May 19, 2021 at 09:39:20PM +0800, Yongji Xie wrote:
> On Mon, May 17, 2021 at 5:56 PM Xie Yongji wrote:
> >
> > This ensures that we will not use an invalid block size
> > in config space (might come from an untrusted device).
I looked at if I should add this as an untrusted function so t
On 5/18/21 1:00 AM, Stephen Hemminger wrote:
>
> The Azure network driver (netvsc) also does not have BQL. Several years ago
> I tried adding it but it benchmarked worse and there is the added complexity
> of handling the accelerated networking VF path.
>
Note that NIC with many TX queues m
Fix to return negative error code -ENOMEM from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 11d8ffed00b2 ("vp_vdpa: switch to use vp_modern_map_vq_notify()")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
---
drivers/vdpa/virtio_pci/vp_vdpa.c | 1 +
1 fil
From: Joerg Roedel
The error reporting from the insn_fetch_from_user*() functions is not
very verbose. Extend it to include information on whether the linear
RIP could not be calculated or whether the memory access faulted.
This will be used in the SEV-ES code to propagate the correct
exception
From: Joerg Roedel
The error path in the runtime #VC handler sends a signal to kill the
current task if the exception was raised from user-space. Some parts of
the #VC handler run in NMI mode, because it is critical that it is not
interrupted (except from an NMI) while the GHCB is in use.
But se
From: Joerg Roedel
The sev_es_get_ghcb() is called from several places, but only one of
them checks the return value. The reaction to returning NULL is always
the same: Calling panic() and kill the machine.
Instead of adding checks to all call-places, move the panic() into the
function itself so
From: Joerg Roedel
When emulating guest instructions for MMIO or IOIO accesses the #VC
handler might get a page-fault and will not be able to complete. Forward
the page-fault in this case to the correct handler instead of killing
the machine.
Fixes: 0786138c78e7 ("x86/sev-es: Add a Runtime #VC E
From: Joerg Roedel
In theory 0 is a valid value for the instruction pointer, so don't use
it as the error return value from insn_get_effective_ip().
Signed-off-by: Joerg Roedel
---
arch/x86/lib/insn-eval.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/
From: Joerg Roedel
When an instruction is fetched from user-space, segmentation needs to
be taken into account. This means that getting the linear address of
an instruction can fail. Hardware would raise a #GP
exception in that case, but the #VC exception handler would emulate it
as a page-fault.
From: Joerg Roedel
The put_user() and get_user() functions do checks on the address which is
passed to them. They check whether the address is actually a user-space
address and whether its fine to access it. They also call might_fault()
to indicate that they could fault and possibly sleep.
All o
From: Joerg Roedel
The runtime #VC handler is not "early" anymore. Fix the copy&paste error
and remove that word from the error message.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/sev.c b/arch/x86/ke
From: Joerg Roedel
Hi,
here is the second version of my pending SEV-ES fixes. The most
important patches are patch 1 to 5, as they fix warnings and splats
that trigger with various debugging options are enabled.
Patches 6 to 8 fix a correctness issue in the instruction emulation
part of the #VC
On Wed, 19 May 2021 08:44:01 -0400, Michael S. Tsirkin wrote:
> On Wed, May 19, 2021 at 07:47:57PM +0800, Xuan Zhuo wrote:
> > Unlike virtqueue_kick(), virtqueue_kick_try() returns true only when the
> > kick is successful. In virtio-net, we want to count the number of kicks.
> > So we need an int
Hi Sean,
On Wed, May 12, 2021 at 05:31:03PM +, Sean Christopherson wrote:
> This got me looking at the flows that "inject" #PF, and I'm pretty sure there
> are bugs in __vc_decode_user_insn() + insn_get_effective_ip().
>
> Problem #1: __vc_decode_user_insn() assumes a #PF if
> insn_fetch_fro
On Wed, May 19, 2021 at 07:47:57PM +0800, Xuan Zhuo wrote:
> Unlike virtqueue_kick(), virtqueue_kick_try() returns true only when the
> kick is successful. In virtio-net, we want to count the number of kicks.
> So we need an interface that can perceive whether the kick is actually
> executed.
>
>
On Wed, May 12, 2021 at 05:38:29PM +, Sean Christopherson wrote:
> Alternatively, and probably even better, fold this revert into the switch to
> the unchecked version (sounds like those will use kernel-specific flavors?).
I folded this revert into the previous commit. But I kept the
__get_use
Unlike virtqueue_kick(), virtqueue_kick_try() returns true only when the
kick is successful. In virtio-net, we want to count the number of kicks.
So we need an interface that can perceive whether the kick is actually
executed.
Signed-off-by: Xuan Zhuo
---
drivers/net/virtio_net.c | 8 --
On Wed, May 12, 2021 at 11:32:35AM +0200, Joerg Roedel wrote:
> On Wed, May 12, 2021 at 10:58:20AM +0200, Juergen Gross wrote:
> > No, those were used before, but commit 9da3f2b7405440 broke Xen's use
> > case. That is why I did commit 1457d8cf7664f.
>
> [...]
>
> Having the distinction between use
On Mon, May 17, 2021 at 11:43:43AM -0700, Dave Taht wrote:
> Not really related to this patch, but is there some reason why virtio
> has no support for BQL?
So just so you can try it out, I rebased my old patch.
XDP is handled incorrectly by it so we shouldn't apply it as is,
but should be good en
26 matches
Mail list logo
