Hi Peter,
On 9/12/19 11:00 AM, Peter Maydell wrote:
> On Thu, 12 Sep 2019 at 09:57, Auger Eric wrote:
>>
>> Hi Peter,
>> On 9/12/19 10:42 AM, Peter Maydell wrote:
>
>>> Is there really no place to put this check in common code?
>
>> Not sure what you mean by common code here? Do you mean in a co
On Thu, 12 Sep 2019 at 09:57, Auger Eric wrote:
>
> Hi Peter,
> On 9/12/19 10:42 AM, Peter Maydell wrote:
> > Is there really no place to put this check in common code?
> Not sure what you mean by common code here? Do you mean in a common code
> for ARM machines (I don't think we have any atm) o
Hi Peter,
On 9/12/19 10:42 AM, Peter Maydell wrote:
> On Wed, 11 Sep 2019 at 16:51, Eric Auger wrote:
>>
>> Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
>> for ARM. The actual capability to instantiate more than 256 vcpus
>> was fixed in 5.4 with the upgrade of the KVM_IRQ_
On Wed, 11 Sep 2019 at 16:51, Eric Auger wrote:
>
> Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
> for ARM. The actual capability to instantiate more than 256 vcpus
> was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
> vcpu id encoded on 12 bits instead o
On Wed, Sep 11, 2019 at 05:51:25PM +0200, Eric Auger wrote:
> Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
> for ARM. The actual capability to instantiate more than 256 vcpus
> was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
> vcpu id encoded on 12 bits
Host kernel within [4.18, 5.3] report an erroneous KVM_MAX_VCPUS=512
for ARM. The actual capability to instantiate more than 256 vcpus
was fixed in 5.4 with the upgrade of the KVM_IRQ_LINE ABI to support
vcpu id encoded on 12 bits instead of 8 and a redistributor consuming
a single KVM IO device in
