Re: [Xen-devel] [RFC v2] ARM VM System Specification

[Paolo Bonzini <pbonzini@xxxxxxxxxx>]

Il 10/06/2014 20:56, Paolo Bonzini ha scritto:
> Il 10/06/2014 20:08, Peter Maydell ha scritto:
> > On 10 June 2014 18:04, Christopher Covington <cov@xxxxxxxxxxxxxx> wrote:
> > > On 06/10/2014 10:42 AM, Peter Maydell wrote:
> > > > I just noticed that this doesn't mandate that the platform
> > > > provides an RTC. As I understand it, the UEFI spec mandates
> > > > that there's an RTC (could somebody more familiar with UEFI
> > > > than me confirm/deny that?) so we should probably put one here.
> > > Pardon my ignorance, but what exactly disqualifies Generic Timer
> > > implementations from being used as Real Time Clocks?
> > So my naive view was that an RTC actually had to have
> > support for dealing with real (wall) clock time, ie
> > knowing it's 2014 and not 1970. The generic timers are
> > just timers. Or am I wrong and UEFI doesn't really
> > require that?
> The real-time clock provides four UEFI runtime services (GetTime,
> SetTime, GetWakeupTime, SetWakeupTime).  The spec says that you can
> return EFI_DEVICE_ERROR from GetTime/SetTime if "the time could not be
> retrieved/set due to a hardware error", but I don't think this is enough
> to make these two optional.  By comparison, GetWakeupTime/SetWakeupTime
> can also return EFI_UNSUPPORTED.
>
> So I agree that the RTC is required in UEFI.
... that said, just like I thought was the case for the serial console, 
do we need to specify the exact hardware models?
We can just say that the VM can expect UEFI boot and runtime services to 
work.  This includes variable services, time services, the serial 
console protocols and more.  It's up to the implementation to provide 
enough devices to support the firmware, and it's out of this spec's 
scope to specify the firmware's implementation.
Paolo

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel