All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Reviewed-by: David Vrabel david.vra...@citrix.com
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Cc: Konrad Rzeszutek Wilk konrad.w
are running in HVM domains.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Appeared in Linux 4.1. HVM backend, which
;
/* Next page */
if (size) {
BUG_ON(!PageCompound(page));
page++;
}
}
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Hi Boris,
On 07/08/2015 22:33, Boris Ostrovsky wrote:
On 08/07/2015 12:34 PM, Julien Grall wrote:
The variable xen_store_mfn is effectively storing a GFN and not an MFN.
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris
, I'm wondering if we could re-use the lru field to link the page
when allocate them and retrieve in the second loop in order to avoid the
pages array.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
Hi Stefano,
On 10/08/15 13:57, Stefano Stabellini wrote:
On Mon, 10 Aug 2015, David Vrabel wrote:
On 10/08/15 13:03, Stefano Stabellini wrote:
On Fri, 7 Aug 2015, Julien Grall wrote:
- rc = HYPERVISOR_memory_op(XENMEM_add_to_physmap_range, xatp);
- return rc 0 ? rc : err;
+ for (i = 0
Hi Stefano,
On 10/08/15 11:50, Stefano Stabellini wrote:
On Fri, 7 Aug 2015, Julien Grall wrote:
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0
with 4KB
PFN when it's not necessary, it make the code more confusing to read.
If your only concern is the size of the array, we could decrease the
number of frames by batch. Or allocation the variable once a boot time.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line
On 10/08/15 12:25, Stefano Stabellini wrote:
yes and page/pages:
xen/biomerge: Don't allow biovec's to be merged when Linux is not using 4KB
pages
Why the ' in biovec's ? Shouldn't we says biovecs directly?
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line
On 10/08/15 12:39, Wei Liu wrote:
On Mon, Aug 10, 2015 at 10:57:48AM +0100, Julien Grall wrote:
while (size 0) {
BUG_ON(offset = PAGE_SIZE);
bytes = PAGE_SIZE - offset;
if (bytes size)
bytes = size
Hi David,
On 24/07/15 11:36, David Vrabel wrote:
On 09/07/15 21:42, Julien Grall wrote:
Only use the first 4KB of the page to store the events channel info. It
means that we will wast 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array
On 27/07/15 10:30, David Vrabel wrote:
On 25/07/15 00:21, Julien Grall wrote:
On 24/07/2015 12:47, David Vrabel wrote:
@@ -550,6 +551,11 @@ int alloc_xenballooned_pages(int nr_pages, struct
page **pages)
page = balloon_retrieve(true);
if (page) {
pages[pgno
or not. It will always return
1 on ARM and keep the same behavior on x86.
This is also allow us to drop the usage of xen_have_vector_callback
entirely in the ARM code.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Reviewed-by: David Vrabel david.vra...@citrix.com
Cc: Stefano Stabellini stefano.stabell
On 27/07/15 13:35, David Vrabel wrote:
On 27/07/15 12:35, Julien Grall wrote:
Currently, the event channel rebind code is gated with the presence of
the vector callback.
The virtual interrupt controller on ARM has the concept of per-CPU
interrupt (PPI) which allow us to support per-VCPU
Hi David,
On 24/07/15 10:28, David Vrabel wrote:
On 09/07/15 21:42, Julien Grall wrote:
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support of 64K page granularity for ARM64 guest, it
won't be possible to re-use the Linux
On 24/07/15 10:48, David Vrabel wrote:
On 24/07/15 10:39, Julien Grall wrote:
Hi David,
On 24/07/15 10:28, David Vrabel wrote:
On 09/07/15 21:42, Julien Grall wrote:
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support
On 24/07/15 10:31, David Vrabel wrote:
On 09/07/15 21:42, Julien Grall wrote:
The Xen interface is always using 4KB page. This means that a Linux page
may be split across multiple Xen page when the page granularity is not
the same.
This helper will break down a Linux page into 4KB chunk
On 24/07/15 11:34, David Vrabel wrote:
On 24/07/15 10:51, Julien Grall wrote:
On 24/07/15 10:48, David Vrabel wrote:
On 24/07/15 10:39, Julien Grall wrote:
Hi David,
On 24/07/15 10:28, David Vrabel wrote:
On 09/07/15 21:42, Julien Grall wrote:
The Xen hypercall interface is always using 4K
On 24/07/15 11:10, David Vrabel wrote:
On 24/07/15 10:54, Julien Grall wrote:
On 24/07/15 10:31, David Vrabel wrote:
On 09/07/15 21:42, Julien Grall wrote:
The Xen interface is always using 4KB page. This means that a Linux page
may be split across multiple Xen page when the page granularity
(alloc_xenballooned_pages);
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
or not. It will always return
1 on ARM and keep the same behavior on x86.
This is also allow us to drop the usage of xen_have_vector_callback
entirely in the ARM code.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Catalin Marinas catalin.mari
The commit 6f6c15ef912465b3aaafe709f39bd6026a8b3e72 xen/pvhvm: Remove
the xen_platform_pci int. makes the x86 version of
xen_pci_platform_unplug static.
Therefore we don't need anymore to define a dummy xen_pci_platform_unplug
for ARM.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc
Hi Stefano,
On 16/07/15 16:11, Stefano Stabellini wrote:
On Thu, 9 Jul 2015, Julien Grall wrote:
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant-pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed
... Yes. Note that I only compiled tested on x86, it would be good
if someone test on real hardware at some point (I don't have any x86 Xen
setup).
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
as fast as __pfn_to_mfn. I
would definitely recommend it.
I'd like to see a basic support of 64KB support on Xen pushed in Linux
upstream before looking to possible improvement in the code. Can we
defer this as the follow-up of this series?
Regards,
--
Julien Grall
--
To unsubscribe from
Hi Stefano,
On 16/07/15 18:12, Stefano Stabellini wrote:
On Thu, 9 Jul 2015, Julien Grall wrote:
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map
On 16/07/15 17:07, Julien Grall wrote:
+pfn = xen_page_to_pfn(page) + (offset XEN_PAGE_SHIFT);
+
+while (len) {
+glen = min_t(unsigned int, XEN_PAGE_SIZE - goffset, len);
Similarly I don't think we want to support glen != XEN_PAGE_SIZE here
See my answer above
On 17/07/15 15:45, Stefano Stabellini wrote:
On Fri, 17 Jul 2015, Julien Grall wrote:
On 17/07/15 14:20, Stefano Stabellini wrote:
We would have to run some benchmarks, but I think it would still be a
win. We should write an ad-hoc __pfn_to_mfn translation function that
operates on a range
Hi Boris,
On 14/07/2015 17:28, Boris Ostrovsky wrote:
On 07/13/2015 06:05 PM, Julien Grall wrote:
On 13/07/2015 22:13, Boris Ostrovsky wrote:
On 07/09/2015 04:42 PM, Julien Grall wrote:
-
struct remap_data {
xen_pfn_t *fgmfn; /* foreign domain's gmfn */
+xen_pfn_t *efgmfn
,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
);
+ if (ret)
+ return ret;
+ }
+
+ return ret;
+}
+
+
#endif/* _XEN_PAGE_H */
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Thank you,
--
Julien Grall
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
Hi Stefano,
On 16/07/2015 16:33, Stefano Stabellini wrote:
On Fri, 10 Jul 2015, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
When Linux is using 64K page granularity, every page will be slipt in
multiple non-contiguous 4K MFN (page granularity
Hi Stefano,
On 16/07/2015 16:43, Stefano Stabellini wrote:
On Thu, 9 Jul 2015, Julien Grall wrote:
Only use the first 4KB of the page to store the events channel info. It
means that we will wast 60KB every time we allocate page for:
^ waste
* control block
Hi Stefano,
On 16/07/2015 17:01, Stefano Stabellini wrote:
On Thu, 9 Jul 2015, Julien Grall wrote:
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers
gnttab_page_grant_foreign_access_ref, that grants all 4K in the page.
Unless having a different prototype it won't be possible to do it. This
is because one ref = one grant. We would need a list of grant.
In any case
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
Thank you,
--
Julien Grall
?
SPP has been removed by commit 548f7c94759ac58d4744ef2663e2a66a106e21c5
as it was unused.
For RPP, it's used internally so there is no need to switch to
XEN_PAGE_SIZE. Otherwise we will waste 60KB for each internal page
allocated (see gnttab_init).
Regards,
--
Julien Grall
Hi Konrad,
On 10/07/2015 21:12, Konrad Rzeszutek Wilk wrote:
On Thu, Jul 09, 2015 at 09:42:21PM +0100, Julien Grall wrote:
When Linux is using 64K page granularity, every page will be slipt in
multiple non-contiguous 4K MFN (page granularity of Xen).
But you don't care about
Hi Boris,
On 13/07/2015 22:13, Boris Ostrovsky wrote:
On 07/09/2015 04:42 PM, Julien Grall wrote:
-
struct remap_data {
xen_pfn_t *fgmfn; /* foreign domain's gmfn */
+xen_pfn_t *efgmfn; /* pointer to the end of the fgmfn array */
It might be better to keep size of fgmfn array
On 09/07/15 21:42, Julien Grall wrote:
Average betwen 10 iperf :
DOM0 Guest Result
4KB-mod 64KB3.176 Gbits/sec
4KB-mod 4KB-mod 3.245 Gbits/sec
4KB-mod 4KB 3.258 Gbits/sec
4KB 4KB 3.292 Gbits/sec
4KB 4KB-mod
Hi,
On 09/07/15 21:42, Julien Grall wrote:
+static void xennet_make_one_txreq(unsigned long mfn, unsigned int offset,
+ unsigned int *len, void *data)
+{
+ struct xennet_gnttab_make_txreq *info = data;
+
+ info-tx-flags |= XEN_NETTXF_more_data
Hi Roger,
On 21/07/15 10:54, Roger Pau Monné wrote:
El 09/07/15 a les 22.42, Julien Grall ha escrit:
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating
Hi Roger,
On 21/07/15 11:16, Roger Pau Monné wrote:
El 09/07/15 a les 22.42, Julien Grall ha escrit:
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant-pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code
Hi Roger,
On 21/07/15 12:06, Roger Pau Monné wrote:
El 09/07/15 a les 22.42, Julien Grall ha escrit:
From: Julien Grall julien.gr...@linaro.org
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device
Hi,
On 21/07/15 11:30, Roger Pau Monné wrote:
El 09/07/15 a les 22.42, Julien Grall ha escrit:
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio
As the caller is allocating the resource, let him handle the release.
This has been introduced by commit b75351f "mm: memory hotplug with
an existing resource".
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: David Vrabel <david.vra...@citrix.com>
Cc: linux...@kvack.
(CC David, Boris and Konrad)
On 13/11/15 18:10, Stefano Stabellini wrote:
> On Fri, 13 Nov 2015, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 12/11/15 17:30, Stefano Stabellini wrote:
>>> Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com&g
On 12/11/15 17:51, Roger Pau Monné wrote:
> El 12/11/15 a les 18.30, Julien Grall ha escrit:
>> Hi,
>>
>> On 12/11/15 16:40, Roger Pau Monné wrote:
>>>> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
>>>>
>>>
Hi,
On 12/11/15 16:40, Roger Pau Monné wrote:
>> [1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
>>
>> Signed-off-by: Julien Grall <julien.gr...@citrix.com>
>
> LGTM, only a couple of typos and a simplification:
>
> Signed-off-by: R
xample if we have ERROR and
> NOTSUPP we should return ERROR, while if we have OK and NOTSUPP we
> should return NOTSUPP.
I will give a look.
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vg
ards,
[1]
https://git.kernel.org/cgit/linux/kernel/git/xen/tip.git/log/?h=for-linus-4.4
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordo
at I'm planning to update the commit message to summarize my
previous mail.
> Acked-by: Roger Pau Monné <roger@citrix.com>
Thank you, I will try to resend a new version today.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
<konrad.w...@oracle.com>
Cc: "Roger Pau Monné" <roger@citrix.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
Julien Grall (2):
block/xen-blkfront: Introduce blkif_ring_get_request
block/xen-blkfront: Handle
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Acked-by: Roger Pau Monné <roger@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostro
n't been updated.
The block code will set the mimimum size supported and we may be able
to support directly any change in the block framework that lower down
the minimal size of a request.
[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
Signed-off-by: Julien Grall <jul
rguments should be aligned to the first parameter. I.e:
xenbus_printf(XBT_NIL, dev->nodename,
"request-abs-pointer", "1");
See an example in xenkbd_backend_changed.
With that fixed:
Reviewed-by: Julien Grall <julien.gr...@citrix.com>
> + i
> absolute but the backend will supply relative coordinates.
>
>
> I cannot understand
If the frontend is not able to write the node "request-abs-pointer" in
the xenstore, the backend will always supply relative coordinates.
Although, as abs = 1, the frontend will be
On 06/10/15 11:06, Roger Pau Monné wrote:
> El 06/10/15 a les 11.58, Julien Grall ha escrit:
>> Hi Roger,
>>
>> On 06/10/2015 10:39, Roger Pau Monné wrote:
>>> El 05/10/15 a les 19.05, Julien Grall ha escrit:
>>>> On 05/10/15 17:01, Roger Pau Monné wr
"xen_pfn_t" in commit 965c0aaafe3e75d4e65cd4ec862915869bde3abd
"xen: balloon: use correct type for frame_list".
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.c
Hi Roger,
On 06/10/2015 10:39, Roger Pau Monné wrote:
El 05/10/15 a les 19.05, Julien Grall ha escrit:
On 05/10/15 17:01, Roger Pau Monné wrote:
El 11/09/15 a les 21.32, Julien Grall ha escrit:
ring_req->u.rw.nr_segments = num_grant;
+ if (unlik
Linux may use a different page size than the size of grant. So make
clear that the order is actually in number of grant.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: "Roger Pau Monné" <roger@citrix
helper which take an array of Linux page and a number of
grant and will figure out the address of each grant.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David
lk <konrad.w...@oracle.com>
Cc: "Roger Pau Monné" <roger@citrix.com>
Cc: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Julien Grall (3):
xen/xenbus: Rename *RING_PAGE* to *RING_GRANT*
xen/grant-table: Add an helper to iterate over a specific number of
grant
will always be mapped on the
first 4KB of each Linux page which make the final ring not contiguous in
the memory.
This can be fixed by mapping multiple grant in a same Linux page.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com&g
to become free. Usage count = 1
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Bernhard Thaler bernhard.tha...@wvnet.at
Cc: Pablo Neira Ayuso pa...@netfilter.org
Cc: f...@strlen.de
Cc: ian.campb...@citrix.com
Cc: wei.l...@citrix.com
Cc: Bob Liu bob@oracle.com
---
Note that it's impossible
From: Julien Grall julien.gr...@linaro.org
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page
will have
to split the Linux page in 4K chunk before asking Xen to add/remove the
frame from the guest.
Note that this can work on any page granularity assuming it's a multiple
of 4K.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
Changes in v2
on the grant table code.
Note that we allocate a Linux page for each rx skb but only the first
4KB is used. We may improve the memory usage by extending the size of
the rx skb.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky
The Xen interface is always using 4KB page. This means that a Linux page
may be split across multiple Xen page when the page granularity is not
the same.
This helper will break down a Linux page into 4KB chunk and call the
helper on each of them.
Signed-off-by: Julien Grall julien.gr
-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
Changes in v2:
- Remove the workaround and check if the Linux page granularity
is the same
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant-pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Roger
to copy
data from persistent grant or indirect grant. Avoid to set it for other
use case as it will have no meaning given the page will be split in
multiple grant.
Provide 2 functions, to setup indirect grant, the other for bio page.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
drivers/xen/events
on the grant table
code.
Note that the grant table code is allocating a Linux page per grant
which will result to waste 6OKB for every grant when Linux is using 64KB
page granularity. This could be improved by sharing the page between
multiple grants.
Signed-off-by: Julien Grall julien.gr
branch xen-64k-v2
Comments, suggestions are welcomed.
Sincerely yours,
Cc: david.vra...@citrix.com
Cc: konrad.w...@oracle.com
Cc: boris.ostrov...@oracle.com
Cc: wei.l...@citrix.com
Cc: roger@citrix.com
Julien Grall (20):
xen: Add Xen specific page definition
xen: Introduce a function
result
to page_mfn not being defined when necessary.
Signed-off-by: Julien Grall julien.gr...@linaro.org
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel david.vra...@citrix.com
---
Changes in v2:
- Patch added
---
arch
grant.
In order to help some PV drivers, the callback is allowed to use less
data and must update the resulting length. This is useful for netback.
Also provide and helper to count the number of grants within a given
contiguous region.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad
execution path, separate
the function in 2. This will also remove one level of tabulation.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Roger Pau Monné roger@citrix.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel
on the grant table code.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: net...@vger.kernel.org
---
Improvement such as support of 64KB grant is not taken into
consideration in this patch because we have the requirement
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: net...@vger.kernel.org
---
Changes in v2
definition. They have exactly the same name but prefixed with
XEN_/xen_ prefix.
Also modify page_to_pfn to use new Xen page definition.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David
will have
to map multiple Xen PFN in a single Linux page.
Note that this solution works on page granularity which is a multiple of
4KB.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: David Vrabel
with multiple
grant. It will require some care with the {Set,Clear}ForeignPage macro.
Note that no changes has been made in the x86 code because both Linux
and Xen will only use 4KB page granularity.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Reviewed-by: David Vrabel david.vra...@citrix.com
Cc
page even though only the
first 4KB is used. I don't think this is really important for now as it
helps to have the pointer 4KB aligned (XENMEM_add_to_physmap is taking a
Xen PFN).
Signed-off-by: Julien Grall julien.gr...@citrix.com
Reviewed-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Jiri Slaby jsl...@suse.cz
Cc: David Vrabel david.vra...@citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc
Hi Konrad,
On 09/11/15 16:05, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 09, 2015 at 03:51:48PM +0000, Julien Grall wrote:
>> Hi,
>>
>> Any comments on this new version?
>
> I completly ignored thinking that the:
>
> c004a6f block/xen-blkfront: Make it running o
n't been updated.
The block code will set the mimimum size supported and we may be able
to support directly any change in the block framework that lower down
the minimal size of a request.
[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
Signed-off-by: Julien Grall <jul
<konrad.w...@oracle.com>
Cc: "Roger Pau Monné" <roger@citrix.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
Cc: Bob Liu <bob@oracle.com>
Julien Grall (2):
block/xen-blkfront: Introduce blkif_ring_get_
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall <julien.gr...@citrix.com>
Acked-by: Roger Pau Monné <roger@citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostro
313,7 +364,9 @@ static int __init xen_guest_init(void)
>
> pv_time_ops.steal_clock = xen_stolen_accounting;
> static_key_slow_inc(_steal_enabled);
> -
> + if (xen_initial_domain())
> + pvclock_gtod_register_notifier(_pvclock_gtod_notifier);
> +
I think, you've introduced a trail
we have similar requirement across the architecture as
this helpers may be called from common code.
> int HYPERVISOR_multicall(struct multicall_entry *calls, uint32_t nr);
>
> static inline int
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line &
Hi Stefano,
On 12/11/15 17:30, Stefano Stabellini wrote:
> The hypervisor actually exposes an additional field to struct
> pvclock_wall_clock, with the high 32 bit seconds.
>
> Signed-off-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
Reviewed-by: Julie
On 20/08/15 09:10, Roger Pau Monné wrote:
Hello,
Hi,
I have some comments regarding the commit message, IMHO it would be good
that a native English speaker reviews it too.
El 07/08/15 a les 18.46, Julien Grall ha escrit:
The PV block protocol is using 4KB page granularity. The goal
Hi David,
On 20/08/15 10:55, David Vrabel wrote:
On 07/08/15 17:46, Julien Grall wrote:
The console ring is always based on the page granularity of Xen.
[...]
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -230,7 +230,7 @@ static int xen_hvm_console_init(void
On 20/08/15 10:59, David Vrabel wrote:
On 07/08/15 17:46, Julien Grall wrote:
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over
Hi David,
On 20/08/15 10:51, David Vrabel wrote:
On 07/08/15 17:46, Julien Grall wrote:
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers
multiple xen_pfn, so we want to get
the next xen_pfn for the next iteration.
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/major
uest allocation and freeing.
>
> Reported-by: Julien Grall <julien.gr...@citrix.com>
> Signed-off-by: Roger Pau Monné <roger@citrix.com>
> Cc: Julien Grall <julien.gr...@citrix.com>
> Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> Cc: Boris
On 07/09/15 07:07, Bob Liu wrote:
> Hi Julien,
Hi Bob,
> On 09/04/2015 09:51 PM, Julien Grall wrote:
>> Hi Roger,
>>
>> On 04/09/15 11:08, Roger Pau Monne wrote:
>>> Request allocation has been moved to connect_ring, which is called every
>>> time
-off-by: Julien Grall <julien.gr...@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabell...@eu.citrix.com>
---
Cc: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Cc: Boris Ostrovsky <boris.ostrov...@oracle.com>
Cc: David Vrabel <david.vra...@citrix.com>
201 - 300 of 1315 matches
Mail list logo
