Tim/Keir, thanks for your save/restore clean up. i still have concerns about following changeset: 13527 -- [HVM] Save/restore cleanups 01: PIT Define public structure for the saved PIT data and use it instead of a series of explicit loads and stores. if i''m right, all hw status are organized into a single & aligned struct for save/restore. it''s clean and simple solution, but 1. it put more responsibility on developer to maintain the format/alignment of hw status struct. 2. compatibility issue. e.g. adding a new field in middle of the hw struct would break restoring an old image. if handling save/restore at fields granularity, we are likely to successfully restore it with only issue of this field. end user would be really frustrated if saved image on 3.0.4 can''t be restored on 3.0.5:-( any ideas for this? thanks, -- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22/1/07 2:44 am, "Zhai, Edwin" <edwin.zhai@intel.com> wrote:> 1. it put more responsibility on developer to maintain the format/alignment of > hw status struct.This is true. We now have anough script support for CONFIG_COMPAT that we could probably check all save structs for 32-on-64 compatibility automatically.> 2. compatibility issue. e.g. adding a new field in middle of the hw struct > would break restoring an old image.We wouldn''t do this -- we''d define a new structure, or add new fields at the end in a backward compatible way. The code as it is is *not* finished by the way, and so gives a slightly poor impression of this approach. The aim is to have some of the structures broken down into more chunks: so for example the hvm_irq structure will move back to where it came from (a private header file) and instead we will have descriptor chunks for PCI INTx wire state, ISA IRQ wire state, and PCI-ISA link state -- note that each of these will effectively be an array which will be easily extended (or shrunk) if e.g., we add another PCI bus. This is the hard bit -- auditing every chunk, deciding if it contains redundant info, or info that is only an artefact of the crrent device-model implementation, or whether the chunk needs to be broken into more pieces to maintain better logical grouping and extensibility. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
now, it''s clear for me. thanks, On Mon, Jan 22, 2007 at 08:46:37AM +0000, Keir Fraser wrote:> On 22/1/07 2:44 am, "Zhai, Edwin" <edwin.zhai@intel.com> wrote: > > > 1. it put more responsibility on developer to maintain the format/alignment of > > hw status struct. > > This is true. We now have anough script support for CONFIG_COMPAT that we > could probably check all save structs for 32-on-64 compatibility > automatically. > > > 2. compatibility issue. e.g. adding a new field in middle of the hw struct > > would break restoring an old image. > > We wouldn''t do this -- we''d define a new structure, or add new fields at the > end in a backward compatible way. > > The code as it is is *not* finished by the way, and so gives a slightly poor > impression of this approach. The aim is to have some of the structures > broken down into more chunks: so for example the hvm_irq structure will move > back to where it came from (a private header file) and instead we will have > descriptor chunks for PCI INTx wire state, ISA IRQ wire state, and PCI-ISA > link state -- note that each of these will effectively be an array which > will be easily extended (or shrunk) if e.g., we add another PCI bus. > > This is the hard bit -- auditing every chunk, deciding if it contains > redundant info, or info that is only an artefact of the crrent device-model > implementation, or whether the chunk needs to be broken into more pieces to > maintain better logical grouping and extensibility. > > -- Keir >-- best rgds, edwin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel