On 9 March 2015 at 21:12, Leif Lindholm leif.lindh...@linaro.org 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
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
a.spyrida...@virtualopensystems.com wrote:
Currently, the virt machine model generates Device Tree information
On 2015/3/9 20:28, Peter Maydell wrote:
On 9 March 2015 at 21:12, Leif Lindholm leif.lindh...@linaro.org 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
On Mon, Mar 09, 2015 at 09:28:05PM +0900, Peter Maydell wrote:
On 9 March 2015 at 21:12, Leif Lindholm leif.lindh...@linaro.org 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
On 13 November 2014 09:57, Claudio Fontana claudio.font...@huawei.com 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
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 hardware
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 ARM
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:
On 12.11.2014 19:10, Peter Maydell wrote:
On 12 November 2014 09:08, Claudio Fontana claudio.font...@huawei.com 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
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_smbus
[ ... ]
So this 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 will do:
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 not fixed at
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 peter.mayd...@linaro.org wrote:
We need ACPI guest support in QEMU for AArch64 over here, with all features
(including the ability to
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:
Hi,
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,
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 peter.mayd...@linaro.org wrote:
We need ACPI guest support in
[...]
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 property would have to do
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 future but
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...
and
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
map, which
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.
Huh?
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 provides AML
On Wed, Nov 12, 2014 at 1:27 PM, Paolo Bonzini pbonz...@redhat.com 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 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 DT is
On 12 November 2014 12:04, Mark Rutland mark.rutl...@arm.com 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
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 we talking
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 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 ACPI
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's not defined in
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
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 guess, albeit not a very pretty
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 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 documents
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
tables and make a
On 12.11.2014 14:27, Peter Maydell wrote:
On 12 November 2014 12:04, Mark Rutland mark.rutl...@arm.com 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
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 for
On 12 November 2014 15:32, Arnd Bergmann a...@arndb.de 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
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
fully set
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 servers and
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) set it up
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 the firmware,
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
as QEMU.
On 12 November 2014 16:25, Paolo Bonzini pbonz...@redhat.com 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
On 12 November 2014 09:08, Claudio Fontana claudio.font...@huawei.com 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
Hi,
On Thu, Nov 06, 2014 at 01:33:20PM +, Alexander Spyridakis wrote:
On 6 November 2014 14:44, Peter Maydell peter.mayd...@linaro.org 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
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 peter.mayd...@linaro.org wrote:
We need ACPI guest support in QEMU for AArch64 over here, with all
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 Spyridakis wrote:
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
needed
On 5 November 2014 09:58, Claudio Fontana claudio.font...@huawei.com 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
On Thu, 6 Nov 2014 12:44:04 +
Peter Maydell peter.mayd...@linaro.org wrote:
On 5 November 2014 09:58, Claudio Fontana claudio.font...@huawei.com 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
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
a.spyrida...@virtualopensystems.com wrote:
Currently, the virt machine model
On 6 November 2014 14:44, Peter Maydell peter.mayd...@linaro.org 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
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
On 6 November 2014 13:33, Alexander Spyridakis
a.spyrida...@virtualopensystems.com 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
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
a.spyrida...@virtualopensystems.com wrote:
Currently, the virt machine model generates Device Tree information
dynamically based on the
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 important
On Thu, 06 Nov 2014 16:57:47 +0100
Paolo Bonzini pbonz...@redhat.com 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
On 06/11/2014 17:18, Igor Mammedov wrote:
On Thu, 06 Nov 2014 16:57:47 +0100
Paolo Bonzini pbonz...@redhat.com 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
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
a.spyrida...@virtualopensystems.com wrote:
Currently, the virt machine model generates Device Tree information
dynamically based on
On Thu, Oct 30, 2014 at 05:52:44PM +, Peter Maydell wrote:
On 30 October 2014 17:43, Alexander Spyridakis
a.spyrida...@virtualopensystems.com wrote:
Currently, the virt machine model generates Device Tree information
dynamically based on the existing devices in the system. This patch
60 matches
Mail list logo
