Re: [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic

2012-09-10 Thread Maciej W. Rozycki
On Sun, 9 Sep 2012, Matthew Ogilvie wrote: > This bug manifested itself when the guest was Microport UNIX > System V/386 v2.1 (ca. 1987), because it would sometimes mask > off IRQ14 in the slave IMR after it had already been asserted. > The master would still try to deliver an interrupt even thoug

Re: [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic

2012-09-11 Thread Maciej W. Rozycki
On Mon, 10 Sep 2012, Matthew Ogilvie wrote: > > > This bug manifested itself when the guest was Microport UNIX > > > System V/386 v2.1 (ca. 1987), because it would sometimes mask > > > off IRQ14 in the slave IMR after it had already been asserted. > > > The master would still try to deliver an int

Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic

2012-09-13 Thread Maciej W. Rozycki
On Wed, 12 Sep 2012, Matthew Ogilvie wrote: > Also, how big of a concern is a very rare gained or lost IRQ0 > actually? Under normal conditions, I would expect this to at most > cause a one time clock drift in the guest OS of a fraction of > a second. If that only happens when rebooting or migra

Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic

2012-09-13 Thread Maciej W. Rozycki
On Thu, 13 Sep 2012, Jan Kiszka wrote: > > I've also just skimmed parts of the 8254 section of "The Indispensable PC > > Hardware Book", by Hans-Peter Messmer, Copyright 1994 Addison-Wesley, > > although I probably ought to read it more carefully. > > http://download.intel.com/design/archives/per

Re: [PATCH 14/20] MIPS: Use the UM bit instead of the CU0 enable bit in the status register to figure out the stack for saving regs.

2012-11-02 Thread Maciej W. Rozycki
On Wed, 31 Oct 2012, Sanjay Lal wrote: > diff --git a/arch/mips/include/asm/stackframe.h > b/arch/mips/include/asm/stackframe.h > index cb41af5..59c9245 100644 > --- a/arch/mips/include/asm/stackframe.h > +++ b/arch/mips/include/asm/stackframe.h > @@ -30,7 +30,7 @@ > #define STATMASK 0x1f > #en

Re: [PATCH 00/18] KVM/MIPS32: Support for the new Virtualization ASE (VZ-ASE)

2013-05-20 Thread Maciej W. Rozycki
On Mon, 20 May 2013, Sanjay Lal wrote: > (1) Newer versions of the MIPS architecture define scratch registers for > just this purpose, but since we have to support standard MIPS32R2 > processors, we use the DDataLo Register (CP0 Register 28, Select 3) as a > scratch register to save k0 and save

Re: [PATCH 00/18] KVM/MIPS32: Support for the new Virtualization ASE (VZ-ASE)

2013-05-27 Thread Maciej W. Rozycki
On Mon, 20 May 2013, David Daney wrote: > > That's rather risky as the implementation of this register (and its > > presence in the first place) is processor-specific. Do you maintain a > > list of PRId values the use of this register is safe with? > > > > FWIW: The MIPS-VZ architecture modu

Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.

2013-06-09 Thread Maciej W. Rozycki
On Sun, 9 Jun 2013, David Daney wrote: > > How different MIPS SMP systems are? > > o Old SGI heavy metal (several different system architectures). > > o Cavium OCTEON SMP SoCs. > > o Broadcom (several flavors) SoCs > > o Loongson o Old DEC hardware (DECsystem 58x0, R3000-based). o Malta-ba

Re: [PATCH 02/20] MIPS: Clear [MSA]FPE CSR.Cause after notify_die()

2015-04-07 Thread Maciej W. Rozycki
On Wed, 11 Mar 2015, James Hogan wrote: > When handling floating point exceptions (FPEs) and MSA FPEs the Cause > bits of the appropriate control and status register (FCSR for FPEs and > MSACSR for MSA FPEs) are read and cleared before enabling interrupts, > presumably so that it doesn't have to g

Re: [PATCH] x86: default to reboot via ACPI

2008-08-26 Thread Maciej W. Rozycki
On Tue, 26 Aug 2008, Avi Kivity wrote: > Most machines are recent machines. This is a bold statement I would say. Any numbers to back it up? > If a machine doesn't have acpi, this change is safe. > > If a machine has acpi, but doesn't have the reset register set in the > FADT, this change is

Re: [PATCH] x86: default to reboot via ACPI

2008-08-26 Thread Maciej W. Rozycki
On Tue, 26 Aug 2008, Avi Kivity wrote: > Only common sense. Non-recent machines are barely usable these days. > Sure they work well as a firewall or server-in-a-closet, but if you run > a desktop or a server that actually does useful work, you're running a > relatively recent machine. Hmm,

Re: [PATCH] x86: default to reboot via ACPI

2008-08-26 Thread Maciej W. Rozycki
On Tue, 26 Aug 2008, Pavel Machek wrote: > reboot needs to work on servers-in-a-closet, too. More importantly even, I would say, as failing to do so will cost some a drive to a remote location in the middle of the night on a weekend or some holiday. Maciej -- To unsubscribe from this list: se