qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 08/11] linux-user: Check for cpu_init() errors


From: Peter Maydell
Subject: Re: [Qemu-devel] [PULL 08/11] linux-user: Check for cpu_init() errors
Date: Fri, 27 Feb 2015 08:23:12 +0900

On 27 February 2015 at 08:11, Eduardo Habkost <address@hidden> wrote:
> On Fri, Feb 27, 2015 at 08:00:25AM +0900, Peter Maydell wrote:
>> On 27 February 2015 at 07:51, Eduardo Habkost <address@hidden> wrote:
>> > I have never seen it in practice, but in x86 it will fail if we try to
>> > create more than 254 VCPUs.
>>
>> That's bad -- it's not hard to imagine a program with 256
>> threads. Why does x86 have this limitation and can we fix it?
>> That seems like the better course than this patch.
>
> I don't think *-user or any x86-specific code has any hard requirement
> of having all VCPUs with different APIC IDs. But right now we set APIC
> ID = cpu_index for every VCPU, so the current code has this limitation.

But the -user code doesn't have an APIC at all, so it shouldn't
have to live with this limitation.

> I would be glad to send a patch adding an assert() instead of an error
> message, but I don't think I will be able to audit every single
> cpu_init() function soon (to ensure they really never fail).
>
> So, while we don't audit all cpu_init() functions, do you prefer to live
> with an error message, or an assert() that may or may not be triggered
> by existing code?

I would prefer:
 (1) that we fix the error handling properly so you return an error
     indication from cpu_copy() and we propagate it back to the guest
 (2) that we fix x86-64 so it can create more than 254 CPUs for usermode

I would rather not paper over this by adding a "let qemu assert or
fatally exit on a recoverable error condition" code path we'd just
have to revert when we fixed (1) properly.

(2) is not really important to deal with right now, since we don't
actually support multiple threads yet. But it would be nice eventually.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]