From: Oleksandr Tyshchenko <Oleksandr_Tyshchenko@epam.com>
To: Xenia Ragiadakou <burzalodowa@gmail.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Juergen Gross <jgross@suse.com>,
Oleksandr Tyshchenko <olekstysh@gmail.com>
Subject: Re: [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts
Date: Thu, 6 Oct 2022 21:13:20 +0000 [thread overview]
Message-ID: <b3b8047e-b4a5-1e75-2a55-a7beecf8ca7d@epam.com> (raw)
In-Reply-To: <96a16b32-0950-b538-65e5-9955ed8cc529@gmail.com>
On 06.10.22 20:59, Xenia Ragiadakou wrote:
Hello Xenia
>
> On 10/6/22 15:09, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Although XEN_PAGE_SIZE is equal to PAGE_SIZE (4KB) for now, it would
>> be more correct to use Xen specific #define-s as XEN_PAGE_SIZE can
>> be changed at some point in the future.
>>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>> ---
>> Cc: Juergen Gross <jgross@suse.com>
>> Cc: Xenia Ragiadakou <burzalodowa@gmail.com>
>>
>> As it was proposed at:
>> https://urldefense.com/v3/__https://lore.kernel.org/xen-devel/20221005174823.1800761-1-olekstysh@gmail.com/__;!!GF_29dbcQIUBPA!zHt-xZ_7tZc_EM6zva21E_YgwIiEeimFWfsJIpPwAu-TBcnzQhXHqlKzmXmwIcI6uIx_arHNZiaZeHt_428_8p-DyMpd$
>> [lore[.]kernel[.]org]
>>
>> Should go in only after that series.
>> ---
>> drivers/xen/grant-dma-ops.c | 20 ++++++++++----------
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
>> index c66f56d24013..5392fdc25dca 100644
>> --- a/drivers/xen/grant-dma-ops.c
>> +++ b/drivers/xen/grant-dma-ops.c
>> @@ -31,12 +31,12 @@ static DEFINE_XARRAY_FLAGS(xen_grant_dma_devices,
>> XA_FLAGS_LOCK_IRQ);
>> static inline dma_addr_t grant_to_dma(grant_ref_t grant)
>> {
>> - return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant << PAGE_SHIFT);
>> + return XEN_GRANT_DMA_ADDR_OFF | ((dma_addr_t)grant <<
>> XEN_PAGE_SHIFT);
>> }
>
> With this change, can the offset added to the dma handle, generated by
> grant_to_dma(), be the offset in the page? Couldn't it corrupt the
> grant ref?
Good point, indeed, I think it could corrupt if guest uses a different
than Xen page granularity (i.e 64KB).
>
>> static inline grant_ref_t dma_to_grant(dma_addr_t dma)
>> {
>> - return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
>> PAGE_SHIFT);
>> + return (grant_ref_t)((dma & ~XEN_GRANT_DMA_ADDR_OFF) >>
>> XEN_PAGE_SHIFT);
>> }
>> static struct xen_grant_dma_data *find_xen_grant_dma_data(struct
>> device *dev)
>> @@ -79,7 +79,7 @@ static void *xen_grant_dma_alloc(struct device
>> *dev, size_t size,
>> unsigned long attrs)
>> {
>> struct xen_grant_dma_data *data;
>> - unsigned int i, n_pages = PFN_UP(size);
>> + unsigned int i, n_pages = XEN_PFN_UP(size);
>> unsigned long pfn;
>> grant_ref_t grant;
>> void *ret;
>> @@ -91,14 +91,14 @@ static void *xen_grant_dma_alloc(struct device
>> *dev, size_t size,
>> if (unlikely(data->broken))
>> return NULL;
>> - ret = alloc_pages_exact(n_pages * PAGE_SIZE, gfp);
>> + ret = alloc_pages_exact(n_pages * XEN_PAGE_SIZE, gfp);
>> if (!ret)
>> return NULL;
>> pfn = virt_to_pfn(ret);
>> if (gnttab_alloc_grant_reference_seq(n_pages, &grant)) {
>> - free_pages_exact(ret, n_pages * PAGE_SIZE);
>> + free_pages_exact(ret, n_pages * XEN_PAGE_SIZE);
>> return NULL;
>> }
>> @@ -116,7 +116,7 @@ static void xen_grant_dma_free(struct device
>> *dev, size_t size, void *vaddr,
>> dma_addr_t dma_handle, unsigned long attrs)
>> {
>> struct xen_grant_dma_data *data;
>> - unsigned int i, n_pages = PFN_UP(size);
>> + unsigned int i, n_pages = XEN_PFN_UP(size);
>> grant_ref_t grant;
>> data = find_xen_grant_dma_data(dev);
>> @@ -138,7 +138,7 @@ static void xen_grant_dma_free(struct device
>> *dev, size_t size, void *vaddr,
>> gnttab_free_grant_reference_seq(grant, n_pages);
>> - free_pages_exact(vaddr, n_pages * PAGE_SIZE);
>> + free_pages_exact(vaddr, n_pages * XEN_PAGE_SIZE);
>> }
>> static struct page *xen_grant_dma_alloc_pages(struct device *dev,
>> size_t size,
>> @@ -168,7 +168,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
>> device *dev, struct page *page,
>> unsigned long attrs)
>> {
>> struct xen_grant_dma_data *data;
>> - unsigned int i, n_pages = PFN_UP(offset + size);
>> + unsigned int i, n_pages = XEN_PFN_UP(offset + size);
>
> The offset, here, refers to the offset in the page ...
>
>> grant_ref_t grant;
>> dma_addr_t dma_handle;
>> @@ -200,8 +200,8 @@ static void xen_grant_dma_unmap_page(struct
>> device *dev, dma_addr_t dma_handle,
>> unsigned long attrs)
>> {
>> struct xen_grant_dma_data *data;
>> - unsigned long offset = dma_handle & (PAGE_SIZE - 1);
>> - unsigned int i, n_pages = PFN_UP(offset + size);
>> + unsigned long offset = dma_handle & ~XEN_PAGE_MASK;
>
> ... while, here, it refers to the offset in the grant.
> So, the calculated number of grants may differ.
Good point, I think you are right, so we need to additionally use
xen_offset_in_page() macro in xen_grant_dma_map_page(),
something like that to be squashed with current patch:
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 9d5eca6d638a..bb984dc05deb 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -169,7 +169,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
unsigned long attrs)
{
struct xen_grant_dma_data *data;
- unsigned int i, n_pages = XEN_PFN_UP(offset + size);
+ unsigned int i, n_pages = XEN_PFN_UP(xen_offset_in_page(offset)
+ size);
grant_ref_t grant;
dma_addr_t dma_handle;
@@ -191,7 +191,7 @@ static dma_addr_t xen_grant_dma_map_page(struct
device *dev, struct page *page,
xen_page_to_gfn(page) + i, dir ==
DMA_TO_DEVICE);
}
- dma_handle = grant_to_dma(grant) + offset;
+ dma_handle = grant_to_dma(grant) + xen_offset_in_page(offset);
return dma_handle;
}
Did I get your point right?
>
>
>> + unsigned int i, n_pages = XEN_PFN_UP(offset + size);
>> grant_ref_t grant;
>> if (WARN_ON(dir == DMA_NONE))
>
Thank you.
--
Regards,
Oleksandr Tyshchenko
next prev parent reply other threads:[~2022-10-06 21:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 12:09 [PATCH] xen/virtio: Convert PAGE_SIZE/PAGE_SHIFT/PFN_UP to Xen counterparts Oleksandr Tyshchenko
2022-10-06 13:28 ` Juergen Gross
2022-10-06 17:59 ` Xenia Ragiadakou
2022-10-06 21:13 ` Oleksandr Tyshchenko [this message]
2022-10-07 4:46 ` Juergen Gross
2022-10-07 7:15 ` Xenia Ragiadakou
2022-10-07 13:43 ` Oleksandr Tyshchenko
2022-10-07 15:50 ` Xenia Ragiadakou
2022-10-07 16:16 ` Oleksandr Tyshchenko
2022-10-07 17:35 ` Oleksandr Tyshchenko
2022-10-07 20:08 ` Xenia Ragiadakou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3b8047e-b4a5-1e75-2a55-a7beecf8ca7d@epam.com \
--to=oleksandr_tyshchenko@epam.com \
--cc=burzalodowa@gmail.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olekstysh@gmail.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).