On Tue, Jul 20, 2010 at 02:15:16PM +0100, Jamie Lokier wrote:
> Gleb Natapov wrote:
> > On Mon, Jul 19, 2010 at 09:40:18AM +0200, Alexander Graf wrote:
> > >
> > > On 19.07.2010, at 09:33, Gleb Natapov wrote:
> > >
> > > > On Mon, Jul 19, 2010 at 08:28:02AM +0100, Richard W.M. Jones wrote:
> > > >> On Mon, Jul 19, 2010 at 09:23:56AM +0300, Gleb Natapov wrote:
> > > >>> That what I am warring about too. If we are adding device we have to
> > > >>> be
> > > >>> sure such device can actually exist on real hw too otherwise we may
> > > >>> have
> > > >>> problems later.
> > > >>
> > > >> I don't understand why the constraints of real h/w have anything to do
> > > >> with this. Can you explain?
> > > >>
> > > > Each time we do something not architectural it cause us troubles later.
> > > > So constraints of real h/w is our constrains to.
> > > >
> > > >>> Also 1 second on 100M file does not look like huge gain to me.
> > > >>
> > > >> Every second counts. We're trying to get libguestfs boot times down
> > > >> from 8-12 seconds to 4-5 seconds. For many cases it's an interactive
> > > >> program.
> > > >>
> > > > So what about making initrd smaller? I remember managing two
> > > > distribution in 64M flash in embedded project.
> > >
> > > Having a huge initrd basically helps in reusing a lot of existing code.
> > > We do the same - in general the initrd is just a subset of the
> > > applications of the host OS. And if you start putting perl or the likes
> > > into it, it becomes big.
> > >
> > Why not provide small disk/cdrom with all those utilities installed?
> >
> > > I guess the best thing for now really is to try and see which code paths
> > > insb goes along. It should really be coalesced.
> > >
> > It is coalesced to a certain extent (reenter guest every 1024 bytes,
> > read from userspace page at a time). You need to continue injecting
> > interrupt into a guest during long string operation and checking
> > exception condition on a page boundaries.
>
> First obvious change is to make that 4k bytes (page size) when the I/O
> port is the firmware port. That'll make initrd 4 times faster straight away.
>
Actually my description above is incorrect. We read 1024 bytes at a time
from userspace not page. I doubt changing this to be 4096 will make it 4
times faster. Many other things are going on during emulation. Will try
to measure benefit though.
> If that's not enough saving, it strikes me a cleaner approach than
> inventing new kinds of DMA and/or new PCI devices, is to just detect
> when the rep insb instruction is used for loading a firmware blob and
> treat that as a different trap.
We are not going to put hacks into the kernel for that. Kernel knows
nothing about firmware blobs.
>
> Is guest SeaBIOS in real mode at that point? If yes, then it would be
> best to trap this combination:
>
> rep insb is fetching a blob + CPU is in real mode
>
> Because then it's safe to skip the exception check on page boundaries.
The interface between kernel an userspace allows for reading/writing 4K
of pio at a time max.
>
> If no, the trap will need to be a bit smarter.
>
> Advantages of this approach:
>
> - No need for new BIOS
Which remind me that ad-hoc DMA interface should be discoverable by a
guest.
> - Will work with older BIOSes using current method, and accelerate them
> - No need for distinct -initrd BIOS implementations for isapc and pc,
> (compared with the PCI proposal)
> - Doesn't add any new "extra-architectural" behaviour
>
> -- Jamie
--
Gleb.
