Paolo Bonzini writes:
> On 26/09/19 12:16, Sergio Lopez wrote:
>>> If KVM is in use, the
>>> LAPIC timer frequency is known to be 1 GHz.
>>>
>>> arch/x86/kernel/kvm.c can just set
>>>
>>> lapic_timer_period = 10 / HZ;
>>>
>>> and that should disabled LAPIC calibration if TSC deadline
On 26/09/19 12:16, Sergio Lopez wrote:
>> If KVM is in use, the
>> LAPIC timer frequency is known to be 1 GHz.
>>
>> arch/x86/kernel/kvm.c can just set
>>
>> lapic_timer_period = 10 / HZ;
>>
>> and that should disabled LAPIC calibration if TSC deadline is absent.
> Given that they can
Paolo Bonzini writes:
> On 26/09/19 08:23, Sergio Lopez wrote:
>>
>> There's still one problem. If the Guest doesn't have TSC_DEADLINE_TIME,
>> Linux hangs on APIC timer calibration. I'm looking for a way to work
>> around this. Worst case scenario, we can check for that feature and add
>> both
On 26/09/19 08:23, Sergio Lopez wrote:
>
> There's still one problem. If the Guest doesn't have TSC_DEADLINE_TIME,
> Linux hangs on APIC timer calibration. I'm looking for a way to work
> around this. Worst case scenario, we can check for that feature and add
> both PIC and PIT if is missing.
>
Paolo Bonzini writes:
> On 25/09/19 17:04, Sergio Lopez wrote:
>> I'm going back to this level of the thread, because after your
>> suggestion I took a deeper look at how things work around the PIC, and
>> discovered I was completely wrong about my assumptions.
>>
>> For virtio-mmio devices, gi
On 25/09/19 17:04, Sergio Lopez wrote:
> I'm going back to this level of the thread, because after your
> suggestion I took a deeper look at how things work around the PIC, and
> discovered I was completely wrong about my assumptions.
>
> For virtio-mmio devices, given that we don't have the abili
Paolo Bonzini writes:
> On 24/09/19 14:44, Sergio Lopez wrote:
>> +Microvm is a machine type inspired by both NEMU and Firecracker, and
>> +constructed after the machine model implemented by the latter.
>
> I would say it's inspired by Firecracker only. The NEMU virt machine
> had virtio-pci an
On 25/09/19 13:04, Sergio Lopez wrote:
> Yes, that would do the trick. There's another use of it at
> hw/intc/ioapic.c:78, but we should be safe as, at least in the case of
> Linux, DM_EXTINT is only used in check_timer(), which is only called if
> it detects a i8259 PIC.
Even there it is actually
Paolo Bonzini writes:
> On 25/09/19 10:40, Sergio Lopez wrote:
We need the PIT for non-KVM accel (if present with KVM and
kernel_irqchip_split = off, it basically becomes a placeholder)
>>> Why?
>>
>> Perhaps I'm missing something. Is some other device supposed to be
>> acting as a HW
On 25/09/19 10:40, Sergio Lopez wrote:
>>> We need the PIT for non-KVM accel (if present with KVM and
>>> kernel_irqchip_split = off, it basically becomes a placeholder)
>> Why?
>
> Perhaps I'm missing something. Is some other device supposed to be
> acting as a HW timer while running with TCG acc
Hi,
> For microvm that's simply not worth it. Fiddling with the command line
> achieves the same result without any significant drawbacks,
Assuming you actually can fiddle with the command line, which is only
the case with direct kernel boot.
> > To fix that the firmware must be able to find t
Paolo Bonzini writes:
> On 25/09/19 07:49, Sergio Lopez wrote:
+serving as a stepping stone
+for future projects aiming at improving boot times, reducing the
+attack surface and slimming down QEMU's footprint.
>>>
>>> "Microvm also establishes a baseline for benchmarking QEMU and
On 25/09/19 07:49, Sergio Lopez wrote:
>>> +serving as a stepping stone
>>> +for future projects aiming at improving boot times, reducing the
>>> +attack surface and slimming down QEMU's footprint.
>>
>> "Microvm also establishes a baseline for benchmarking QEMU and operating
>> systems, since it i
Gerd Hoffmann writes:
> Hi,
>
>> +microvm.kernel-cmdline=bool (Set off to disable adding virtio-mmio devices
>> to the kernel cmdline)
>
> Hmm, is that the long-term plan? IMO the virtio-mmio devices should be
> discoverable somehow. ACPI, or device-tree, or fw_cfg, or ...
I'd say that dep
Paolo Bonzini writes:
> On 24/09/19 14:44, Sergio Lopez wrote:
>> +Microvm is a machine type inspired by both NEMU and Firecracker, and
>> +constructed after the machine model implemented by the latter.
>
> I would say it's inspired by Firecracker only. The NEMU virt machine
> had virtio-pci an
Hi,
> +microvm.kernel-cmdline=bool (Set off to disable adding virtio-mmio devices
> to the kernel cmdline)
Hmm, is that the long-term plan? IMO the virtio-mmio devices should be
discoverable somehow. ACPI, or device-tree, or fw_cfg, or ...
> +As no current FW is able to boot from a block de
Document the new microvm machine type.
Signed-off-by: Sergio Lopez
---
docs/microvm.txt | 78
1 file changed, 78 insertions(+)
create mode 100644 docs/microvm.txt
diff --git a/docs/microvm.txt b/docs/microvm.txt
new file mode 100644
index 00
On 24/09/19 14:44, Sergio Lopez wrote:
> +Microvm is a machine type inspired by both NEMU and Firecracker, and
> +constructed after the machine model implemented by the latter.
I would say it's inspired by Firecracker only. The NEMU virt machine
had virtio-pci and ACPI.
> +It's main purpose is p
18 matches
Mail list logo
