similar to: [vhost:vhost 38/45] include/linux/vdpa.h:43:21: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 84d40e4b4bc64456abf5ef5663871053b40e84ac commit: 03750f7fa49f9384911059fe16f5367b7e86f99d [40/45] virtio_vdpa: legacy features handling config: nds32-randconfig-r003-20200728 (attached as .config) compiler: nds32le-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget

Some legacy guests just assume features are 0 after reset. We detect that config space is accessed before features are set and set features to 0 automatically. Note: some legacy guests might not even access config space, if this is reported in the field we might need to catch a kick to handle these. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vdpa/vdpa.c | 1 +

Some legacy guests just assume features are 0 after reset. We detect that config space is accessed before features are set and set features to 0 automatically. Note: some legacy guests might not even access config space, if this is reported in the field we might need to catch a kick to handle these. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vdpa/vdpa.c | 1 +

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > Some legacy guests just assume features are 0 after reset. > We detect that config space is accessed before features are > set and set features to 0 automatically. > Note: some legacy guests might not even access config space, if this is > reported in the field we might need to catch a kick to handle these. I wonder whether it's

On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > Some legacy guests just assume features are 0 after reset. > We detect that config space is accessed before features are > set and set features to 0 automatically. > Note: some legacy guests might not even access config space, if this is > reported in the field we might need to catch a kick to handle these. I wonder whether it's

On Wed, Aug 05, 2020 at 02:14:07PM +0800, Jason Wang wrote: > > On 2020/8/4 ??5:00, Michael S. Tsirkin wrote: > > Some legacy guests just assume features are 0 after reset. > > We detect that config space is accessed before features are > > set and set features to 0 automatically. > > Note: some legacy guests might not even access config space, if this is > >

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 84d40e4b4bc64456abf5ef5663871053b40e84ac commit: fee8fe6bd8ccacd27e963b71b4f943be3721779e [38/45] vdpa: make sure set_features in invoked for legacy config: x86_64-randconfig-a014-20200727 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 84d40e4b4bc64456abf5ef5663871053b40e84ac commit: fee8fe6bd8ccacd27e963b71b4f943be3721779e [38/45] vdpa: make sure set_features in invoked for legacy :::::: branch date: 5 hours ago :::::: commit date: 6 hours ago config: x86_64-randconfig-s021-20200727 (attached as .config) compiler: gcc-9 (Debian 9.3.0-14) 9.3.0

We normally expect vdpa to use the modern interface. However for consistency, let's use same APIs as vhost for legacy guests. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_vdpa.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c index c30eb55030be..4a9ddb44b2a7

For new helpers handling legacy features to be effective, vhost needs to invoke them. Tie them in. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/vdpa.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c index 18869a35d408..3674404688f5 100644 --- a/drivers/vhost/vdpa.c +++ b/drivers/vhost/vdpa.c

tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next head: c5db5a8d998da36ada7287aa53b4ed501a0a2b2b commit: b1b0d638e6f93b91cf34585350bb00035d066989 [13/15] mm: Introduce Reported pages config: ia64-defconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 7.4.0 reproduce: wget

Hello, I''ve mapped granted pages in a module inserted in a domU and I''m trying to get the PFN or the struct page * of these pages to map them in the user space : Mapping granted pages (that''s xensocket''s code) : if (!(x->buffer_area = alloc_vm_area(buffer_num_pages * PAGE_SIZE, NULL))) { DPRINTK("error: cannot allocate %d buffer pages\n",

Config space endian-ness is currently a mess: fields are not tagged with the correct endian-ness so it's easy to make mistakes like instanciating config space in native endian-ness. The following patches adding sparse tagging are currently in my tree. Lightly tested. As a follow-up, I plan to add new APIs that handle modern config space in a more efficient way (bypassing the version check).

kmap_atomic() is deprecated in favor of kmap_local_page() since commit f3ba3c710ac5 ("mm/highmem: Provide kmap_local*"). With kmap_local_page() the mappings are per thread, CPU local, can take page-faults, and can be called from any context (including interrupts). Furthermore, the tasks can be preempted and, when they are scheduled to run again, the kernel virtual addresses are restored

Hi, just for your information and maybe for some help: with 5.1rc1 and SVM enabled i see the following backtrace [1] when the nouveau card (reverse prime) goes to sleep, for now i have papered over with [2] which leaves me with userspace hangs. Any pointers where to look for the actual culprit? PS: Card is: nouveau 0000:01:00.0: NVIDIA GP106 (136000a1) Greetings, Tobias [1]: BUG: unable

Assumes hypervisor interface headers have been sync-ed after the hypervisor side patch was applied. As usual, written and tested on 2.6.27.3 and made apply to the 2.6.18 tree without further testing. Signed-off-by: Jan Beulich <jbeulich@novell.com> Index: head-2008-10-24/arch/i386/mm/highmem-xen.c =================================================================== ---

vDPA supports the possibility to use user VA in the iotlb messages. So, let's add support for user VA in vringh to use it in the vDPA simulators. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- Notes: v3: - refactored avoiding code duplication [Eugenio] v2: - replace kmap_atomic() with kmap_local_page() [see previous patch] - fix cast warnings when

On Tue, Mar 21, 2023 at 11:43?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > vDPA supports the possibility to use user VA in the iotlb messages. > So, let's add support for user VA in vringh to use it in the vDPA > simulators. > > Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> > --- > > Notes: > v3: > - refactored

Hi Kishon: On 2020/9/14 ??3:23, Kishon Vijay Abraham I wrote: >> Then you need something that is functional equivalent to virtio PCI >> which is actually the concept of vDPA (e.g vDPA provides alternatives if >> the queue_sel is hard in the EP implementation). > Okay, I just tried to compare the 'struct vdpa_config_ops' and 'struct > vhost_config_ops' (

vDPA device is a device that uses a datapath which complies with the virtio specifications with vendor specific control path. vDPA devices can be both physically located on the hardware or emulated by software. vDPA hardware devices are usually implemented through PCIE with the following types: - PF (Physical Function) - A single Physical Function - VF (Virtual Function) - Device that supports