latentprion / zambesii Goto Github PK

Virtual box fails to route IRQs through to the LAPICs when the kernel masks the i8259 PICs and unmasks pins on the IO-APICs.

ISA IRQ overriding is correctly set-up, and all signs point to the problem not being in the IO-APIC code.

Having looked through Linux source, I may have to probe for and handle possible cases where eccentric routing may need to be used. Could also be the fact that the LAPICs are only half-heartedly initialized for now.

Return to this issue when the CPU initialization sequence has been overhauled.

In several places where we do a readAcquire() and then read locked values, then do a readReleaseWriteAcquire() using the values we read during the readAcquire(), we may be creating bugs.

In particular, consider:

readAcquire();
// Assume that s.rsrc.count == 4, arbitrarily.
newmem = new ExampleClass[s.rsrc.count + 1];
memcpy(newmem, s.rsrc.array, sizeof(*newmem) * s.rsrc.count);

readReleaseWriteAcquire();
s.rsrc.array = newmem;
s.rsrc.counter += 1;
writeRelease();

This is fine if executed by one CPU, but if two CPUs executed it and both of them read the same value from s.rsrc.counter and allocated an array with 5 elements, then CPU0 acquired the write lock and incremented s.rsrc.counter to 5. CPU0 then exits safely.

Then CPU1 acquires the write lock and now it assigns its array of size 5 to s.rsrc.array as well. Then it increments s.rsrc.counter to 6. It then exits.

Now the state is invalid.

You can combine all of the functions into one function with a single large switch, and then create front-end type-safe wrapper functions to eliminate the need to cast the returned table pointer.

The same applies to srat.cpp.