Hi Julien,
On 25.08.20 15:02, Julien Grall wrote:
> May I ask why did you create a new transport rather than using the
> existing one?
We wanted a mechanism for dynamically creating virtio devices at
runtime. I looked at virtio-mmio briefly and it seemed to me that a lot
of things would have to
On 26.08.20 10:27, Jürgen Groß wrote:
> On 26.08.20 10:14, Simon Leiner wrote:
>> On 26.08.20 09:59, Jürgen Groß wrote:
>>> This seems to be an Arm specific function.
>>
>> Is that a problem? The caller site is also ARM specific.
>
> The caller site is AR
On 26.08.20 09:59, Jürgen Groß wrote:
> This seems to be an Arm specific function.
Is that a problem? The caller site is also ARM specific.
> virt_addr_valid() seems to be a good fit.
If you prefer that anyway, I will change it and resubmit that part of
the patch.
Simon
On 26.08.20 08:20, Jan Beulich wrote:
> Hmm, to me __phys_to_virt() and __virt_to_phys_nodebug() give
> the impression that they're just linear transformations of the
> address, which would seem to suggest there's a pre-determined
> address range used for the direct map.
>From eyeballing the kerne
On some architectures (like ARM), virt_to_gfn cannot be used for
vmalloc'd memory because of its reliance on virt_to_phys. This patch
introduces a check for vmalloc'd addresses and obtains the PFN using
vmalloc_to_pfn in that case.
Signed-off-by: Simon Leiner
---
drivers/
As virt_to_gfn uses virt_to_phys, it will return invalid addresses when
used with vmalloc'd addresses. This patch introduces a warning, when
virt_to_gfn is used in this way.
Signed-off-by: Simon Leiner
---
include/xen/arm/page.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
On 20.08.20 20:35, Stefano Stabellini wrote:
> Thank for the well-written analysis of the problem. The following
should
> work to translate the virtual address properly in xenbus_grant_ring:
>
> if (is_vmalloc_addr(vaddr))
> page = vmalloc_to_page(vaddr);
> else
>
Hi Julien,
On 20.08.20 13:17, Julien Grall wrote:
> There is a lot of interest to get Virtio working on Xen at the moment.
> Is this going to be a new transport layer for Virtio?
It is designed that way, yes. The current implementation (based on
virtio_mmio.c) has a few limitations:
- Only the
