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
---
Cc: Stefano Stabellini
Cc: Russell King
Stefano, I've dropped your r
lying 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
---
Cc: K
the
extent_order field to directly allocate/free chunk of the Linux page
size.
Note that PVMMU is only used for PV guest (which is x86) and the page
granularity is always 4KB. Some BUILD_BUG_ON has been added to ensure
that because the code has not been modified.
Signed-off-by: Julien Grall
---
Cc
granularity).
Futhermore, in the case of persistent grant we allocate one Linux page
per grant although only the 4KB of the page will be effectively use.
This could be improved by share the page with multiple grants.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: Roger Pau Monné
chunk). That would require more care when we fail to expand the
event channel.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Note I haven't updated the suggestion to reduce the memory
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
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
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
I kept the hypercall arguments in remap_data to avoid
= bytes;
offset = 0;
/* Next page */
if (size) {
BUG_ON(!PageCompound(page));
page++;
}
}
Regards,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
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
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
I think that the
nballooned_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/
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
Cc: Stefano
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
Cc: Stefano Stabellini
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc
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_re
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
Reviewed-by: David Vrabel
Cc: Stefano Stabellini
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Konrad Rzeszutek Wilk
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
>> interrup
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
Reviewed-by: David Vrabel
Cc: Stefano Stabellini
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Konrad Rzeszutek Wilk
t enabled on my config.
Reviewed-by: Julien Grall
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 F
KB
page granularity.
Regards,
On 07/08/2015 09:46, Julien Grall wrote:
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.
Any attempt to boot a Linux guest with 64KB pages enabled wi
eturn the MFN associated to the first 4KB of the page */
static inline unsigned long page_to_mfn(struct page *page)
{
- return pfn_to_mfn(page_to_pfn(page));
+ return pfn_to_mfn(xen_page_to_pfn(page));
}
struct xen_memory_region {
Aside from the two minor suggestions:
Reviewed
ge, pfn, data);
+ if (ret)
+ return ret;
+ }
+
+ return ret;
+}
+
+
#endif/* _XEN_PAGE_H */
Reviewed-by: Stefano Stabellini
Thank you,
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
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
Thank you,
--
Julien Grall
--
To unsubscribe from this
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
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 of
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: a
to RPP and SPP?
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,
--
Ju
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, i
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 thin
page = balloon_retrieve(false);
>> BUG_ON(page == NULL);
>>
>> -pfn = page_to_pfn(page);
>> -
>> #ifdef CONFIG_XEN_HAVE_PVMMU
>> +frame_idx = 0;
>
> Shouldn't this be before the beginning of the loop above?
H... 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
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
It should be just 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
--
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
arm/device-tree/guest.txt
[3] http://www.gossamer-threads.com/lists/xen/devel/397349
--
Julien Grall
The loop that browses the array compat_hwcap_str will stop when a NULL
is encountered, however NULL is missing at the end of array. This will
result to overrun until one NULL is found somewhere in the memory.
Fixes: 44b82b7700d0 "arm64: Fix up /proc/cpuinfo"
Signed-off-by: Julien Gral
Hi Mark,
On 10/05/2016 15:54, Mark Rutland wrote:
On Tue, May 10, 2016 at 03:40:31PM +0100, Julien Grall wrote:
The loop that browses the array compat_hwcap_str will stop when a NULL
is encountered, however NULL is missing at the end of array. This will
result to overrun until one NULL is
new fields.
Regards,
--
Julien Grall
looning on x86 32 bit PAE")
Cc: sta...@vger.kernel.org
Reviewed-by: Stefano Stabellini
You have applied this patch to the branch for-linus-4.8 but not
for-linus-4.7. Is it intentional?
Regards,
--
Julien Grall
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
>
> LGTM, only a couple of typos and a simplification:
>
> Signed-off-by: Roger Pau Monné
Do you mean Acked
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
>>>>
>>>> Si
he most restrictive one, for example 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 bod
ross 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 "unsubscribe linux-kernel" in
the body of
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
Reviewed-by: Julien Grall
Regards,
--
Julien Grall
--
To unsubscri
info;
> @@ -313,7 +364,9 @@ static int __init xen_guest_init(void)
>
> pv_time_ops.steal_clock = xen_stolen_accounting;
> static_key_slow_inc(¶virt_steal_enabled);
> -
> + if (xen_initial_domain())
> + pvclock_gtod_register_notifier(&xen_pvclock_gtod_n
(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
>>>
>>> ---
>>&g
Hi Konrad,
On 01/12/15 18:52, Konrad Rzeszutek Wilk wrote:
> On Tue, Dec 01, 2015 at 05:55:48PM +0000, Julien Grall wrote:
>> Hi Konrad,
>>
>> On 01/12/15 15:37, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Nov 18, 2015 at 06:57:23PM +, Julien Grall wrote:
>>&
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
e_max_* helpers haven'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-o
szutek Wilk
Cc: "Roger Pau Monné"
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Bob Liu
Julien Grall (2):
block/xen-blkfront: Introduce blkif_ring_get_request
block/xen-blkfront: Handle non-indirect grant with 64KB pages
drivers/block/xen-blkfront.c | 258 ++
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Cc: Bob Liu
Changes in v2:
- Add Royger's ack
Hi,
Ping?
Regards,
On 18/11/15 18:57, Julien Grall wrote:
> Hi all,
>
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity which doesn't boot when the backend isn't using indirect
> descriptor.
>
> This has been su
ctor fingered the commit 578270b "block: fix segment split".
If I reverted this patch on top of 4.4-rc3 and everything seems to
work fine.
Anyone have any ideas?
FWIW, the 2 patches mentioned in a related thread [1] are already
part of Linux 4.4-rc3.
Regards,
[1] https://lkml.org/lkml
Hi,
Just noticed that Bob and Konrad have not been correctly CCed.
Regards,
On 18/11/15 18:57, Julien Grall wrote:
> Hi all,
>
> This is a follow-up on the previous discussion [1] related to guest using 64KB
> page granularity which doesn't boot when the backend isn
us' master and the problem disappear, thank
you!
Next time I will try your branch before sending an error report.
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
Mor
Hi Konrad,
On 01/12/15 15:37, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 18, 2015 at 06:57:23PM +0000, Julien Grall wrote:
>> Hi all,
>>
>> This is a follow-up on the previous discussion [1] related to guest using
>> 64KB
>> page granularity which doesn&#x
This has been introduced by commit 82d340081b6f71237373d1452e3573a5a122794c
"arm64: Improve error reporting on set_pte_at() checks". This is because
mmdebug.h relies on the includer to properly include the dependencies.
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Catalin Marinas
C
Hi Catalin,
On 14/12/15 16:22, Catalin Marinas wrote:
> On Mon, Dec 14, 2015 at 04:07:24PM +0000, Julien Grall wrote:
>> Linux 4.4-rc5 doesn't build for arm64 with CONFIG_XEN=y enabled:
>>
>> In file included from linux/arch/arm64/include/asm/pgtable.h:60:0,
>>
it's used by itself (UART, virtual GIC...).
So we would need to modify the FreeBSD data structure to pass the new
DT/ACPI. Does the metadata are standardize? I.e is it stable from
accross FreeBSD version?
Anyway, I'd like to avoid any FreeBSD specific code in Xen, and even any
OS specific c
On 10/09/15 13:05, Roger Pau Monné wrote:
> El 10/09/15 a les 13.48, Julien Grall ha escrit:
>> On 10/09/15 12:32, Andrew Turner wrote:
>>> On Thu, 10 Sep 2015 16:41:56 +0800
>>> Shannon Zhao wrote:
>>>
>>>> From: Shannon Zhao
>>
With 64KB page granularity support, the frame number will be different.
It will be easier to modify the behavior in a single place rather than
in each caller.
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Russell King
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David
e are very
minimal because we only need to check the first Xen PFN.
Note that it may be possible to optimize the function
check_page_physically_contiguous to avoid looping over every Xen PFN
for local memory. Although I will let this optimization for a follow-up.
Signed-off-by: Julien Grall
C
onrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Cc: David Vrabel
Julien Grall (2):
xen/swiotlb: Pass addresses rather than frame numbers to
xen_arch_need_swiotlb
xen/swiotlb: Add support for 64KB page granularity
arch/arm/include/asm/xen/page-coherent.h | 26 ---
arch/arm/includ
On 10/09/15 10:54, Marc Zyngier wrote:
> Hi Julian,
Hi Marc,
> On 09/09/15 20:23, Julien Grall wrote:
>> Hi,
>>
>> I've been trying the latest linus/master (a794b4f), which include this
>> patch, as baremetal kernel on X-gene. This is failing on early bo
On 10/09/15 17:30, Marc Zyngier wrote:
> On 10/09/15 17:23, Julien Grall wrote:
>> On 10/09/15 10:54, Marc Zyngier wrote:
>
> [...]
>
>>> In the meantime, can you give the following patch a shot? My Mustang is
>>> wired to a 4kB CPU interface, so I'll n
On 11/09/2015 11:54, Ian Campbell wrote:
On Thu, 2015-09-10 at 17:23 +0100, Julien Grall wrote:
I applied the two patches on top of linus/master and I'm able to boot
correctly on X-gene. Thank you!
Perhaps we should replicate this approach in Xen and get r
On 11/09/15 12:09, Marc Zyngier wrote:
> On 11/09/15 11:59, Julien Grall wrote:
>>
>>
>> On 11/09/2015 11:54, Ian Campbell wrote:
>>> On Thu, 2015-09-10 at 17:23 +0100, Julien Grall wrote:
>>>> I applied the two patches on top of linus/master and I'
e operations, so the change
is only arm32 specific.
Reported-by: Riku Voipio
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Russell King
ARM64 doesn't seem to have priviledge no-access support yet so there
is nothing to do for now.
I haven't look x86 at a
On 11/09/15 15:29, Ian Campbell wrote:
> On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
>> When Xen is copyin data to/from the guest it will check if the kernel
>
> "copying"
>
>> has the right to do the access. If not, the hypercall will return a
On 11/09/15 15:55, Ian Campbell wrote:
> On Fri, 2015-09-11 at 15:45 +0100, Julien Grall wrote:
>> On 11/09/15 15:29, Ian Campbell wrote:
>>> On Fri, 2015-09-11 at 15:16 +0100, Julien Grall wrote:
>>>> When Xen is copyin data to/from the guest it will check
On 11/09/15 16:25, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 03:56:38PM +0100, Julien Grall wrote:
>> Well, we can't assume that the function will be called with uaccess
>> disabled.
>
> Please explain your reasoning.
I think I was confused about the u
h. So I won't fix this one.
All the others will be fixed on the next version.
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.k
these operations, so the change
is only arm32 specific.
Reported-by: Riku Voipio
Signed-off-by: Julien Grall
---
Cc: Stefano Stabellini
Cc: Russell King
Changes in v2:
- Directly enable/disable the user space access in assembly
- Typoes
ARM64 doesn't seem to
On 11/09/15 18:00, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>> +/*
>> + * Privcmd calls are issued by the userspace. We need to allow the
>> + * kernel to access the userspace memory before
On 11/09/15 18:32, Julien Grall wrote:
> On 11/09/15 18:00, Russell King - ARM Linux wrote:
>> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>>> + /*
>>> +* Privcmd calls are issued by the userspace. We need to allow the
>>> +* kernel t
On 11/09/15 18:00, Russell King - ARM Linux wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Julien Grall wrote:
>> +/*
>> + * Privcmd calls are issued by the userspace. We need to allow the
>> + * kernel to access the userspace memory before
The code to get a request is always the same. Therefore we can factorize
it in a single function.
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Boris Ostrovsky
Cc: David Vrabel
---
drivers/block/xen-blkfront.c | 30 +++
Rzeszutek Wilk
Cc: "Roger Pau Monné"
Cc: Boris Ostrovsky
Cc: David Vrabel
Julien Grall (2):
block/xen-blkfront: Introduce blkif_ring_get_request
block/xen-blkfront: Handle non-indirect grant with 64KB pages
drivers/block/xen-blkfront.c | 229
upported and we may be able to
support directly any change in the block framework that lower down the
mimimal size of a request.
[1] http://lists.xen.org/archives/html/xen-devel/2015-08/msg02200.html
Signed-off-by: Julien Grall
---
Cc: Konrad Rzeszutek Wilk
Cc: "Roger Pau Monné&quo
Hi,
A quick update on the TODO.
On 07/09/15 16:33, Julien Grall wrote:
> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
> hypercall interface and PV protocol are always based on 4KB page granularity.
>
> Any attempt to boot a Linux guest with 64KB pages
On 12/09/2015 10:46, Bob Liu wrote:
Hi Julien,
Hi Bob,
On 09/12/2015 03:31 AM, Julien Grall wrote:
Hi all,
This is a follow-up on the previous discussion [1] related to guest using 64KB
page granularity not booting with backend using non-indirect grant.
This has been successly tested
ring request. You may want
to give a look to this patch before looking to this series.
Regards,
[1] https://lwn.net/Articles/656797/
[2] http://www.spinics.net/lists/arm-kernel/msg430468.html
--
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Hi Roger,
On 14/09/15 09:56, Roger Pau Monné wrote:
> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>> Hi all,
>>
>> ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
>> hypercall interface and PV protocol are always based on 4KB page granul
On 14/09/15 12:04, Roger Pau Monné wrote:
> Hello,
>
> El 14/09/15 a les 12.40, Julien Grall ha escrit:
>> Hi Roger,
>>
>> On 14/09/15 09:56, Roger Pau Monné wrote:
>>> El 07/09/15 a les 17.33, Julien Grall ha escrit:
>>>> Hi all,
>>&g
> BLKIF_MAX_SEGMENTS_PER_REQUEST) {
/*
> @@ -716,8 +728,6 @@ static int blkif_queue_rw_req(struct request *req, struct
> blkfront_ring_info *ri
> if (setup.segments)
> kunmap_atomic(setup.segments);
>
> - rinfo->ring.req_prod_pvt++;
>
ve the readability of the code. It even
make it worth in the two cases.
--
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.ht
Hi Konrad,
On 07/12/15 15:01, Konrad Rzeszutek Wilk wrote:
> On Mon, Dec 07, 2015 at 02:21:46PM +0000, Julien Grall wrote:
>> Thank you, the changes look good to me. What about patch #2?
>
> Oh, I thought you said you would rebase it - so I had been waiting
> for that
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
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 Gbi
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
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
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 use
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
>>
>> The PV block protocol is using 4KB page granularity. The goal of this
>> patch is to allow a Linux using 64KB page granularity usi
Hello Wei,
On 19/02/16 07:24, Wei Huang wrote:
On 02/11/2016 09:33 AM, Julien Grall wrote:
[...]
This is also dropping arch_timer_get_timecounter as it was only used by
the KVM code. Furthermore, a stub for the new helper hasn't been
introduced because KVM is requiring the arch time
On 19/02/16 10:53, Julien Grall wrote:
--
Julien Grall
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person
tables are duplicated which I think make more complex to
support new firmware tables.
Regards,
[1] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018482.html
[2] https://lists.cs.columbia.edu/pipermail/kvmarm/2016-February/018355.html
Julien Grall (5):
KVM: arm/arm64: arch_timer
information about the virtual GIC.
With this change, the virtual GIC becomes agnostic to the firmware
table and KVM will be able to initialize the vGIC on ACPI.
Signed-off-by: Julien Grall
---
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Gleb Natapov
Cc: Paolo Bonzini
include/kvm/arm_vgic.h | 7
timer code.
With this changes, the support for ACPI is coming free.
Signed-off-by: Julien Grall
---
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Gleb Natapov
Cc: Paolo Bonzini
drivers/clocksource/arm_arch_timer.c | 2 ++
include/clocksource
information. Also fill up the structure for GICv2.
Signed-off-by: Julien Grall
---
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
drivers/irqchip/irq-gic-common.c | 13 ++
drivers/irqchip/irq-gic-common.h | 3 ++
drivers/irqchip/irq-gic.c | 78
Fill up the recently introduced gic_kvm_info with the virtual GIC
information.
Signed-off-by: Julien Grall
---
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
drivers/irqchip/irq-gic-v3.c | 43 ++
include/linux/irqchip/arm-gic-common.h | 1
, a stub for the new helper hasn't been
introduced because KVM is requiring the arch timer for both ARM64 and
ARM32.
Signed-off-by: Julien Grall
---
Cc: Daniel Lezcano
Cc: Thomas Gleixner
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Gleb Natapov
Cc: Paolo Bonzini
drivers/clocks
On 08/02/16 18:30, Marc Zyngier wrote:
Julien,
Hi Marc,
On 08/02/16 16:47, Julien Grall wrote:
[...]
+static void __init gic_of_setup_kvm_info(struct device_node *node)
+{
+ int ret;
+ struct resource r;
+ unsigned int irq;
+
+ gic_v2_kvm_info.type = GIC_V2
heers,
--
Julien Grall
Hi Marc,
On 10/02/16 14:46, Marc Zyngier wrote:
On 10/02/16 14:19, Julien Grall wrote:
On 09/02/16 20:49, Christoffer Dall wrote:
+static void __init gic_acpi_setup_kvm_info(void)
+{
+ gic_v2_kvm_info.type = GIC_V2;
+
+ gic_v2_kvm_info.maint_irq = acpi_register_gsi(NULL
301 - 400 of 727 matches
Mail list logo
