On Tue, Jun 28, 2016 at 06:10:51PM +0800, Chao Peng wrote:
> On Thu, Jun 23, 2016 at 01:55:06PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jun 20, 2016 at 02:12:17PM +0800, Chao Peng wrote:
> > > On Sun, Jun 19, 2016 at 06:51:04AM +0300, Michael S. Tsirkin wrote:
> > > > On Fri, Jun 17, 2016 at
On Thu, Jun 23, 2016 at 01:55:06PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 20, 2016 at 02:12:17PM +0800, Chao Peng wrote:
> > On Sun, Jun 19, 2016 at 06:51:04AM +0300, Michael S. Tsirkin wrote:
> > > On Fri, Jun 17, 2016 at 04:14:08AM -0400, Chao Peng wrote:
> > > > - it is FAST;
> > >
> >
>
> qboot does basically four things: 1) relocate from ROM to 0xf; 2)
> initialize PCI; 2) provide the ACPI and e820 tables; 3) boot.
>
> If Linux can boot without initializing PCI bridges and without INTX, we
> can remove that code from qboot. The PCI scan is the most expensive
> part, I
Hi Paolo,
On 24.06.2016 14:53, Paolo Bonzini wrote:
>
>
> On 24/06/2016 08:41, Claudio Fontana wrote:
>>> I use qboot for similar goals, you mention that PAM is necessary because of
>>> how qboot probes parallel flash,
>>> however in my custom platform I removed PAM completely from QEMU, and
On 24/06/2016 08:41, Claudio Fontana wrote:
>> I use qboot for similar goals, you mention that PAM is necessary because of
>> how qboot probes parallel flash,
>> however in my custom platform I removed PAM completely from QEMU, and
>> everything seems to work without any problems..
>
> Btw
Hi Paolo,
On 23.06.2016 20:44, Paolo Bonzini wrote:
>
>
> On 23/06/2016 10:32, Chao Peng wrote:
>> The original usage model is to replace kvm-tool with QEMU for Clear
>> Containers (https://clearlinux.org/features/clear-containers). It's not
>> going to present the guest a real PC platform, but
On 24.06.2016 14:39, Claudio Fontana wrote:
> Hi Paolo,
>
> On 23.06.2016 20:44, Paolo Bonzini wrote:
>>
>>
>> On 23/06/2016 10:32, Chao Peng wrote:
>>> The original usage model is to replace kvm-tool with QEMU for Clear
>>> Containers (https://clearlinux.org/features/clear-containers). It's not
On Mon, Jun 20, 2016 at 02:12:17PM +0800, Chao Peng wrote:
> On Sun, Jun 19, 2016 at 06:51:04AM +0300, Michael S. Tsirkin wrote:
> > On Fri, Jun 17, 2016 at 04:14:08AM -0400, Chao Peng wrote:
> > > - it is FAST;
> >
> > Any numbers to demonstrate just how fast it is and fast at what?
>
> On a
On 23/06/2016 10:32, Chao Peng wrote:
> The original usage model is to replace kvm-tool with QEMU for Clear
> Containers (https://clearlinux.org/features/clear-containers). It's not
> going to present the guest a real PC platform, but instead, a totally
> virtual platform.
It is not completely
>
> I think a lightweight q35 platform that can run the usual firmware could
> be acceptable in QEMU.
After re-thought the target usage model, I'm not sure if this is a good
idea.
The original usage model is to replace kvm-tool with QEMU for Clear
Containers
On Mon, Jun 20, 2016 at 08:54:10AM +0200, Paolo Bonzini wrote:
>
>
> On 20/06/2016 08:01, Chao Peng wrote:
> > On Fri, Jun 17, 2016 at 03:24:59PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 17/06/2016 10:14, Chao Peng wrote:
> >>> Basically:
> >>> - it removes old ISA devices and support only
> It would be nice to at least see the patches. :)
>
> I think a lightweight q35 platform that can run the usual firmware could
> be acceptable in QEMU.
OK, I will send out v2.
>
> >> 2) this:
> >>
> >>> - it loads guest kernel directly, no BIOS, no bootloader, no realmode
> >>> code;
> >>
>
On 20/06/2016 14:31, Stefan Hajnoczi wrote:
> On Mon, Jun 20, 2016 at 08:54:10AM +0200, Paolo Bonzini wrote:
> > I wonder if Linux could run as a multiboot-compliant ELF file, and what
> > the performance would be... Multiboot omits the real mode stub.
>
> The Linux boot protocol does not
On Mon, Jun 20, 2016 at 08:54:10AM +0200, Paolo Bonzini wrote:
> I wonder if Linux could run as a multiboot-compliant ELF file, and what
> the performance would be... Multiboot omits the real mode stub.
The Linux boot protocol does not require real mode. I think "64-bit
BOOT PROTOCOL" in
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 17/06/2016 10:14, Chao Peng wrote:
> > Basically:
> > - it removes old ISA devices and support only PCI devices;
>
> I think you need to keep at least the RTC, otherwise where does Linux
> get the time of day from?
>
> > - it removes 8259,
On 20/06/2016 08:01, Chao Peng wrote:
> On Fri, Jun 17, 2016 at 03:24:59PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 17/06/2016 10:14, Chao Peng wrote:
>>> Basically:
>>> - it removes old ISA devices and support only PCI devices;
>>
>> I think you need to keep at least the RTC, otherwise where
>
> The combination of devices removed/supported seems a bit arbitrary to me.
> The use in this text of "legacy" and non-"legacy" is also arbitrary if not
> given a definition.
The criterial here is to remove the devices that have poor performance.
You can think legacy devices here as ISA
On Sun, Jun 19, 2016 at 06:51:04AM +0300, Michael S. Tsirkin wrote:
> On Fri, Jun 17, 2016 at 04:14:08AM -0400, Chao Peng wrote:
> > - it is FAST;
>
> Any numbers to demonstrate just how fast it is and fast at what?
On a 2.30GHz Haswell server, guest kernel booting time is 59.9ms by
following
On Fri, Jun 17, 2016 at 03:24:59PM +0200, Paolo Bonzini wrote:
>
>
> On 17/06/2016 10:14, Chao Peng wrote:
> > Basically:
> > - it removes old ISA devices and support only PCI devices;
>
> I think you need to keep at least the RTC, otherwise where does Linux
> get the time of day from?
PV
Hi,
On 17.06.2016 10:14, Chao Peng wrote:
> This patchset is against commit 585fcd4 (Merge remote-tracking branch
> 'remotes/bonzini/tags/for-upstream' into staging) on master branch. I
> also put it on github:
>
> https://github.com/chao-p/qemu pc-lite-v1
>
> Although we have run the patchset
On Fri, Jun 17, 2016 at 04:14:08AM -0400, Chao Peng wrote:
> - it is FAST;
Any numbers to demonstrate just how fast it is and fast at what?
> --
> 1.8.3.1
On 17/06/2016 10:14, Chao Peng wrote:
> Basically:
> - it removes old ISA devices and support only PCI devices;
I think you need to keep at least the RTC, otherwise where does Linux
get the time of day from?
> - it removes 8259, instead use MSI as much as possible. IOAPIC and PCI
> PIN are
This patchset is against commit 585fcd4 (Merge remote-tracking branch
'remotes/bonzini/tags/for-upstream' into staging) on master branch. I
also put it on github:
https://github.com/chao-p/qemu pc-lite-v1
Although we have run the patchset internally for a while but it is still
considered as
23 matches
Mail list logo
