On 2012-09-03 17:57, Avi Kivity wrote:
> On 09/03/2012 06:54 PM, Jan Kiszka wrote:
>> On 2012-09-03 17:52, Avi Kivity wrote:
>>> On 09/03/2012 06:42 PM, Juan Quintela wrote:
>>>> Avi Kivity <a...@redhat.com> wrote:
>>>>> On 09/03/2012 11:40 AM, Andreas Färber wrote:
>>>>>> Am 03.09.2012 04:56, schrieb Matthew Ogilvie:
>>>>>>> diff --git a/hw/i8259_common.c b/hw/i8259_common.c
>>>>>>> index ab3d98b..dcde5f2 100644
>>>>>>> --- a/hw/i8259_common.c
>>>>>>> +++ b/hw/i8259_common.c
>>>>>> [...]
>>>>>>> @@ -111,6 +112,7 @@ static const VMStateDescription vmstate_pic_common
>>>>>>> = {
>>>>>>> VMSTATE_UINT8(isr, PICCommonState),
>>>>>>> VMSTATE_UINT8(priority_add, PICCommonState),
>>>>>>> VMSTATE_UINT8(irq_base, PICCommonState),
>>>>>>> + VMSTATE_UINT8(icw3, PICCommonState),
>>>>>>> VMSTATE_UINT8(read_reg_select, PICCommonState),
>>>>>>> VMSTATE_UINT8(poll, PICCommonState),
>>>>>>> VMSTATE_UINT8(special_mask, PICCommonState),
>>>>>>
>>>>>> Additional VMState needs to be versioned by incrementing .version_id and
>>>>>> by specifying the new version number here. Otherwise it breaks migration.
>>>>
>>>> For the subsection, only sending this when icw3 != 0 is enough? I am
>>>> searching for a test about when we need to send it.
>>>
>>> Looks like the optimal condition is ((s->icw3 & ~s->eclr) != 0) (i.e.
>>> bit set in icw3 but clear in eclr).
>>
>> The standard PC values are optimal: 4 for master, 2 for slave.
>
> Can you explain why? I saw that icw3 is always ORed with eclr, so my
> condition will catch exactly those cases where a change in behaviour
> occurs, and no more.
The values above are what every user of the PIC cascaded on our targets
must program to use them. So We will find them in the state once any
relevant guest code was able to run (e.g. the BIOS).
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
