On 05-07-21, 14:21, Jie Deng wrote:
>
> On 2021/7/5 10:43, Viresh Kumar wrote:
> > On 02-07-21, 12:58, Andy Shevchenko wrote:
> > > On Fri, Jul 02, 2021 at 04:46:47PM +0800, Jie Deng wrote:
> > > > +static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> > > > +
From: Joerg Roedel
Check whether the hypervisor supports GHCB version 2 and use it if
available.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev.c | 10 --
arch/x86/include/asm/sev.h | 4 ++--
arch/x86/kernel/sev-shared.c | 17 ++---
3 files changed, 24
From: Joerg Roedel
Move the code for MMIO handling in the #VC handler to sev-shared.c so
that it can be used in the decompressor code. The decompressor needs
to handle MMIO events for writing to the VGA framebuffer.
When the kernel is booted via UEFI the VGA console is not enabled that
early,
From: Joerg Roedel
The AP Jump Table under SEV-ES contains the reset vector where non-boot
CPUs start executing when coming out of reset. This means that a CPU
coming out of the AP-reset-hold VMGEXIT also needs to start executing at
the reset vector stored in the AP Jump Table.
The problem is
From: Joerg Roedel
Handle CLFLUSH instruction to MMIO memory in the #VC handler. The
instruction is ignored by the handler, as the Hypervisor is
responsible for cache management of emulated MMIO memory.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev-shared.c | 9 +
1 file
From: Joerg Roedel
GHCB protocol version 2 adds the MSR-based AP-reset-hold VMGEXIT which
does not need a GHCB. Use that to park APs in 16-bit protected mode on
the AP Jump Table.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/realmode.h| 3 +
arch/x86/kernel/sev.c |
From: Joerg Roedel
Introduce the sev_get_ghcb_proto_ver() which will return the negotiated
GHCB protocol version and use it to set the version field in the GHCB.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev.c | 5 +
arch/x86/kernel/sev-shared.c | 5 -
From: Joerg Roedel
Store the physical address of the AP Jump Table in kernel memory so
that it does not need to be fetched from the Hypervisor again.
Signed-off-by: Joerg Roedel
---
arch/x86/kernel/sev.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff
From: Joerg Roedel
Hi,
here are changes to enable kexec/kdump in SEV-ES guests. The biggest
problem for supporting kexec/kdump under SEV-ES is to find a way to
hand the non-boot CPUs (APs) from one kernel to another.
Without SEV-ES the first kernel parks the CPUs in a HLT loop until
they get
From: Joerg Roedel
When the AP Jump Table blob is installed the kernel can hand over the
APs from the old to the new kernel. Enable kexec when the AP Jump
Table blob has been installed.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/sev.h | 2 ++
From: Joerg Roedel
For now, kexec is not supported when running as an SEV-ES guest. Doing
so requires additional hypervisor support and special code to hand
over the CPUs to the new kernel in a safe way.
Until this is implemented, do not support kexec in SEV-ES guests.
Cc:
From: Joerg Roedel
To support kexec under SEV-ES the APs can't be parked with HLT. Upon
wakeup the AP needs to find its way to execute at the reset vector set
by the new kernel and in real-mode.
This is what the AP Jump Table blob provides, so stop the APs the
SEV-ES way by calling the
From: Joerg Roedel
Save the results of the GHCB protocol negotiation into a data structure
and print information about versions supported and used to the kernel
log.
Signed-off-by: Joerg Roedel
---
arch/x86/boot/compressed/sev.c | 2 +-
arch/x86/kernel/sev-shared.c | 22
From: Joerg Roedel
Allow a runtime opt-out of kexec support for architecture code in case
the kernel is running in an environment where kexec is not properly
supported yet.
This will be used on x86 when the kernel is running as an SEV-ES
guest. SEV-ES guests need special handling for kexec to
On 05-07-21, 14:22, Jie Deng wrote:
> On 2021/7/5 12:38, Viresh Kumar wrote:
> > On 05-07-21, 11:45, Jie Deng wrote:
> > > On 2021/7/5 10:40, Viresh Kumar wrote:
> > > > On 02-07-21, 16:46, Jie Deng wrote:
> > > > The right way of doing this is is making this function return - Error
> > > > on
On 05-07-21, 12:38, Andy Shevchenko wrote:
> Because we do not have "uapi" in the path in /usr/include on the real
> system where the linux-headers (or kernel-headers) package is
> installed.
>
> It's still possible that our installation hooks will remove that
> "uapi" from the headers, but I
On 2021/7/5 12:38, Viresh Kumar wrote:
On 05-07-21, 11:45, Jie Deng wrote:
On 2021/7/5 10:40, Viresh Kumar wrote:
On 02-07-21, 16:46, Jie Deng wrote:
The right way of doing this is is making this function return - Error on failure
and 0 on success. There is no point returning number of
On 2021/7/5 14:30, Viresh Kumar wrote:
This is still not enough to convince me. So I won't change them for now
until I see it
is the consensus of the majority.
Do you see reqs[i] to ever be NULL here ? If not, then if (req) is like if
(true).
Why would you want to have something like that
Virtio spec allows the device to specify the per virtqueue max queue
size. vDPA needs to adapt to this flexibility. E.g Qemu advertise a
small control virtqueue for virtio-net.
So this patch adds a index parameter to get_vq_num_max bus operations
for the device to report its per virtqueue max
This patch switch to read virtqueue size from the capability instead
of depending on the hardcoded value. This allows the per virtqueue
size could be advertised.
Signed-off-by: Jason Wang
---
drivers/vdpa/virtio_pci/vp_vdpa.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff
在 2021/7/5 下午3:26, Michael S. Tsirkin 写道:
On Mon, Jul 05, 2021 at 03:19:10PM +0800, Jason Wang wrote:
This patch switch to read virtqueue size from the capability instead
of depending on the hardcoded value. This allows the per virtqueue
size could be advertised.
Signed-off-by: Jason Wang
On Mon, Jul 5, 2021 at 11:56 AM Viresh Kumar wrote:
> On 05-07-21, 11:45, Andy Shevchenko wrote:
> > On Mon, Jul 5, 2021 at 11:03 AM Viresh Kumar
> > wrote:
> > > On 05-07-21, 14:53, Jie Deng wrote:
> >
> > > > +#include
> > > > +#include
> > >
> > > Both of these need to be the uapi headers
On Mon, Jul 05, 2021 at 11:57:33AM +0800, Yunsheng Lin wrote:
> tools/include/* have a lot of abstract layer for building
> kernel code from userspace, so reuse or add the abstract
> layer in tools/include/ to build the ptr_ring for ringtest
> testing.
...
> create mode 100644
On Mon, Jul 05, 2021 at 03:19:10PM +0800, Jason Wang wrote:
> This patch switch to read virtqueue size from the capability instead
> of depending on the hardcoded value. This allows the per virtqueue
> size could be advertised.
>
> Signed-off-by: Jason Wang
So let's add an ioctl for this? It's
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg8.html.
By
Hi Jie.
On 05-07-21, 14:53, Jie Deng wrote:
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> +static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> + struct virtio_i2c_req *reqs,
> + struct
On Mon, Jul 5, 2021 at 11:03 AM Viresh Kumar wrote:
> On 05-07-21, 14:53, Jie Deng wrote:
> > +#include
> > +#include
>
> Both of these need to be the uapi headers as Andy said earlier
They are already since this header _is_ UAPI, what you are suggesting
is gonna not work, although it's
On 2021/7/5 10:43, Viresh Kumar wrote:
On 02-07-21, 12:58, Andy Shevchenko wrote:
On Fri, Jul 02, 2021 at 04:46:47PM +0800, Jie Deng wrote:
+static int virtio_i2c_complete_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+
On Mon, Jul 05, 2021 at 01:04:11PM +0800, Jason Wang wrote:
> > +static int ifcvf_probe(struct pci_dev *pdev, const struct pci_device_id
> > *id)
> > +{
> > + struct ifcvf_vdpa_mgmt_dev *ifcvf_mgmt_dev;
> > + struct device *dev = >dev;
> > + struct ifcvf_adapter *adapter;
>
>
> adapter is
On 05-07-21, 11:45, Andy Shevchenko wrote:
> On Mon, Jul 5, 2021 at 11:03 AM Viresh Kumar wrote:
> > On 05-07-21, 14:53, Jie Deng wrote:
>
> > > +#include
> > > +#include
> >
> > Both of these need to be the uapi headers as Andy said earlier
>
> They are already since this header _is_ UAPI,
On Thu, Jul 01, 2021 at 01:46:52PM +0200, Vincent Whitchurch wrote:
Do not call vDPA drivers' callbacks with vq indicies larger than what
the drivers indicate that they support. vDPA drivers do not bounds
check the indices.
Signed-off-by: Vincent Whitchurch
---
drivers/virtio/virtio_vdpa.c |
On 29-06-21, 12:43, Wolfram Sang wrote:
>
> > From the spec:
> >
> > The case when ``length of \field{write_buf}''=0, and at the same time,
> > ``length of \field{read_buf}''=0 doesn't make any sense.
> >
> > I mentioned this in my first reply and to my understanding I did not get
> > a reply
On Mon, Jul 05, 2021 at 08:06:50PM +0800, Yunsheng Lin wrote:
> On 2021/7/5 17:56, Andy Shevchenko wrote:
> > On Mon, Jul 05, 2021 at 11:57:33AM +0800, Yunsheng Lin wrote:
> >> tools/include/* have a lot of abstract layer for building
> >> kernel code from userspace, so reuse or add the abstract
>
On Mon, Jul 05, 2021 at 11:36:15AM +0800, Jason Wang wrote:
>
> 在 2021/7/4 下午5:49, Yongji Xie 写道:
> > > > OK, I get you now. Since the VIRTIO specification says "Device
> > > > configuration space is generally used for rarely-changing or
> > > > initialization-time parameters". I assume the
On Mon, Jul 05, 2021 at 01:48:28PM +0300, Arseny Krasnov wrote:
On 04.07.2021 12:54, Michael S. Tsirkin wrote:
On Sun, Jul 04, 2021 at 12:23:03PM +0300, Arseny Krasnov wrote:
On 04.07.2021 11:30, Michael S. Tsirkin wrote:
On Sun, Jul 04, 2021 at 11:08:13AM +0300, Arseny Krasnov wrote:
在 2021/7/6 上午1:59, Michael S. Tsirkin 写道:
On Mon, Jul 05, 2021 at 03:29:47PM +0800, Jason Wang wrote:
在 2021/7/5 下午3:26, Michael S. Tsirkin 写道:
On Mon, Jul 05, 2021 at 03:19:10PM +0800, Jason Wang wrote:
This patch switch to read virtqueue size from the capability instead
of depending on the
On 2021/7/5 20:18, Viresh Kumar wrote:
On 29-06-21, 12:43, Wolfram Sang wrote:
From the spec:
The case when ``length of \field{write_buf}''=0, and at the same time,
``length of \field{read_buf}''=0 doesn't make any sense.
I mentioned this in my first reply and to my understanding I did not
在 2021/7/5 下午8:49, Stefan Hajnoczi 写道:
On Mon, Jul 05, 2021 at 11:36:15AM +0800, Jason Wang wrote:
在 2021/7/4 下午5:49, Yongji Xie 写道:
OK, I get you now. Since the VIRTIO specification says "Device
configuration space is generally used for rarely-changing or
initialization-time parameters". I
On Mon, Jul 05, 2021 at 02:26:32PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 05, 2021 at 08:06:50PM +0800, Yunsheng Lin wrote:
> > On 2021/7/5 17:56, Andy Shevchenko wrote:
> > > On Mon, Jul 05, 2021 at 11:57:33AM +0800, Yunsheng Lin wrote:
> > >> tools/include/* have a lot of abstract layer
On Mon, Jul 05, 2021 at 10:05:30PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 5, 2021 at 9:45 PM Michael S. Tsirkin wrote:
> >
> > On Mon, Jul 05, 2021 at 09:36:26PM +0300, Andy Shevchenko wrote:
> > > On Mon, Jul 05, 2021 at 02:26:32PM -0400, Michael S. Tsirkin wrote:
> > > > On Mon, Jul 05,
On Tue, Jun 22, 2021 at 11:11:06AM +0100, Stefan Hajnoczi wrote:
> On Thu, Jun 17, 2021 at 01:10:04PM +0800, Xie Yongji wrote:
> > This ensures that we will not use an invalid block size
> > in config space (might come from an untrusted device).
> >
> > Signed-off-by: Xie Yongji
> > ---
> >
On Mon, Jul 5, 2021 at 9:45 PM Michael S. Tsirkin wrote:
>
> On Mon, Jul 05, 2021 at 09:36:26PM +0300, Andy Shevchenko wrote:
> > On Mon, Jul 05, 2021 at 02:26:32PM -0400, Michael S. Tsirkin wrote:
> > > On Mon, Jul 05, 2021 at 08:06:50PM +0800, Yunsheng Lin wrote:
> > > > On 2021/7/5 17:56, Andy
On Mon, Jul 05, 2021 at 03:29:47PM +0800, Jason Wang wrote:
>
> 在 2021/7/5 下午3:26, Michael S. Tsirkin 写道:
> > On Mon, Jul 05, 2021 at 03:19:10PM +0800, Jason Wang wrote:
> > > This patch switch to read virtqueue size from the capability instead
> > > of depending on the hardcoded value. This
On Mon, Jul 05, 2021 at 08:06:50PM +0800, Yunsheng Lin wrote:
> On 2021/7/5 17:56, Andy Shevchenko wrote:
> > On Mon, Jul 05, 2021 at 11:57:33AM +0800, Yunsheng Lin wrote:
> >> tools/include/* have a lot of abstract layer for building
> >> kernel code from userspace, so reuse or add the abstract
>
On Mon, Jul 05, 2021 at 06:00:06PM +0800, Xie Yongji wrote:
> This ensures that we will not use an invalid block size
> in config space (might come from an untrusted device).
>
> Signed-off-by: Xie Yongji
I replied on v3.
Silently ignoring what hypervisor said is not a good idea.
> ---
>
On Mon, Jul 05, 2021 at 09:36:26PM +0300, Andy Shevchenko wrote:
> On Mon, Jul 05, 2021 at 02:26:32PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 05, 2021 at 08:06:50PM +0800, Yunsheng Lin wrote:
> > > On 2021/7/5 17:56, Andy Shevchenko wrote:
> > > > On Mon, Jul 05, 2021 at 11:57:33AM +0800,
On Mon, Jul 05, 2021 at 10:13:33PM +0800, Zhu Lingshan wrote:
> This commit implments the management netlink framework for ifcvf,
implements
> including register and add / remove a device
>
> It works with iprouter2:
I am guessing iproute2?
> [root@localhost lszhu]# vdpa mgmtdev show -jp
> {
On Mon, Jul 05, 2021 at 11:57:34AM +0800, Yunsheng Lin wrote:
> In order to build ptr_ring.h in userspace, the cacheline
> aligning, cpu_relax() and slab related infrastructure is
> needed, so add them in this patch.
>
> As L1_CACHE_BYTES may be different for different arch, which
> is mostly
On Fri, Jul 02, 2021 at 11:05:54PM +0800, Ming Lei wrote:
> blk-mq needs to know if the device uses managed irq, so add one field
> to virtio_device for recording if device uses managed irq.
>
> If the driver use managed irq, this flag has to be set so it can be
> passed to blk-mq.
I don't think
49 matches
Mail list logo
