On Thu, Nov 28, 2019 at 4:03 PM <[email protected]> wrote:
> Thanks for the comment :) Please see my reply in the comments.
>
> On 27.11.19 15:43, Nadav Har'El wrote:
>
>
> + u8 v = processor::inb(0x0cf9) & ~6;
>> + processor::outb(v|2, 0x0cf9); // request hard reset
>> + usleep(50);
>> + processor::outb(v|6, 0x0cf9); // actually do the reset
>>
> + usleep(50);
>>
>
> Nice, I wasn't familiar with this method before.
>
> Is it really necessary to write 0x2 once, wait, and then write 0x2 | 0x4
> ("6") in a second write?
> Won't a single write of 6 - once - work, as the (virtual) hardware
> realizes that both 0x4 (do a reset) and 0x2 (make it a hardware reset) bits
> are turned on?
>
> I think, it is better to look at the Intel spec for this question. The
> reset control register is located at offset CF9h. Bit 0 is reserved, bit 1
> is used for system reset (SYS_RST), bit 2 is used for reset cpu (RST_CPU),
> bit 3 is used for full reset (FULL_RST), and bit4-7 are also reserved.
>
> "If SYS_RST is 0 when RST_CPU goes from 0 to 1, then the PMC will force
> INIT# active for 16 PCI clocks. *If SYS_RST is 1 when RST_CPU goes from 0
> to 1, then the PMC will force PCI reset active for about 1 ms, however the
> PMU_SLP_S3_B and PMU_SLP_S4_B signals assertion is dependent on the value
> of the FULL_RST.*
>
> The RST_CPU bit will cause either a hard or soft reset to the CPU
> depending on the state of the SYS_RST The software will cause the reset by
> setting bit 2 from a 0 to a 1."
>
> In other words, we need to first set the SYS_RST to 1, and then set the
> RST_CPU to 1 (which forces a hard reset). The wait probably matters more on
> real hardware.
>
I'm not convinced by this logic - there is no single-bit addressing in x86,
we write the entire byte at once. When the CPU notices RST_CPU=1, it will
also see SYS_RST=1.
But I see that in Linux they did it exactly the way you did it, and also
the same 50usec delay, so I guess I can live with this too :-)
> Linux also implemented this reset method similarly, in
> arch/x86/kernel/reboot.c
>
Yes, I see now.
>
> +}
>> +
>> +void kbd_reboot(void) {
>> + while (processor::inb(0x64) & 0x02); // clear all keyboard buffers
>> + processor::outb(0xfe, 0x64);
>> + usleep(50);
>> +}
>> +
>> void reboot(void)
>> {
>> - // It would be nice if AcpiReset() worked, but it doesn't seem to
>> work
>> - // (on qemu & kvm), so let's resort to other techniques, which appear
>> - // to work. Hopefully one of them will work on any hypervisor.
>> - // Method 1: "fast reset" via System Control Port A (port 0x92)
>> - processor::outb(1, 0x92);
>> + // Method 1: AcpiReset, does not work on qemu or kvm now because the
>> reset
>> + // register is not supported. Nevertheless, we should try it first
>> + AcpiReset();
>> // Method 2: Reset using the 8042 PS/2 Controller ("keyboard
>> controller")
>> - processor::outb(0xfe, 0x64);
>> - // Method 3: Cause triple fault by loading a broken IDT and
>> triggering an
>> + kbd_reboot();
>> + // Method 3: PCI reboot
>> + pci_reboot();
>> + // Method 4: "fast reset" via System Control Port A (port 0x92)
>> + processor::outb(1, 0x92);
>>
>
> I'm curious why you moved this, which was the first method we tried until
> now, to be the fourth. What's
> the downside of doing it first?
>
> Yes, there is no downside. I will submit a new patch with the original
> order.
>
>
> + // Method 5: Cause triple fault by loading a broken IDT and
>> triggering an
>> // interrupt.
>> processor::lidt(processor::desc_ptr(0, 0));
>> __asm__ __volatile__("int3");
>> --
>> 2.17.1
>>
>>
>>
>>
>> Amazon Development Center Germany GmbH
>> Krausenstr. 38
>> 10117 Berlin
>> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
>> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
>> Sitz: Berlin
>> Ust-ID: DE 289 237 879
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OSv Development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/osv-dev/20191127134607.15293-1-yuchenq%40amazon.de
>> .
>>
>
>
--
You received this message because you are subscribed to the Google Groups "OSv
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/osv-dev/CANEVyjueEk3OikcjaHP%3D%3DEuNJ4vMnxrvhLB87f8oCiLMw9pqRw%40mail.gmail.com.
