On Mon, Mar 09, 2015 at 09:28:05PM +0900, Peter Maydell wrote:
> On 9 March 2015 at 21:12, Leif Lindholm wrote:
> > Sorry for being late to the party, missed this set when it went out.
>
> You seem to be replying to an email thread which is now many
> months old and at a part of the conversation
On 2015/3/9 20:28, Peter Maydell wrote:
> On 9 March 2015 at 21:12, Leif Lindholm wrote:
>> > Sorry for being late to the party, missed this set when it went out.
> You seem to be replying to an email thread which is now many
> months old and at a part of the conversation which was obsoleted
> by
On 9 March 2015 at 21:12, Leif Lindholm wrote:
> Sorry for being late to the party, missed this set when it went out.
You seem to be replying to an email thread which is now many
months old and at a part of the conversation which was obsoleted
by the subsequent discussion in this thread...
Summa
Sorry for being late to the party, missed this set when it went out.
On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote:
> On 30 October 2014 17:43, Alexander Spyridakis
> wrote:
> > Currently, the virt machine model generates Device Tree information
> > dynamically based on the exist
On 13 November 2014 09:57, Claudio Fontana wrote:
> I agree with you that as a result of this discussion, the solution for QEMU
> upstreaming purposes needs to take everything discussed (possibly more)
> into account.
(Picking this email as a reasonable if slightly arbitrary
place to try to summa
On Do, 2014-11-13 at 11:16 -0700, Al Stone wrote:
> On 11/13/2014 01:10 AM, Gerd Hoffmann wrote:
> > Hi,
> >
> >> My understanding from an IRC conversation yesterday was that at
> >> least some of these ACPI blobs contain data which has to be constructed
> >> at the point it is requested (ie is
On 11/13/2014 01:10 AM, Gerd Hoffmann wrote:
> Hi,
>
>> My understanding from an IRC conversation yesterday was that at
>> least some of these ACPI blobs contain data which has to be constructed
>> at the point it is requested (ie is not fixed at the point when
>> QEMU starts up), because OVMF w
On 13/11/2014 19:16, Al Stone wrote:
>> > [root@fedora ~]# cat /proc/ioports
>> > [ ... ]
>> > 0600-063f : :00:01.3
>> > 0600-0603 : ACPI PM1a_EVT_BLK
>> > 0604-0605 : ACPI PM1a_CNT_BLK
>> > 0608-060b : ACPI PM_TMR
>> > 0700-070f : :00:01.3
>> > 0700-0707 : piix4_smbu
On 12.11.2014 19:10, Peter Maydell wrote:
> On 12 November 2014 09:08, Claudio Fontana wrote:
>> As mentioned by others, I'd rather see an implementation of ACPI in QEMU
>> which
>> learns from the experience of X86 (and possibly shares some code if
>> possible),
>> rather than going in a differ
Hi,
> The PowerPC folks are using u-boot as the firmware. I know Peter
> disagrees, but I don't understand why so I'll throw this up for
> discussion too; it is definitely lighter-weight than UEFI. Would that
> make sense for ARM?
Played around with that. Look here:
https://www.kraxel.org/c
On Mi, 2014-11-12 at 16:01 +0100, Claudio Fontana wrote:
> I ask because on OSv at the moment, the situation is that for x86 we
> don't need to reprogram anything on PCI,
> as everything is already nicely set up by the time the guest starts,
> and thus the BAR addresses can be read directly.
> On A
Hi,
> My understanding from an IRC conversation yesterday was that at
> least some of these ACPI blobs contain data which has to be constructed
> at the point it is requested (ie is not fixed at the point when
> QEMU starts up), because OVMF will do:
> * startup
> * prod some parts of the hard
On 12 November 2014 09:08, Claudio Fontana wrote:
> As mentioned by others, I'd rather see an implementation of ACPI in QEMU which
> learns from the experience of X86 (and possibly shares some code if possible),
> rather than going in a different direction by creating device trees first,
> and the
On 12 November 2014 16:25, Paolo Bonzini wrote:
> On 12/11/2014 17:13, Arnd Bergmann wrote:
>> > Same as real hardware. Firmware (SeaBIOS or OVMF) builds the memory
>> > map, decides where in the free space the BARs go, and programs the PCI
>> > devices accordingly.
>> >
>> > kvmtool is the speci
On 12/11/2014 17:13, Arnd Bergmann wrote:
> > Same as real hardware. Firmware (SeaBIOS or OVMF) builds the memory
> > map, decides where in the free space the BARs go, and programs the PCI
> > devices accordingly.
> >
> > kvmtool is the special one here. Xen, VMware, Hyper-V all do the same
>
On Wednesday 12 November 2014 17:04:30 Paolo Bonzini wrote:
> On 12/11/2014 16:57, Arnd Bergmann wrote:
> > > > It seems to me like complicated stuff like that definitely belongs
> > > > in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> > > > the hardware and let the guest (or th
On 12/11/2014 16:57, Arnd Bergmann wrote:
> > > It seems to me like complicated stuff like that definitely belongs
> > > in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> > > the hardware and let the guest (or the firmware, which is guest
> > > code from QEMU's point of view) s
On Wednesday 12 November 2014 16:52:25 Paolo Bonzini wrote:
> On 12/11/2014 16:39, Peter Maydell wrote:
> > > Definitely, I think having the OS manually program the BARs only makes
> > > sense
> > > in an environment where you don't have a full-featured boot loader or you
> > > don't trust it. In
On 12/11/2014 16:39, Peter Maydell wrote:
> > Definitely, I think having the OS manually program the BARs only makes sense
> > in an environment where you don't have a full-featured boot loader or you
> > don't trust it. In servers and virtual machines, the PCI bus should always
> > come
> > ful
On 12 November 2014 15:32, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 16:01:14 Claudio Fontana wrote:
>> Would the last step you mention allow for guests to start with an already
>> existing PCI interrupt map
>> and the BAR registers preprogrammed to point to somewhere sane?
>>
>> I ask
On Wednesday 12 November 2014 16:01:14 Claudio Fontana wrote:
>
> Would the last step you mention allow for guests to start with an already
> existing PCI interrupt map
> and the BAR registers preprogrammed to point to somewhere sane?
>
> I ask because on OSv at the moment, the situation is that
On 12.11.2014 14:27, Peter Maydell wrote:
> On 12 November 2014 12:04, Mark Rutland wrote:
>> On Wed, Nov 12, 2014 at 11:52:22AM +, Paolo Bonzini wrote:
>>> SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
>>> On ARM you could use DT binary blobs instead of fw_cfg, as pro
On 12/11/2014 15:10, Mark Rutland wrote:
>>> We can't just pick-and-mix
>>> portions of ACPI and state that it's specified and standard.
>>
>> But that's what you already do if you want to build ACPI tables from DT.
>> You are already picking-and-mixing the variable portions of the ACPI
>> table
On Wed, Nov 12, 2014 at 01:59:30PM +, Paolo Bonzini wrote:
>
>
> On 12/11/2014 14:41, Mark Rutland wrote:
> > Writing a binding for the partiuclar device might be trivial. How this
> > would fit with the DT model is more complicated, and needs to be
> > specified. As far as I can see, those d
On 12/11/2014 14:41, Mark Rutland wrote:
> Writing a binding for the partiuclar device might be trivial. How this
> would fit with the DT model is more complicated, and needs to be
> specified. As far as I can see, those documents are quite strongly tied
> to x86 ACPI (they talk in terms of OSPM,
On Wed, Nov 12, 2014 at 11:07:22AM +, Mark Rutland wrote:
> [...]
>
> > > > > > We are currently suggesting adding an RDSP property to the chosen
> > > > > > node
> > > > > > in the tiny DT, but a command-line arguement like kexec proposed
> > > > > > could
> > > > > > be another option I gu
Hi,
On 12/11/2014 10:44, Christoffer Dall wrote:
I'm not a fan of placing fundamentally required system description on
the command line. It's fine for explicit overrides but I don't think it
should be the default mechanism as that causes its own set of problems
(who wants to fight with their hy
On Wed, Nov 12, 2014 at 12:27:14PM +, Paolo Bonzini wrote:
>
>
> On 12/11/2014 13:18, Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote:
> >>
> >> On 12/11/2014 12:34, Christoffer Dall wrote:
> >>> AFAIU ACPI already has a method for doing this
> >>
> >> It
On Wed, Nov 12, 2014 at 02:03:01PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 12:34:01 Christoffer Dall wrote:
> > On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> > > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > > >
> > > > For the features which
On 12/11/2014 14:27, Peter Maydell wrote:
> If somebody with more x86/ACPI knowledge could clarify what the
> dynamically-constructed parts of the tables are and whether
> they're likely to apply to use that would be good. I think they
> involved PCI in some way, but I don't have access to my irc
On 12/11/2014 14:08, Arnd Bergmann wrote:
>>> Putting an interrupt in DT is trivial. The hard part is the rest of the
>>> interface, which so far there is no specification for.
>>
>> Have you looked at docs/specs/acpi_{cpu,mem}_hotplug.txt? Writing a DT
>> binding for it is trivial too. Or are
On 12 November 2014 12:04, Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 11:52:22AM +, Paolo Bonzini wrote:
>> SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
>> On ARM you could use DT binary blobs instead of fw_cfg, as proposed
>> already (I don't remember if it was in
On Wednesday 12 November 2014 13:27:14 Paolo Bonzini wrote:
> On 12/11/2014 13:18, Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote:
> >> Perhaps you could treat it as a shared level-triggered interrupt in DT?
> >> I don't know.
> >
> > Putting an interrupt in
On Wednesday 12 November 2014 12:34:01 Christoffer Dall wrote:
> On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > >
> > > For the features which ACPI provides which device trees do not (e.g. the
> > > dynamic addition
On Wed, Nov 12, 2014 at 1:27 PM, Paolo Bonzini wrote:
>
>
> On 12/11/2014 13:18, Mark Rutland wrote:
>> On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote:
>>>
>>> On 12/11/2014 12:34, Christoffer Dall wrote:
AFAIU ACPI already has a method for doing this
>>>
>>> It's not defined i
On 12/11/2014 13:18, Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote:
>>
>> On 12/11/2014 12:34, Christoffer Dall wrote:
>>> AFAIU ACPI already has a method for doing this
>>
>> It's not defined in the spec. QEMU defines a bunch of registers to do
>> that, and
On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote:
>
> On 12/11/2014 12:34, Christoffer Dall wrote:
> > AFAIU ACPI already has a method for doing this
>
> It's not defined in the spec. QEMU defines a bunch of registers to do
> that, and provides AML that works with those registers.
On 12/11/2014 13:04, Mark Rutland wrote:
>> > SeaBIOS fishes out information from fw_cfg, and puts it in low memory.
>> > On ARM you could use DT binary blobs instead of fw_cfg, as proposed
>> > already (I don't remember if it was in this thread or IRC). Then if you
>> > want to go !UEFI you can
On Wed, Nov 12, 2014 at 11:52:22AM +, Paolo Bonzini wrote:
>
> On 12/11/2014 11:38, Mark Rutland wrote:
> > > I share your concern, but running another UEFI instance for Dom0 doesn't
> > > seem like a viable alternative either. Why is this a problem on ARM and
> > > not on x86 though?
> >
>
On Wed, Nov 12, 2014 at 11:15:08AM +, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 09:08:55AM +, Claudio Fontana wrote:
> > > On 11.11.2014 16:29, Mark Rutland wrote:
> > >
> > > I tend to mostly agree with this, we might loo
On 12/11/2014 11:38, Mark Rutland wrote:
> > I share your concern, but running another UEFI instance for Dom0 doesn't
> > seem like a viable alternative either. Why is this a problem on ARM and
> > not on x86 though?
>
> I believe that on x86 the fallback for !UEFI would be the e820 memory
> ma
On 12/11/2014 12:34, Christoffer Dall wrote:
> AFAIU ACPI already has a method for doing this
It's not defined in the spec. QEMU defines a bunch of registers to do
that, and provides AML that works with those registers.
While these registers can be separated from the ACPI code in QEMU...
> an
On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 09:08:55AM +, Claudio Fontana wrote:
> > > On 11.11.2014 16:29, Mark Rutland wrote:
> > >
> > > I tend to mostly agree with this, we might loo
On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 09:08:55AM +, Claudio Fontana wrote:
> > On 11.11.2014 16:29, Mark Rutland wrote:
> >
> > I tend to mostly agree with this, we might look for alternative
> > solutions for speeding up guest startup in the futu
[...]
> > > > > We are currently suggesting adding an RDSP property to the chosen node
> > > > > in the tiny DT, but a command-line arguement like kexec proposed could
> > > > > be another option I guess, albeit not a very pretty one.
> > > >
> > > > I'm not sure what an RDSP command line propert
On Wed, Nov 12, 2014 at 09:08:55AM +, Claudio Fontana wrote:
> On 11.11.2014 16:29, Mark Rutland wrote:
> > Hi,
> >
> > On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote:
> >> On 6 November 2014 14:44, Peter Maydell wrote:
> >>>
> >>>
> We need ACPI guest support in QE
On Wed, Nov 12, 2014 at 10:38:54AM +, Mark Rutland wrote:
> On Tue, Nov 11, 2014 at 09:33:12PM +, Christoffer Dall wrote:
> > On Tue, Nov 11, 2014 at 04:48:07PM +, Mark Rutland wrote:
> > > Hi Christoffer,
> > >
> > > On Tue, Nov 11, 2014 at 04:31:01PM +, Christoffer Dall wrote:
>
On Tue, Nov 11, 2014 at 09:33:12PM +, Christoffer Dall wrote:
> On Tue, Nov 11, 2014 at 04:48:07PM +, Mark Rutland wrote:
> > Hi Christoffer,
> >
> > On Tue, Nov 11, 2014 at 04:31:01PM +, Christoffer Dall wrote:
> > > On Tue, Nov 11, 2014 at 03:29:33PM +, Mark Rutland wrote:
> > >
On 11.11.2014 16:29, Mark Rutland wrote:
> Hi,
>
> On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote:
>> On 6 November 2014 14:44, Peter Maydell wrote:
>>>
>>>
We need ACPI guest support in QEMU for AArch64 over here, with all features
(including the ability to run AC
On Tue, Nov 11, 2014 at 04:48:07PM +, Mark Rutland wrote:
> Hi Christoffer,
>
> On Tue, Nov 11, 2014 at 04:31:01PM +, Christoffer Dall wrote:
> > On Tue, Nov 11, 2014 at 03:29:33PM +, Mark Rutland wrote:
> > > Hi,
> > >
> > > On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyrida
Hi Christoffer,
On Tue, Nov 11, 2014 at 04:31:01PM +, Christoffer Dall wrote:
> On Tue, Nov 11, 2014 at 03:29:33PM +, Mark Rutland wrote:
> > Hi,
> >
> > On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote:
> > > On 6 November 2014 14:44, Peter Maydell wrote:
> > > >
> >
On Tue, Nov 11, 2014 at 03:29:33PM +, Mark Rutland wrote:
> Hi,
>
> On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote:
> > On 6 November 2014 14:44, Peter Maydell wrote:
> > >
> > >
> > > > We need ACPI guest support in QEMU for AArch64 over here, with all
> > > > features
Hi,
On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote:
> On 6 November 2014 14:44, Peter Maydell wrote:
> >
> >
> > > We need ACPI guest support in QEMU for AArch64 over here, with all
> > > features
> > > (including the ability to run ACPI code and add specific tables), for
>
On 2014-11-6 23:57, Paolo Bonzini wrote:
> On 06/11/2014 07:53, Hanjun Guo wrote:
>>> So the important question is _why_ the guest needs to see an ACPI
>>> environment. What exactly can ACPI provide to the guest that DT does not
>>> already provide, and why is that necessary? What infrastrucutre is
On 06/11/2014 17:18, Igor Mammedov wrote:
> On Thu, 06 Nov 2014 16:57:47 +0100
> Paolo Bonzini wrote:
>
>> On 06/11/2014 07:53, Hanjun Guo wrote:
So the important question is _why_ the guest needs to see an ACPI
environment. What exactly can ACPI provide to the guest that DT does not
On Thu, 06 Nov 2014 16:57:47 +0100
Paolo Bonzini wrote:
> On 06/11/2014 07:53, Hanjun Guo wrote:
> >> So the important question is _why_ the guest needs to see an ACPI
> >> environment. What exactly can ACPI provide to the guest that DT does not
> >> already provide, and why is that necessary? Wh
On 06/11/2014 07:53, Hanjun Guo wrote:
>> So the important question is _why_ the guest needs to see an ACPI
>> environment. What exactly can ACPI provide to the guest that DT does not
>> already provide, and why is that necessary? What infrastrucutre is
>> needed for that use case?
>
> There is im
On 2014-10-31 2:02, Mark Rutland wrote:
> On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote:
>> On 30 October 2014 17:43, Alexander Spyridakis
>> wrote:
>>> Currently, the virt machine model generates Device Tree information
>>> dynamically based on the existing devices in the system.
On 6 November 2014 13:33, Alexander Spyridakis
wrote:
> The rational in the proposed approach is meant for cases where the
> user does not want to rely on external firmware layers. While UEFI
> could do what you are describing, the point is to avoid this not so
> trivial overhead in the booting pr
On Thursday 06 November 2014 13:30:01 Mark Rutland wrote:
>
> There is no way of doing this with DT. There has been work into DT
> fragments/overlays where portions can be added to the tree dynamically,
> but that's controlled by the OS rather than the hypervisor, and there's
> no standard for com
On 6 November 2014 14:44, Peter Maydell wrote:
>
>
> > We need ACPI guest support in QEMU for AArch64 over here, with all features
> > (including the ability to run ACPI code and add specific tables), for
> > ACPI-based guests.
>
> The plan for providing ACPI to guests is that we run a UEFI BIOS
>
On Thu, Nov 06, 2014 at 06:53:03AM +, Hanjun Guo wrote:
> On 2014-10-31 2:02, Mark Rutland wrote:
> > On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote:
> >> On 30 October 2014 17:43, Alexander Spyridakis
> >> wrote:
> >>> Currently, the virt machine model generates Device Tree inf
On Thu, 6 Nov 2014 12:44:04 +
Peter Maydell wrote:
> On 5 November 2014 09:58, Claudio Fontana wrote:
> > Please correct me if I am wrong, my understanding at the moment is that
> > for X86 there is an ACPI implementation in hw/acpi, with the table
> > generation
> > happening in hw/i386/ac
On 5 November 2014 09:58, Claudio Fontana wrote:
> Please correct me if I am wrong, my understanding at the moment is that
> for X86 there is an ACPI implementation in hw/acpi, with the table generation
> happening in hw/i386/acpi-build.c .
> Couldn't there be some unification where part of the in
Hi all,
On 30.10.2014 19:02, Mark Rutland wrote:
> On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote:
>> On 30 October 2014 17:43, Alexander Spyridakis
>> wrote:
>>> Currently, the virt machine model generates Device Tree information
>>> dynamically based on the existing devices in t
On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote:
> On 30 October 2014 17:43, Alexander Spyridakis
> wrote:
> > Currently, the virt machine model generates Device Tree information
> > dynamically based on the existing devices in the system. This patch series
> > extends the same con
66 matches
Mail list logo