Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi, On 12/03/18 02:57, Peng Fan wrote: Hi Stefano, On Fri, Mar 09, 2018 at 05:09:20PM -0800, Stefano Stabellini wrote: On Fri, 9 Mar 2018, Julien Grall wrote: Furthermore, the workaround is not in Linux upstream and I doubt this will be accepted as it is. So I am not convinced that we should modify Xen interface for that. Anyway, given that your silicon is going to be respined, then you probably want to restrict to run on the same cluster. Hi Pen, I think that i.MX8 is a critical platform for the future of embedded virtualization and I really want to support it in Xen out of the box. However, I agree with Julien that if there will be a new version of the silicon with this issue properly fixed in hardware, then it might not make sense to add workarounds in Xen for this. Unless you think the version of the hardware with the errata will be commercialized? Understand. I just thought some kernel code use machine compatible string to do some check for passthrough case. Usually you give access to a device and describe it in the device-tree. The kernel will then use the appropriate driver for that device. You should never need to know what the machine is. Can you describe why this would be necessary in your use case? Some early customers might use the 1.0 chip to do their development, but I think all will switch to use new Silicon in the end. Do you plan to upstream your workaround in Linux? If not, then it might No plan. This workaround might not be accepted by Linux community. Based on what you said above, I would not even consider to upstream workaround for Xen. be best for you to carry the workaround for Xen in your Xen tree, the same way you'll do for Linux. For workarounds that affect/involve both Linux and Xen, we tend to follow the same policy as the Linux kernel, unless we have good reasons not to. On the other end, if you intend to upstream the Linux workaround, then we can discuss what to do for Xen. Also let me expand on one of Julien's suggestions that actually I think is quite good. Assuming that we have the tlb maintenance workaround in the hypervisor, it would be safe to start guests only in the big or only in the little cluster, right? In other words, you could still use both I am a bit lost here. Are you refering Julien's suggestion 3? "3) Trap all TLBs access from the guest and convert them to TLB alle1s/vmalls12e1is" Currently, only use one the of the 2 clusters, I do not meet issue. No change to xen and domu not aware of linux workaround. Do you mean it is not safe without tlb maintenance workaround on my current hardware, even if restricting Guest OS only have one kind of cpu? I think so. But this is only based on how I understood the description provided in the commit message you pointed early on. I have no insight whether TLB flush in hypervisor are going to be affected by the workaround. I would recommend to speak with your hardware team for that. A naive question, what case would require tlb broadcast from A53 to A72 in XEN? page balloon? Xen is sharing page-table between all the pCPU. As the hypervisor will run on the both cluster, you would need to convert all innershareable TLBs flush by VA to a full innershareable. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
On 12/03/18 02:32, Peng Fan wrote: On Fri, Mar 09, 2018 at 02:40:25PM +, Julien Grall wrote: Hi, On 09/03/18 13:30, Peng Fan wrote: Hi Julien, On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote: Hi Peng, On 09/03/18 09:05, Peng Fan wrote: On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote: On 08/03/18 12:43, Peng Fan wrote: There are a major difference between Dom0 and DomU in your setup. Dom0 vCPUs are pinned to a specific pCPU, so they can't move around. For DomU, each vCPU are pinned to a set of pCPUs, so they can move around. But, did you check the DomU has the workaround enabled? I am asking that because it looks like to me the way to detect the workaround is based on a device (scu) and not processor. So I am not convinced that DomU is actually using your workaround. Just checked this. Because xen toolstack create device tree with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";", but the linux code use "fsl,imx8qm" to detect soc, then call scu to get revision of chip. But how does the guest call the scu? We are doing GPU and display passthrough, also some other IPs passthrough. we could not totally rely on Dom0 to configure the pinmux, gpio, clk, relying on dom0 to do that would bring much hack code to our kernel, also runtime clk set rate in domu could not be done. So we expose an interface to domu to directly communicate with SCU(system control unit). Do you always expect a domain to access the SCU? Even with no passthrough involved? only needed when a domain only needs to directly access hardware. Then your suggested workaround can't work for guest with not device passthrough. I would recommend to find a workaround that works for every guests. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi Stefano, On Fri, Mar 09, 2018 at 05:09:20PM -0800, Stefano Stabellini wrote: >On Fri, 9 Mar 2018, Julien Grall wrote: >> Furthermore, the workaround is not in Linux upstream and I doubt this will be >> accepted as it is. So I am not convinced that we should modify Xen interface >> for that. >> >> Anyway, given that your silicon is going to be respined, then you probably >> want to restrict to run on the same cluster. > >Hi Pen, > >I think that i.MX8 is a critical platform for the future of embedded >virtualization and I really want to support it in Xen out of the box. > >However, I agree with Julien that if there will be a new version of the >silicon with this issue properly fixed in hardware, then it might not >make sense to add workarounds in Xen for this. Unless you think the >version of the hardware with the errata will be commercialized? Understand. I just thought some kernel code use machine compatible string to do some check for passthrough case. Some early customers might use the 1.0 chip to do their development, but I think all will switch to use new Silicon in the end. > >Do you plan to upstream your workaround in Linux? If not, then it might No plan. This workaround might not be accepted by Linux community. >be best for you to carry the workaround for Xen in your Xen tree, the >same way you'll do for Linux. For workarounds that affect/involve both >Linux and Xen, we tend to follow the same policy as the Linux kernel, >unless we have good reasons not to. On the other end, if you intend to >upstream the Linux workaround, then we can discuss what to do for Xen. > > >Also let me expand on one of Julien's suggestions that actually I think >is quite good. Assuming that we have the tlb maintenance workaround in >the hypervisor, it would be safe to start guests only in the big or only >in the little cluster, right? In other words, you could still use both I am a bit lost here. Are you refering Julien's suggestion 3? "3) Trap all TLBs access from the guest and convert them to TLB alle1s/vmalls12e1is" Currently, only use one the of the 2 clusters, I do not meet issue. No change to xen and domu not aware of linux workaround. Do you mean it is not safe without tlb maintenance workaround on my current hardware, even if restricting Guest OS only have one kind of cpu? A naive question, what case would require tlb broadcast from A53 to A72 in XEN? page balloon? Thanks Peng. >clusters but only starting guests in one or the other, not both. This is >a good compromise because it allows full usage of the hardware, a >relatively small patch in Xen, and no guest visible changes (such as >toolstack changes to modify the compatible line). Guest visible and user >visible changes are particularly troublesome to maintain in the long >term and this is reason why we are reticent in introducing them. The tlb >maintenance workaround in the hypervisor is something much easier to >manage and we could consider taking it in if hardware with the errata >will become available to customers. > >Cheers, > >Stefano -- ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
On Fri, Mar 09, 2018 at 02:40:25PM +, Julien Grall wrote:
>Hi,
>
>On 09/03/18 13:30, Peng Fan wrote:
>>Hi Julien,
>>On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
>>>Hi Peng,
>>>
>>>On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
>On 08/03/18 12:43, Peng Fan wrote:
>There are a major difference between Dom0 and DomU in your setup.
>Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
>For DomU, each vCPU are pinned to a set of pCPUs, so they can move
>around.
>
>But, did you check the DomU has the workaround enabled? I am asking
>that because it looks like to me the way to detect the workaround is
>based on a device (scu) and not processor. So I am not convinced that
>DomU is actually using your workaround.
Just checked this. Because xen toolstack create device tree
with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";",
but the linux code use "fsl,imx8qm" to detect soc, then call scu
to get revision of chip.
>>>
>>>But how does the guest call the scu?
>>
>>We are doing GPU and display passthrough, also some other IPs passthrough.
>>we could not totally rely on Dom0 to configure the pinmux, gpio, clk,
>>relying on dom0 to do that would bring much hack code to our kernel, also
>>runtime clk set rate in domu could not be done.
>>
>>So we expose an interface to domu to directly communicate with SCU(system
>>control unit).
>
>Do you always expect a domain to access the SCU? Even with no
>passthrough involved?
only needed when a domain only needs to directly access hardware.
>
>>
>>>
After add an entry in linux side "{ .compatible = "xen,xenvm", .data =
_soc_data, },"
It seems works. Passed a map/unmap stress test which easily fail without
the tlb workaround.
Wonder is it ok to specific machine compatible in domu.cfg and let xen stack
use this machine compatible other than "xen,xenvm"? Is this acceptable by
community?
>>>
>>>A user should be able to boot a guest safely on any machine without
>>>having to hack the configuration file. He should also be able to boot
>>>a guest with both ACPI and DT as this is independent from the real
>>>machine. So for me the way to find the workaround at the moment is
>>>not acceptable for a Xen guest upstream.
>>
>>I have no idea about ACPI (:
>>we are mainly working on embedded case, and mostly we are partitioning
>>our IPs. So our kernel normally only work with the dedicated DTB.
>>I am not asking to replace "xen,xenvm", just would like to add a option
>>that if user specific a machine compatible in cfg or else, xen toolstack
>>could add that in the final device tree.
>
>I know you were suggesting that and my point stands. Xen VM are not
>compatible with IMX8 platform.
>
>And again, a user should not have to tweak his configuration file,
>have to passthrough some device to an untrusted guest in order to
>have a guest booting normally on your platform. That is breaking the
>whole purpose of virtualization.
>
>Furthermore, the workaround is not in Linux upstream and I doubt this
>will be accepted as it is. So I am not convinced that we should
>modify Xen interface for that.
>
>Anyway, given that your silicon is going to be respined, then you
>probably want to restrict to run on the same cluster.
Understand.
Thanks,
Peng.
>
>Cheers,
>
>--
>Julien Grall
--
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
On Fri, 9 Mar 2018, Julien Grall wrote: > Furthermore, the workaround is not in Linux upstream and I doubt this will be > accepted as it is. So I am not convinced that we should modify Xen interface > for that. > > Anyway, given that your silicon is going to be respined, then you probably > want to restrict to run on the same cluster. Hi Pen, I think that i.MX8 is a critical platform for the future of embedded virtualization and I really want to support it in Xen out of the box. However, I agree with Julien that if there will be a new version of the silicon with this issue properly fixed in hardware, then it might not make sense to add workarounds in Xen for this. Unless you think the version of the hardware with the errata will be commercialized? Do you plan to upstream your workaround in Linux? If not, then it might be best for you to carry the workaround for Xen in your Xen tree, the same way you'll do for Linux. For workarounds that affect/involve both Linux and Xen, we tend to follow the same policy as the Linux kernel, unless we have good reasons not to. On the other end, if you intend to upstream the Linux workaround, then we can discuss what to do for Xen. Also let me expand on one of Julien's suggestions that actually I think is quite good. Assuming that we have the tlb maintenance workaround in the hypervisor, it would be safe to start guests only in the big or only in the little cluster, right? In other words, you could still use both clusters but only starting guests in one or the other, not both. This is a good compromise because it allows full usage of the hardware, a relatively small patch in Xen, and no guest visible changes (such as toolstack changes to modify the compatible line). Guest visible and user visible changes are particularly troublesome to maintain in the long term and this is reason why we are reticent in introducing them. The tlb maintenance workaround in the hypervisor is something much easier to manage and we could consider taking it in if hardware with the errata will become available to customers. Cheers, Stefano ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi,
On 09/03/18 13:30, Peng Fan wrote:
Hi Julien,
On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
Hi Peng,
On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
On 08/03/18 12:43, Peng Fan wrote:
There are a major difference between Dom0 and DomU in your setup.
Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
For DomU, each vCPU are pinned to a set of pCPUs, so they can move
around.
But, did you check the DomU has the workaround enabled? I am asking
that because it looks like to me the way to detect the workaround is
based on a device (scu) and not processor. So I am not convinced that
DomU is actually using your workaround.
Just checked this. Because xen toolstack create device tree
with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";",
but the linux code use "fsl,imx8qm" to detect soc, then call scu
to get revision of chip.
But how does the guest call the scu?
We are doing GPU and display passthrough, also some other IPs passthrough.
we could not totally rely on Dom0 to configure the pinmux, gpio, clk,
relying on dom0 to do that would bring much hack code to our kernel, also
runtime clk set rate in domu could not be done.
So we expose an interface to domu to directly communicate with SCU(system
control unit).
Do you always expect a domain to access the SCU? Even with no
passthrough involved?
After add an entry in linux side "{ .compatible = "xen,xenvm", .data =
_soc_data, },"
It seems works. Passed a map/unmap stress test which easily fail without
the tlb workaround.
Wonder is it ok to specific machine compatible in domu.cfg and let xen stack
use this machine compatible other than "xen,xenvm"? Is this acceptable by
community?
A user should be able to boot a guest safely on any machine without
having to hack the configuration file. He should also be able to boot
a guest with both ACPI and DT as this is independent from the real
machine. So for me the way to find the workaround at the moment is
not acceptable for a Xen guest upstream.
I have no idea about ACPI (:
we are mainly working on embedded case, and mostly we are partitioning
our IPs. So our kernel normally only work with the dedicated DTB.
I am not asking to replace "xen,xenvm", just would like to add a option
that if user specific a machine compatible in cfg or else, xen toolstack
could add that in the final device tree.
I know you were suggesting that and my point stands. Xen VM are not
compatible with IMX8 platform.
And again, a user should not have to tweak his configuration file, have
to passthrough some device to an untrusted guest in order to have a
guest booting normally on your platform. That is breaking the whole
purpose of virtualization.
Furthermore, the workaround is not in Linux upstream and I doubt this
will be accepted as it is. So I am not convinced that we should modify
Xen interface for that.
Anyway, given that your silicon is going to be respined, then you
probably want to restrict to run on the same cluster.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi Julien,
On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
>Hi Peng,
>
>On 09/03/18 09:05, Peng Fan wrote:
>>On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
>>>On 08/03/18 12:43, Peng Fan wrote:
>>>There are a major difference between Dom0 and DomU in your setup.
>>>Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
>>>For DomU, each vCPU are pinned to a set of pCPUs, so they can move
>>>around.
>>>
>>>But, did you check the DomU has the workaround enabled? I am asking
>>>that because it looks like to me the way to detect the workaround is
>>>based on a device (scu) and not processor. So I am not convinced that
>>>DomU is actually using your workaround.
>>
>>Just checked this. Because xen toolstack create device tree
>>with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";",
>>but the linux code use "fsl,imx8qm" to detect soc, then call scu
>>to get revision of chip.
>
>But how does the guest call the scu?
We are doing GPU and display passthrough, also some other IPs passthrough.
we could not totally rely on Dom0 to configure the pinmux, gpio, clk,
relying on dom0 to do that would bring much hack code to our kernel, also
runtime clk set rate in domu could not be done.
So we expose an interface to domu to directly communicate with SCU(system
control unit).
>
>>
>>After add an entry in linux side "{ .compatible = "xen,xenvm", .data =
>>_soc_data, },"
>>It seems works. Passed a map/unmap stress test which easily fail without
>>the tlb workaround.
>>
>>Wonder is it ok to specific machine compatible in domu.cfg and let xen stack
>>use this machine compatible other than "xen,xenvm"? Is this acceptable by
>>community?
>
>A user should be able to boot a guest safely on any machine without
>having to hack the configuration file. He should also be able to boot
>a guest with both ACPI and DT as this is independent from the real
>machine. So for me the way to find the workaround at the moment is
>not acceptable for a Xen guest upstream.
I have no idea about ACPI (:
we are mainly working on embedded case, and mostly we are partitioning
our IPs. So our kernel normally only work with the dedicated DTB.
I am not asking to replace "xen,xenvm", just would like to add a option
that if user specific a machine compatible in cfg or else, xen toolstack
could add that in the final device tree.
Anyway new silicon will have issue fixed.
>
>What could be acceptable for the community is one of the 3 solutions below:
> 1) Only use one of the 2 clusters
The easiest way:)
> 2) Restrict both Xen and Guest to use only 36-bit VA.
I have no idea, need to check
> 3) Trap all TLBs access from the guest and convert them to TLB
>alle1s/vmalls12e1is
This will introduce performance penalty. I would not do this.
Thanks,
Peng.
>
>I would be happy to consider any other.
>
>Cheers,
>
>--
>Julien Grall
--
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi Peng,
On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
On 08/03/18 12:43, Peng Fan wrote:
There are a major difference between Dom0 and DomU in your setup.
Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
For DomU, each vCPU are pinned to a set of pCPUs, so they can move
around.
But, did you check the DomU has the workaround enabled? I am asking
that because it looks like to me the way to detect the workaround is
based on a device (scu) and not processor. So I am not convinced that
DomU is actually using your workaround.
Just checked this. Because xen toolstack create device tree
with compatible "compatible = "xen,xenvm-4.10", "xen,xenvm";",
but the linux code use "fsl,imx8qm" to detect soc, then call scu
to get revision of chip.
But how does the guest call the scu?
After add an entry in linux side "{ .compatible = "xen,xenvm", .data =
_soc_data, },"
It seems works. Passed a map/unmap stress test which easily fail without
the tlb workaround.
Wonder is it ok to specific machine compatible in domu.cfg and let xen stack
use this machine compatible other than "xen,xenvm"? Is this acceptable by
community?
A user should be able to boot a guest safely on any machine without
having to hack the configuration file. He should also be able to boot a
guest with both ACPI and DT as this is independent from the real
machine. So for me the way to find the workaround at the moment is not
acceptable for a Xen guest upstream.
What could be acceptable for the community is one of the 3 solutions below:
1) Only use one of the 2 clusters
2) Restrict both Xen and Guest to use only 36-bit VA.
3) Trap all TLBs access from the guest and convert them to TLB
alle1s/vmalls12e1is
I would be happy to consider any other.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
>Hi,
>
>On 08/03/18 12:43, Peng Fan wrote:
>>I am not sure whether this issue cause DomU big/Little not work.
>
>Well, I would recommend to speak with NXP whether this errata affects
>TLB flush for Hypervisor Page-Table or Stage-2 Page-Table.
I tried the following, but no help. Not sure my patch is correct. I
think it affects stage2 TLB.
--- a/xen/include/asm-arm/arm64/flushtlb.h
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -6,7 +6,7 @@ static inline void flush_tlb_local(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1;"
+"tlbi alle1;"
"dsb sy;"
"isb;"
: : : "memory");
@@ -17,7 +17,7 @@ static inline void flush_tlb(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1is;"
+"tlbi alle1;"
>>>
>>>I am not sure why you drop the innershareable here?
>>Just want to invalid all the tlb, innershareable could be kept.
>>This is not a formal patch, just my trying to narrow the issue.
>
>alle1 will only flush the TLBs of the local processor. The flush will
>not get propagated to the other CPUs of the system. So you definitely
>want this to be innershareable to avoid the other processors
>containing stale TLBs.
>
>>>
"dsb sy;"
"isb;"
: : : "memory");
@@ -39,7 +39,7 @@ static inline void flush_tlb_all(void)
{
asm volatile(
"dsb sy;"
-"tlbi alle1is;"
+"tlbi alle1;"
>>>
>>>Ditto.
>>>
"dsb sy;"
"isb;"
: : : "memory");
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -74,14 +74,16 @@ static inline void flush_xen_data_tlb_local(void)
/* Flush TLB of local processor for address va. */
static inline void __flush_xen_data_tlb_one_local(vaddr_t va)
{
-asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
+//asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) :
+ "memory");
}
/* Flush TLB of all processors in the inner-shareable domain for
* address va. */
static inline void __flush_xen_data_tlb_one(vaddr_t va)
{
-asm volatile("tlbi vae2is, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
>>>
>>>Why do you replace an innershareable call to a local call? Is it part of the
>>>errata?
>>
>>No. Just my trying to narrow down.
>
>Then you should keep the innershareable. See above.
>
>>>
+//asm volatile("tlbi vae2is, %0;" : : "r" (va>>PAGE_SHIFT) :
+ "memory");
}
>
>>So wonder has this patchset been tested on Big/Little Hardware?
>
>This series only adds facility to report the correct MIDR to the guest.
>If your platform requires more, then it would be necessary send a patch for
>>>Xen.
Do you have any suggestions? Besides MIDR/ACTLR/Cacheline, are there more
>>>needed?
>>>
>>>Having a bit more details from your side would be helpful. At the moment, I
>>>have
>>>no clue what's going on.
>>
>>As from the linux kernel commit:
>> on i.MX8QM TO1.0, there is an issue: the bus width between A53-CCI-A72
>> is limited to 36bits.TLB maintenance through DVM messages over AR
>> channel,
>> some bits will be forced(truncated) to zero as the followings:
>>
>> ASID[15:12] is forced to 0
>> VA[48:45] is forced to 0
>> VA[44:41] is forced to 0
>> VA[39:36] is forced to 0
>>
>> This issue will result in the TLB aintenance across the clusters not
>> working
>> as expected due to some VA and ASID bits get truncated and forced to be
>> zero.
>>
>> The SW workaround is: use the vmalle1is if VA larger than 36bits or
>> ASID[15:12] is not zero, otherwise, we use original TLB maintenance path.
>>
>>When doing tlb maintenance through DVM from A53 to A72, some bits are forced
>>to 0, this means TLB may not be really invalidated from A72 perspective.
>>
>>Currently I am trying a domu with big/little capability, but not allowing
>>big/little vcpu
>>migration.
>>
>>I am not sure whether this hardware issue impacts DomU or not. Or it is
>>software issue.
>>As you could see dom0 has 6 vcpus, I did a stress test and not found issue on
>>dom0.
>
>There are a major difference between Dom0 and DomU in your setup.
>Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
>For DomU, each vCPU are pinned to a set of pCPUs, so they can move
>around.
>
>But, did you check the DomU has the workaround enabled? I am asking
>that because it looks like to me the way to detect the workaround is
>based on a device (scu) and not processor. So I am not convinced that
>DomU is actually using your workaround.
Just checked this. Because
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi,
On 08/03/18 12:43, Peng Fan wrote:
I am not sure whether this issue cause DomU big/Little not work.
Well, I would recommend to speak with NXP whether this errata affects
TLB flush for Hypervisor Page-Table or Stage-2 Page-Table.
I tried the following, but no help. Not sure my patch is correct. I
think it affects stage2 TLB.
--- a/xen/include/asm-arm/arm64/flushtlb.h
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -6,7 +6,7 @@ static inline void flush_tlb_local(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1;"
+"tlbi alle1;"
"dsb sy;"
"isb;"
: : : "memory");
@@ -17,7 +17,7 @@ static inline void flush_tlb(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1is;"
+"tlbi alle1;"
I am not sure why you drop the innershareable here?
Just want to invalid all the tlb, innershareable could be kept.
This is not a formal patch, just my trying to narrow the issue.
alle1 will only flush the TLBs of the local processor. The flush will
not get propagated to the other CPUs of the system. So you definitely
want this to be innershareable to avoid the other processors containing
stale TLBs.
"dsb sy;"
"isb;"
: : : "memory");
@@ -39,7 +39,7 @@ static inline void flush_tlb_all(void)
{
asm volatile(
"dsb sy;"
-"tlbi alle1is;"
+"tlbi alle1;"
Ditto.
"dsb sy;"
"isb;"
: : : "memory");
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -74,14 +74,16 @@ static inline void flush_xen_data_tlb_local(void)
/* Flush TLB of local processor for address va. */
static inline void __flush_xen_data_tlb_one_local(vaddr_t va)
{
-asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
+//asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) :
+ "memory");
}
/* Flush TLB of all processors in the inner-shareable domain for
* address va. */
static inline void __flush_xen_data_tlb_one(vaddr_t va)
{
-asm volatile("tlbi vae2is, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
Why do you replace an innershareable call to a local call? Is it part of the
errata?
No. Just my trying to narrow down.
Then you should keep the innershareable. See above.
+//asm volatile("tlbi vae2is, %0;" : : "r" (va>>PAGE_SHIFT) :
+ "memory");
}
So wonder has this patchset been tested on Big/Little Hardware?
This series only adds facility to report the correct MIDR to the guest.
If your platform requires more, then it would be necessary send a patch for
Xen.
Do you have any suggestions? Besides MIDR/ACTLR/Cacheline, are there more
needed?
Having a bit more details from your side would be helpful. At the moment, I have
no clue what's going on.
As from the linux kernel commit:
on i.MX8QM TO1.0, there is an issue: the bus width between A53-CCI-A72
is limited to 36bits.TLB maintenance through DVM messages over AR channel,
some bits will be forced(truncated) to zero as the followings:
ASID[15:12] is forced to 0
VA[48:45] is forced to 0
VA[44:41] is forced to 0
VA[39:36] is forced to 0
This issue will result in the TLB aintenance across the clusters not
working
as expected due to some VA and ASID bits get truncated and forced to be
zero.
The SW workaround is: use the vmalle1is if VA larger than 36bits or
ASID[15:12] is not zero, otherwise, we use original TLB maintenance path.
When doing tlb maintenance through DVM from A53 to A72, some bits are forced
to 0, this means TLB may not be really invalidated from A72 perspective.
Currently I am trying a domu with big/little capability, but not allowing
big/little vcpu
migration.
I am not sure whether this hardware issue impacts DomU or not. Or it is
software issue.
As you could see dom0 has 6 vcpus, I did a stress test and not found issue on
dom0.
There are a major difference between Dom0 and DomU in your setup. Dom0
vCPUs are pinned to a specific pCPU, so they can't move around. For
DomU, each vCPU are pinned to a set of pCPUs, so they can move around.
But, did you check the DomU has the workaround enabled? I am asking that
because it looks like to me the way to detect the workaround is based on
a device (scu) and not processor. So I am not convinced that DomU is
actually using your workaround.
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
> -Original Message- > From: Julien Grall [mailto:julien.gr...@arm.com] > Sent: 2018年3月8日 20:30 > To: Peng Fan <peng@nxp.com>; Peng Fan <van.free...@gmail.com>; > Stefano Stabellini <sstabell...@kernel.org> > Cc: xen-de...@lists.xen.org > Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support > > Hi, > > On 08/03/18 12:23, Peng Fan wrote: > > > > > >> -Original Message- > >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On > >> Behalf Of Julien Grall > >> Sent: 2018年3月8日 19:04 > >> To: Peng Fan <van.free...@gmail.com>; Stefano Stabellini > >> <sstabell...@kernel.org> > >> Cc: xen-de...@lists.xen.org > >> Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support > >> > >> Hello, > >> > >> On 08/03/18 06:15, Peng Fan wrote: > >>> Hi Stefano, > >>> On Fri, Mar 02, 2018 at 11:05:54AM -0800, Stefano Stabellini wrote: > >>>> Hi all, > >>>> > >>>> This series changes the initialization of two virtual registers to > >>>> make sure they match the value of the underlying physical cpu. > >>>> > >>>> It also disables cpus different from the boot cpu, unless a newly > >>>> introduced command line option is specified. In that case, it > >>>> explains how to setup the system to avoid corruptions, which > >>>> involves manually specifying the cpu affinity of all domains, > >>>> because the scheduler still lacks big.LITTLE support. > >>>> > >>>> In the uncommon case of a system where the cacheline sizes are > >>>> different across cores, it disables all cores that have a > >>>> different dcache line size from the boot cpu. In fact, it is not > >>>> sufficient to use the dcache line size of the current cpu, it > >>>> would be necessary to use the minimum across all dcache line sizes > >>>> of all cores. Given that it is actually uncommon even in > >>>> big.LITTLE systems, just disable cpus > >> for now. > >>>> > >>>> The first patch in the series is a fix for the way we read the > >>>> dcache line size. > >>> > >>> I am trying the patchset, but I meet issue that Guest Big/Little > >>> with vcpu not working properly. As my current hardware has an issue > >>> which has fix in Kernel, > >>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs > >>> ou > >>> > >> > rce.codeaurora.org%2Fexternal%2Fimx%2Flinux-imx%2Fcommit%2F%3Fh%3Di > >> mx_ > >>> > >> > 4.9.51_imx8_beta2%26id%3D917cc3a8db2f3609ef8e2f59e7bcd31aa2cd4e59& > >> data > >>> > >> > =02%7C01%7Cpeng.fan%40nxp.com%7Cc7f074c6708647441f2b08d584e45fec > >> %7C686 > >>> > >> > ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636561038755176475 > >> =S%2BI > >>> 7g1BwUDgAnXGP8%2FFc1bVZZTIimd3J7%2FkTIdeWL4o%3D=0 > >> > >> Can you describe what you mean by not working properly? Also what is > >> your setup? Did you pin the different vCPUs as requested by the > documentation. > >> > > > > I may not describe clearly. It is domu with big/little guest could not > > bootup > correctly. > > What do you mean by "could not bootup correctly"? Can you please provide logs > or a bit more feedback. Without them, it is nearly impossible to me to help to > debugging the problem. > > > For dom0, the args are > > dom0_mem=2048M dom0_max_vcpus=6 dom0_vcpus_pin=true > hmp-unsafe=true > > > > For domu > > vcpus = 4 > > > > #vcpu pin > > cpus = ['2-3', '2-3', '4-5', '4-5'] > > > > The hardware is cpu0-3 is A53, cpu4-5 is A72. > > What does "xl vcpu-list" give you? # xl vcpu-list NameID VCPU CPU State Time(s) Affinity (Hard / Soft) Domain-0 0 00 r-- 7.4 0 / all Domain-0 0 11 -b- 9.4 1 / all Domain-0 0 22 -b- 2.2 2 / all Domain-0 0 33 -b- 2.6 3 / all Domain-0 0 44 -b- 2.1 4 / all Domain-0 0 55 -b- 3.3 5 / all DomU 1 02 -b- 9.6 2-3 / all DomU
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi,
On 08/03/18 12:23, Peng Fan wrote:
-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
Julien Grall
Sent: 2018年3月8日 19:04
To: Peng Fan <van.free...@gmail.com>; Stefano Stabellini
<sstabell...@kernel.org>
Cc: xen-de...@lists.xen.org
Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hello,
On 08/03/18 06:15, Peng Fan wrote:
Hi Stefano,
On Fri, Mar 02, 2018 at 11:05:54AM -0800, Stefano Stabellini wrote:
Hi all,
This series changes the initialization of two virtual registers to
make sure they match the value of the underlying physical cpu.
It also disables cpus different from the boot cpu, unless a newly
introduced command line option is specified. In that case, it
explains how to setup the system to avoid corruptions, which involves
manually specifying the cpu affinity of all domains, because the
scheduler still lacks big.LITTLE support.
In the uncommon case of a system where the cacheline sizes are
different across cores, it disables all cores that have a different
dcache line size from the boot cpu. In fact, it is not sufficient to
use the dcache line size of the current cpu, it would be necessary to
use the minimum across all dcache line sizes of all cores. Given
that it is actually uncommon even in big.LITTLE systems, just disable cpus
for now.
The first patch in the series is a fix for the way we read the dcache
line size.
I am trying the patchset, but I meet issue that Guest Big/Little with
vcpu not working properly. As my current hardware has an issue which
has fix in Kernel,
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsou
rce.codeaurora.org%2Fexternal%2Fimx%2Flinux-imx%2Fcommit%2F%3Fh%3Di
mx_
4.9.51_imx8_beta2%26id%3D917cc3a8db2f3609ef8e2f59e7bcd31aa2cd4e59&
data
=02%7C01%7Cpeng.fan%40nxp.com%7Cc7f074c6708647441f2b08d584e45fec
%7C686
ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636561038755176475
=S%2BI
7g1BwUDgAnXGP8%2FFc1bVZZTIimd3J7%2FkTIdeWL4o%3D=0
Can you describe what you mean by not working properly? Also what is your
setup? Did you pin the different vCPUs as requested by the documentation.
I may not describe clearly. It is domu with big/little guest could not bootup
correctly.
What do you mean by "could not bootup correctly"? Can you please provide
logs or a bit more feedback. Without them, it is nearly impossible to me
to help to debugging the problem.
For dom0, the args are
dom0_mem=2048M dom0_max_vcpus=6 dom0_vcpus_pin=true hmp-unsafe=true
For domu
vcpus = 4
#vcpu pin
cpus = ['2-3', '2-3', '4-5', '4-5']
The hardware is cpu0-3 is A53, cpu4-5 is A72.
What does "xl vcpu-list" give you?
I do not met issue for dom0.
I am not sure whether this issue cause DomU big/Little not work.
Well, I would recommend to speak with NXP whether this errata affects TLB
flush for Hypervisor Page-Table or Stage-2 Page-Table.
I tried the following, but no help. Not sure my patch is correct. I think it
affects stage2 TLB.
--- a/xen/include/asm-arm/arm64/flushtlb.h
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -6,7 +6,7 @@ static inline void flush_tlb_local(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1;"
+"tlbi alle1;"
"dsb sy;"
"isb;"
: : : "memory");
@@ -17,7 +17,7 @@ static inline void flush_tlb(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1is;"
+"tlbi alle1;"
I am not sure why you drop the innershareable here?
"dsb sy;"
"isb;"
: : : "memory");
@@ -39,7 +39,7 @@ static inline void flush_tlb_all(void)
{
asm volatile(
"dsb sy;"
-"tlbi alle1is;"
+"tlbi alle1;"
Ditto.
"dsb sy;"
"isb;"
: : : "memory");
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -74,14 +74,16 @@ static inline void flush_xen_data_tlb_local(void)
/* Flush TLB of local processor for address va. */
static inline void __flush_xen_data_tlb_one_local(vaddr_t va)
{
-asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
+//asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
}
/* Flush TLB of all processors in the inner-shareable domain for
* address va. */
static inline void __flush_xen_data_tlb_one(vaddr_t va)
{
-asm volatile("tlbi vae2is, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
Why do you replace an innershareable call to a local call? Is it part of
the errata?
+//asm volatile("tlbi vae2is,
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Julien Grall
> Sent: 2018年3月8日 19:04
> To: Peng Fan <van.free...@gmail.com>; Stefano Stabellini
> <sstabell...@kernel.org>
> Cc: xen-de...@lists.xen.org
> Subject: Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
>
> Hello,
>
> On 08/03/18 06:15, Peng Fan wrote:
> > Hi Stefano,
> > On Fri, Mar 02, 2018 at 11:05:54AM -0800, Stefano Stabellini wrote:
> >> Hi all,
> >>
> >> This series changes the initialization of two virtual registers to
> >> make sure they match the value of the underlying physical cpu.
> >>
> >> It also disables cpus different from the boot cpu, unless a newly
> >> introduced command line option is specified. In that case, it
> >> explains how to setup the system to avoid corruptions, which involves
> >> manually specifying the cpu affinity of all domains, because the
> >> scheduler still lacks big.LITTLE support.
> >>
> >> In the uncommon case of a system where the cacheline sizes are
> >>different across cores, it disables all cores that have a different
> >>dcache line size from the boot cpu. In fact, it is not sufficient to
> >>use the dcache line size of the current cpu, it would be necessary to
> >>use the minimum across all dcache line sizes of all cores. Given
> >>that it is actually uncommon even in big.LITTLE systems, just disable cpus
> for now.
> >>
> >> The first patch in the series is a fix for the way we read the dcache
> >> line size.
> >
> > I am trying the patchset, but I meet issue that Guest Big/Little with
> > vcpu not working properly. As my current hardware has an issue which
> > has fix in Kernel,
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsou
> >
> rce.codeaurora.org%2Fexternal%2Fimx%2Flinux-imx%2Fcommit%2F%3Fh%3Di
> mx_
> >
> 4.9.51_imx8_beta2%26id%3D917cc3a8db2f3609ef8e2f59e7bcd31aa2cd4e59&
> data
> >
> =02%7C01%7Cpeng.fan%40nxp.com%7Cc7f074c6708647441f2b08d584e45fec
> %7C686
> >
> ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636561038755176475
> =S%2BI
> > 7g1BwUDgAnXGP8%2FFc1bVZZTIimd3J7%2FkTIdeWL4o%3D=0
>
> Can you describe what you mean by not working properly? Also what is your
> setup? Did you pin the different vCPUs as requested by the documentation.
>
I may not describe clearly. It is domu with big/little guest could not bootup
correctly.
For dom0, the args are
dom0_mem=2048M dom0_max_vcpus=6 dom0_vcpus_pin=true hmp-unsafe=true
For domu
vcpus = 4
#vcpu pin
cpus = ['2-3', '2-3', '4-5', '4-5']
The hardware is cpu0-3 is A53, cpu4-5 is A72.
I do not met issue for dom0.
> >
> > I am not sure whether this issue cause DomU big/Little not work.
>
> Well, I would recommend to speak with NXP whether this errata affects TLB
> flush for Hypervisor Page-Table or Stage-2 Page-Table.
I tried the following, but no help. Not sure my patch is correct. I think it
affects stage2 TLB.
--- a/xen/include/asm-arm/arm64/flushtlb.h
+++ b/xen/include/asm-arm/arm64/flushtlb.h
@@ -6,7 +6,7 @@ static inline void flush_tlb_local(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1;"
+"tlbi alle1;"
"dsb sy;"
"isb;"
: : : "memory");
@@ -17,7 +17,7 @@ static inline void flush_tlb(void)
{
asm volatile(
"dsb sy;"
-"tlbi vmalls12e1is;"
+"tlbi alle1;"
"dsb sy;"
"isb;"
: : : "memory");
@@ -39,7 +39,7 @@ static inline void flush_tlb_all(void)
{
asm volatile(
"dsb sy;"
-"tlbi alle1is;"
+"tlbi alle1;"
"dsb sy;"
"isb;"
: : : "memory");
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -74,14 +74,16 @@ static inline void flush_xen_data_tlb_local(void)
/* Flush TLB of local processor for address va. */
static inline void __flush_xen_data_tlb_one_local(vaddr_t va)
{
-asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_tlb_local();
+//asm volatile("tlbi vae2, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
}
/* Flush TLB of all processors in the inner-shareable domain for
* address va. */
static inline void __flush_xen_data_tlb_one(vaddr_t va)
{
-asm volatile("tlbi vae2is, %0;" : : "r" (va>>PAGE_SHIFT) : "memory");
+ flush_xen_data_
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hello, On 08/03/18 06:15, Peng Fan wrote: Hi Stefano, On Fri, Mar 02, 2018 at 11:05:54AM -0800, Stefano Stabellini wrote: Hi all, This series changes the initialization of two virtual registers to make sure they match the value of the underlying physical cpu. It also disables cpus different from the boot cpu, unless a newly introduced command line option is specified. In that case, it explains how to setup the system to avoid corruptions, which involves manually specifying the cpu affinity of all domains, because the scheduler still lacks big.LITTLE support. In the uncommon case of a system where the cacheline sizes are different across cores, it disables all cores that have a different dcache line size from the boot cpu. In fact, it is not sufficient to use the dcache line size of the current cpu, it would be necessary to use the minimum across all dcache line sizes of all cores. Given that it is actually uncommon even in big.LITTLE systems, just disable cpus for now. The first patch in the series is a fix for the way we read the dcache line size. I am trying the patchset, but I meet issue that Guest Big/Little with vcpu not working properly. As my current hardware has an issue which has fix in Kernel, https://source.codeaurora.org/external/imx/linux-imx/commit/?h=imx_4.9.51_imx8_beta2=917cc3a8db2f3609ef8e2f59e7bcd31aa2cd4e59 Can you describe what you mean by not working properly? Also what is your setup? Did you pin the different vCPUs as requested by the documentation. I am not sure whether this issue cause DomU big/Little not work. Well, I would recommend to speak with NXP whether this errata affects TLB flush for Hypervisor Page-Table or Stage-2 Page-Table. So wonder has this patchset been tested on Big/Little Hardware? This series only adds facility to report the correct MIDR to the guest. If your platform requires more, then it would be necessary send a patch for Xen. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi Stefano, On Fri, Mar 02, 2018 at 11:05:54AM -0800, Stefano Stabellini wrote: >Hi all, > >This series changes the initialization of two virtual registers to make >sure they match the value of the underlying physical cpu. > >It also disables cpus different from the boot cpu, unless a newly >introduced command line option is specified. In that case, it explains >how to setup the system to avoid corruptions, which involves manually >specifying the cpu affinity of all domains, because the scheduler still >lacks big.LITTLE support. > >In the uncommon case of a system where the cacheline sizes are different >across cores, it disables all cores that have a different dcache line size >from the boot cpu. In fact, it is not sufficient to use the dcache line >size of the current cpu, it would be necessary to use the minimum across >all dcache line sizes of all cores. Given that it is actually uncommon >even in big.LITTLE systems, just disable cpus for now. > >The first patch in the series is a fix for the way we read the dcache >line size. I am trying the patchset, but I meet issue that Guest Big/Little with vcpu not working properly. As my current hardware has an issue which has fix in Kernel, https://source.codeaurora.org/external/imx/linux-imx/commit/?h=imx_4.9.51_imx8_beta2=917cc3a8db2f3609ef8e2f59e7bcd31aa2cd4e59 I am not sure whether this issue cause DomU big/Little not work. So wonder has this patchset been tested on Big/Little Hardware? Thanks, Peng. > >Cheers, > >Stefano > > >Julien Grall (1): > xen/arm: Park CPUs with a MIDR different from the boot CPU. > >Stefano Stabellini (6): > xen/arm: Read the dcache line size from CTR register > xen/arm: make processor a per cpu variable > xen/arm: read ACTLR on the pcpu where the vcpu will run > xen/arm: set VPIDR based on the MIDR value of the underlying pCPU > xen/arm: update the docs about heterogeneous computing > xen/arm: disable CPUs with different dcache line sizes > > docs/misc/arm/big.LITTLE.txt| 46 + > docs/misc/xen-command-line.markdown | 15 > xen/arch/arm/arm32/head.S | 2 +- > xen/arch/arm/arm64/head.S | 2 +- > xen/arch/arm/domain.c | 15 ++-- > xen/arch/arm/processor.c| 8 +++ > xen/arch/arm/setup.c| 17 ++ > xen/arch/arm/smpboot.c | 39 +++ > xen/arch/arm/vcpreg.c | 4 ++-- > xen/include/asm-arm/cpregs.h| 2 ++ > xen/include/asm-arm/domain.h| 3 --- > xen/include/asm-arm/page.h | 27 +++--- > 12 files changed, 138 insertions(+), 42 deletions(-) > create mode 100644 docs/misc/arm/big.LITTLE.txt > >___ >Xen-devel mailing list >Xen-devel@lists.xenproject.org >https://lists.xenproject.org/mailman/listinfo/xen-devel -- ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v4 0/7] unsafe big.LITTLE support
Hi all, This series changes the initialization of two virtual registers to make sure they match the value of the underlying physical cpu. It also disables cpus different from the boot cpu, unless a newly introduced command line option is specified. In that case, it explains how to setup the system to avoid corruptions, which involves manually specifying the cpu affinity of all domains, because the scheduler still lacks big.LITTLE support. In the uncommon case of a system where the cacheline sizes are different across cores, it disables all cores that have a different dcache line size from the boot cpu. In fact, it is not sufficient to use the dcache line size of the current cpu, it would be necessary to use the minimum across all dcache line sizes of all cores. Given that it is actually uncommon even in big.LITTLE systems, just disable cpus for now. The first patch in the series is a fix for the way we read the dcache line size. Cheers, Stefano Julien Grall (1): xen/arm: Park CPUs with a MIDR different from the boot CPU. Stefano Stabellini (6): xen/arm: Read the dcache line size from CTR register xen/arm: make processor a per cpu variable xen/arm: read ACTLR on the pcpu where the vcpu will run xen/arm: set VPIDR based on the MIDR value of the underlying pCPU xen/arm: update the docs about heterogeneous computing xen/arm: disable CPUs with different dcache line sizes docs/misc/arm/big.LITTLE.txt| 46 + docs/misc/xen-command-line.markdown | 15 xen/arch/arm/arm32/head.S | 2 +- xen/arch/arm/arm64/head.S | 2 +- xen/arch/arm/domain.c | 15 ++-- xen/arch/arm/processor.c| 8 +++ xen/arch/arm/setup.c| 17 ++ xen/arch/arm/smpboot.c | 39 +++ xen/arch/arm/vcpreg.c | 4 ++-- xen/include/asm-arm/cpregs.h| 2 ++ xen/include/asm-arm/domain.h| 3 --- xen/include/asm-arm/page.h | 27 +++--- 12 files changed, 138 insertions(+), 42 deletions(-) create mode 100644 docs/misc/arm/big.LITTLE.txt ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
