* Peter Maydell (peter.mayd...@linaro.org) wrote:
> On 21 May 2015 at 12:09, Markus Armbruster wrote:
> > Kevin Wolf writes:
> >
> >> Am 21.05.2015 um 12:11 hat Peter Maydell geschrieben:
> >>> 2b add a subsection, send the subsection always in new qemu,
> >>> if receiving from an old qemu then c
On 21 May 2015 at 12:09, Markus Armbruster wrote:
> Kevin Wolf writes:
>
>> Am 21.05.2015 um 12:11 hat Peter Maydell geschrieben:
>>> 2b add a subsection, send the subsection always in new qemu,
>>> if receiving from an old qemu then calculate the phase from
>>> the register fields in post-load
>
Kevin Wolf writes:
> Am 21.05.2015 um 12:11 hat Peter Maydell geschrieben:
>> On 21 May 2015 at 10:42, Kevin Wolf wrote:
>> > Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
>> >> On 20 May 2015 at 12:55, John Snow wrote:
>> >> > So even if /currently/ we can reconstitute it from the regi
Am 21.05.2015 um 12:11 hat Peter Maydell geschrieben:
> On 21 May 2015 at 10:42, Kevin Wolf wrote:
> > Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
> >> On 20 May 2015 at 12:55, John Snow wrote:
> >> > So even if /currently/ we can reconstitute it from the register values,
> >> > we may
On 21 May 2015 at 10:42, Kevin Wolf wrote:
> Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
>> On 20 May 2015 at 12:55, John Snow wrote:
>> > So even if /currently/ we can reconstitute it from the register values,
>> > we may eventually be unable to.
>> >
>> > post_load will work for now,
* Kevin Wolf (kw...@redhat.com) wrote:
> Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
> > On 20 May 2015 at 12:55, John Snow wrote:
> > > So even if /currently/ we can reconstitute it from the register values,
> > > we may eventually be unable to.
> > >
> > > post_load will work for now,
Am 20.05.2015 um 14:07 hat Peter Maydell geschrieben:
> On 20 May 2015 at 12:55, John Snow wrote:
> > So even if /currently/ we can reconstitute it from the register values,
> > we may eventually be unable to.
> >
> > post_load will work for now, but I fear the case (in ten years) when
> > someone
On 20 May 2015 at 12:55, John Snow wrote:
> So even if /currently/ we can reconstitute it from the register values,
> we may eventually be unable to.
>
> post_load will work for now, but I fear the case (in ten years) when
> someone else cleans up FDC code but fails to realize that the phase is
>
On 05/20/2015 05:24 AM, Peter Maydell wrote:
> On 20 May 2015 at 09:43, Kevin Wolf wrote:
>> Am 20.05.2015 um 10:06 hat Peter Maydell geschrieben:
>>> That handles migration, which is good. But I still think that
>>> storing the same information in two places in the device
>>> state (phase field
On 20 May 2015 at 09:43, Kevin Wolf wrote:
> Am 20.05.2015 um 10:06 hat Peter Maydell geschrieben:
>> That handles migration, which is good. But I still think that
>> storing the same information in two places in the device
>> state (phase field and the register fields) is error-prone.
>
> That's
Am 20.05.2015 um 10:06 hat Peter Maydell geschrieben:
> On 20 May 2015 at 08:54, Kevin Wolf wrote:
> > Am 19.05.2015 um 22:57 hat Peter Maydell geschrieben:
> >> Yeah, if there's genuinely an underlying state machine that's
> >> not completely visible in registers you need to actually model it.
>
On 20 May 2015 at 08:54, Kevin Wolf wrote:
> Am 19.05.2015 um 22:57 hat Peter Maydell geschrieben:
>> Yeah, if there's genuinely an underlying state machine that's
>> not completely visible in registers you need to actually model it.
>> You should probably then model the register bits by calculati
Am 19.05.2015 um 22:57 hat Peter Maydell geschrieben:
> On 19 May 2015 at 21:52, John Snow wrote:
> > Hmm, I think this is not purely derived state because the flags are not
> > necessarily sufficient for regenerating that state.
>
> Yeah, if there's genuinely an underlying state machine that's
>
On 19 May 2015 at 21:52, John Snow wrote:
> Hmm, I think this is not purely derived state because the flags are not
> necessarily sufficient for regenerating that state.
Yeah, if there's genuinely an underlying state machine that's
not completely visible in registers you need to actually model it
On 05/19/2015 04:44 PM, Peter Maydell wrote:
> On 19 May 2015 at 16:35, Kevin Wolf wrote:
>> The floppy controller spec describes three different controller phases,
>> which are currently not explicitly modelled in our emulation. Instead,
>> each phase is represented by a combination of flags in
On 19 May 2015 at 16:35, Kevin Wolf wrote:
> The floppy controller spec describes three different controller phases,
> which are currently not explicitly modelled in our emulation. Instead,
> each phase is represented by a combination of flags in registers.
>
> This patch makes explicit in which p
On 05/19/2015 11:35 AM, Kevin Wolf wrote:
> The floppy controller spec describes three different controller phases,
> which are currently not explicitly modelled in our emulation. Instead,
> each phase is represented by a combination of flags in registers.
>
> This patch makes explicit in which
The floppy controller spec describes three different controller phases,
which are currently not explicitly modelled in our emulation. Instead,
each phase is represented by a combination of flags in registers.
This patch makes explicit in which phase the controller currently is.
Signed-off-by: Kev
18 matches
Mail list logo
