Re: [PATCH 02/20] MIPS: Clear [MSA]FPE CSR.Cause after notify_die()
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 go through the pain of restoring > those bits if the process is pre-empted, since writing those bits would > cause another immediate exception while still in the kernel. Another reason is MIPS I processors (and for the record I believe the R6000 MIPS II implementation as well) signal FPA exceptions using an ordinary interrupt, seen on one of the IP[7:2] bits in the CP0 Cause register. Consequently reenabling interrupts without first clearing at least all the unmasked FCSR.Cause bits would retrigger the interrupt and cause an infinite loop. We don't ever mask the FPA interrupt with the relevant IM[7:2] bit in the CP0 Status register, because for simplicity we reuse the whole of the FPE exception handling path for FPA interrupts as well. Except that we enter it via the `handle_fpe_int' alternative entry point rather than the usual `handle_fpe' one, bypassing the register save sequence as it was already done by the interrupt handler. Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
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-based MIPS Technologies CMP solutions (1004K, 1074K, interAptiv). Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM/MIPS32: Support for the new Virtualization ASE (VZ-ASE)
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 module requires the presence of CP0 scratch > registers that can be used for this in the exception handlers without having > to worry about using these implementation dependent registers. For the > trap-and-emulate only version, there really is no choice other than to > re-purpose some of the existing CP0 registers. Sure, I've just been wondering what the implementation does to make sure it does not go astray on a random processor out there. FWIW, offhand the ErrorEPC register, that's been universally present since MIPS III (and I doubt anyone cares of virtualising on earlier implementations), seems to me promising as a better choice -- of course that register can get clobbered if an error-class exception happens early on in exception processing, but in that case we're in a worse trouble than just clobbering one of the guest registers anyway and likely cannot recover at all regardless. Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] KVM/MIPS32: Support for the new Virtualization ASE (VZ-ASE)
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 k1 @ a known offset from EBASE. 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? Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 > #endif > > -#ifdef CONFIG_MIPS_MT_SMTC > +#if defined(CONFIG_MIPS_MT_SMTC) || defined (CONFIG_MIPS_HW_FIBERS) > #include > #endif /* CONFIG_MIPS_MT_SMTC */ > > @@ -162,9 +162,9 @@ > .setnoat > .setreorder > mfc0k0, CP0_STATUS > - sll k0, 3 /* extract cu0 bit */ > + andik0,k0,0x10 /* check user mode bit*/ > .setnoreorder > - bltzk0, 8f > + beq k0, $0, 8f >move k1, sp > .setreorder > /* Called from user mode, new stack. */ Any reason this is needed for? If so, then given that this is generic code a corresponding piece has to be added to support the MIPS I ISA processors that have the user mode bit in a different location. Presumably you'll update all the other places that fiddle with CP0.Status.CU0 too? Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic
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/periphrl/docs/23124406.pdf > should be the primary reference - as long as it leaves no open questions. Oh, I'm glad they've put it online after all, so there's an ultimate place to refer to. I've only got a copy of this datasheet I got from Intel on a CD some 15 years ago. And for the record -- they used to publish the 8259A datasheet as well, but it appears to have gone from its place. However it can be easily tracked down by an Internet search engine of your choice by referring to its order # as 231468.pdf (no revision number embedded there in the file name as there was none as it was originally published either). Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic
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 migrating the > guest... It depends on how you define "very rare". Once per month or probably even per day is probably acceptable although you'll see a disruption in the system clock. This is still likely unwanted if the system is used as a clock reference and not just wants to keep its clock right for own purposes. Anything more frequent and NTP does care very much; an accurate system clock is important in many uses, starting from basic ones such as where timestamps of files exported over NFS are concerned. Speaking of real hw -- I don't know whether that really matters for emulated systems. Thanks for looking into the 8254 PIT in details. Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic
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 interrupt even though > > > IRQ2 had dropped again, resulting in a spurious interupt > > > (IRQ15) and a panicked UNIX kernel. > > > > That is quite weird actually -- from my experience the spurious vector is > > never sent from a slave (quite understandably -- since the interrupt is > > gone and no other is pending, the master has no reason to select a slave > > to supply a vector and therefore supplies the spurious vector itself) and > > therefore a spurious IRQ7 is always issued regardless of whether the > > discarded request came from a slave or from the master. > > Keep in mind that this paragraph is describing QEMU's 8259 device > model behavior (and also KVM's), not real hardware. Reading the > unpatched code, the master clearly latches on to the momentary IRQ2, > does not cancel it when it is cleared again, and ultimately delivers > a spurious IRQ15. Well, it is your software model I am writing about. IIRC either (according to your previous understanding of the edge trigger mode) the master should latch IRQ2 and the slave IRQ14 both at a time until ackonwledged or both should (correctly) let it go. So, depending on the model implemented, you should see either IRQ14 or IRQ7 delivered, but never IRQ15. It does not make sense to me when you latch the cascade input in the master but no corresponding actual input in the slave, the chips are symmetrical. Anyway I infer you have corrected the model now and as a side effect no spurious IRQ15 is going to be delivered ever, right? Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] KVM: fix i8259 interrupt high to low transition logic
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 though > IRQ2 had dropped again, resulting in a spurious interupt > (IRQ15) and a panicked UNIX kernel. That is quite weird actually -- from my experience the spurious vector is never sent from a slave (quite understandably -- since the interrupt is gone and no other is pending, the master has no reason to select a slave to supply a vector and therefore supplies the spurious vector itself) and therefore a spurious IRQ7 is always issued regardless of whether the discarded request came from a slave or from the master. Is there a bug elsewhere then too? I would have expected a reasonable (and especially an old-school) x86 OS to be able to cope with spurious 8259A interrupts, but then obviously one would expect them on IRQ7 only. Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86: default to reboot via ACPI
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: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86: default to reboot via ACPI
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, it may have been true not so long ago, though not necessarily so because of less affordability. These days hardware is more and more affordable, but for several years the performance of hardware increased at a rate substantially higher than the demand for resources from software did. Therefore unless you are into HPC or use some inferior pieces of software beyond the scope of this mailing list, older pieces of hardware are often more than adequate to get your work done, so for some there is little incentive to upgrade. Especially as upgrades are not necessarily convenient for example because suddenly you lose something you have got used to with your older equipment which the new one does not have. My old x86 laptop I scrapped earlier this year was eight years old and still up to its task and working fine except its enclosure fell apart. The new one has the graphic driver barely working (no resolution switching for example, the text mode gets garbled upon switching occasionally and sometimes the console goes off entirely), plus a number of less annoying issues I was not really eager to have. I would have kept the old gear if I had had a way to replace the enclosure. My best MIPS64 box is five years old and still decent enough to get its work done. I do not seek a replacement. Overall I am afraid common sense can sometimes be misleading, especially as it varies from person to person. > If we find that the reset was wired to the launch controller after all, > we can back out the change (after we re-evolve technology and Linux; > after all we are doomed to keep reinventing it, aren't we?). The problem is it will work for us and then hit an unsuspecting innocent user out there, someone not competent enough in the area of computer hardware to have an idea what may be going wrong. And most certainly it won't be the launch controller (whatever the thing is -- some military equipment?), but some other random piece of hardware it will have been wired to by someone on a whim. > Let's see what breaks, if any. I understand the disgust people feel > when ACPI is mentioned, but we can't ignore reality. The disgust is expressed for future generations to get a lesson or perish. Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86: default to reboot via ACPI
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 safe. > > If a machine has acpi, and the reset register is set incorrectly, this > change is safe. > > If a machine has acpi, and the reset register is wired to the launch > controller, then perhaps this change is unsafe. Don't issue sysrq-b on > such machines. If a machine has ACPI and it is broken randomly, then the results can be arbitrary. Hopefully not destructively. If even such a simple thing as wiring the reset line so that it functions correctly can be got wrong, more so can be more complex matters. Failing a better alternative, I suppose the change has to go in though. Maciej -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
