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

Re: [Xen-devel] [PATCH 4/5] x86/PV: remove the emulated PIT

El 14/01/16 a les 13.38, Jan Beulich ha escrit:
>>>> On 14.01.16 at 11:59, <roger.pau@xxxxxxxxxx> wrote:
>> El 14/01/16 a les 10.11, Jan Beulich ha escrit:
>>>>>> On 14.01.16 at 09:25, <roger.pau@xxxxxxxxxx> wrote:
>>>> El 13/01/16 a les 17.36, Jan Beulich ha escrit:
>>>>>>>> On 13.01.16 at 13:32, <roger.pau@xxxxxxxxxx> wrote:
>>>>>> The HVMlite series removed the initialization of the emulated PIT for PV
>>>>>> guests, but the handler was still reachable, which means a PV guests can
>>>>>> crash Xen if it pokes at IO ports 0x42, 0x43 or 0x61. Completely remove 
>>>>>> the
>>>>>> PV PIT handler and move the PIT initialization to HVM guests only.
>>>>> As said on IRC - this is needed for Dom0 to be able to drive the
>>>>> PC speaker. You'll need to provide a fix for the suppressed
>>>>> initialization instead, at least for Dom0. (As an aside, your patch
>>>>> orphans hwdom_pit_access().)
>>>> Thanks for the clarification. AFAICT I can leave the usage of
>>>> hwdom_pit_access for Dom0, and completely remove PIT access for DomU, is
>>>> that right?
>>> I don't think so - see the explanation Tim gave on IRC. Afaict the
>>> mention of BIOS here isn't related to a virtual BIOS, but to that
>>> of a passed through graphics card.
>> I'm sorry but I still don't fully understand why that's needed, and it
>> arises a couple of questions. First of all, the only reference that I
>> can find about BIOS and i8254 usage is regarding VGA BIOS POST [0],
>> where they mention that the VGA POST method might make use of the i8254.
>> This seems reasonable, but I still don't understand why we provide an
>> emulated i8254 to DomUs. They don't have access to the low 1MB, which is
>> where the VGA BIOS resides, so there's no way they can call into the VGA
>> POST at all.
> All of this arrangement predates me, but see the original change
> introducing this: "Provide PV guests with emulated PIT", which
> suggests this wasn't just for Dom0. I'm hesitant to accept removal
> of code when we don't know exactly by whom and for what purpose
> it might be used. When I enabled Dom0 speaker control, I
> intentionally retained the original code for DomU purposes.

What about we do the following: enable the PIT for PV(H) guests
(DomU/Dom0), and completely remove it for HVMlite guests for the moment?

We might consider enabling it for HVMlite, but the plan is that this
could be done on a per-domain basis using the flags in the
xen_arch_domainconfig struct.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.