Hi,
On Tue, 2007-11-27 at 09:00 -0800, Jeremy Fitzhardinge wrote:
> > Why do you think that's a CR0 write?
>
> Well, the oops says "EIP is at native_write_cr0+0x0/0x4", and the caller
> is prepare_set(), which does:
>
> /* Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
>
>The oops and backtrace doesn't suggest it's an MSR write. Does a crX
Oh, right, the MSR write is being ignored, not failed.
>write take the same path through the emulator as an MSR write?
No, the two operations take different paths.
Jan
___
Virtua
Jan Beulich wrote:
>>> It breaks with:
>>>
>>> Intel machine check architecture supported.
>>> (XEN) traps.c:1734:d0 Domain attempted WRMSR 0404 from
>>> :0001 to
>>> :.
>>> Intel machine check reporting enabled on CPU#0.
>>> general protection fault: [#1] SMP
>> It breaks with:
>>
>> Intel machine check architecture supported.
>> (XEN) traps.c:1734:d0 Domain attempted WRMSR 0404 from :0001
>> to
>> :.
>> Intel machine check reporting enabled on CPU#0.
>> general protection fault: [#1] SMP
>> Modules linked in:
>>
Carsten Otte wrote:
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should se
Avi Kivity wrote:
We intend to bind our virtio devices to PCI too, so that they look the
same in Linux userland across architectures.
Ouch.
That was my initial opinion too, but HPA has come up with a lean and
clean PCI binding for lguest. I think we should seriously consider
using that over t
Carsten Otte wrote:
[actually thinking a bit, this is specific to the virtio pci binding;
s390 will never see any of it]
You remember that we've lost the big debate around virtio in Tucson?
I was in the embedded BOF.
We intend to bind our virtio devices to PCI too, so that they look the
sa
Avi Kivity wrote:
Unfortunately, we have to care for platform differences, subarch
differences (vmx/svm), hypervisor differences (with virtio), and guest
differences (Linux/Windows/pvLinux, 32/64). Much care is needed when
designing the ABI here.
Yea, I agree.
[actually thinking a bit, this
Carsten Otte wrote:
Avi Kivity wrote:
No, definitely not define a hypercall ABI. The feature bit should say
"this device understands a hypervisor-specific way of kicking. consult
your hypervisor manual and cpuid bits for further details. should you
not be satisfied with this method, port
On Tuesday 27 November 2007, Avi Kivity wrote:
> > :-) Do you know if there is a hard limit on the number of devices on
> > a PCI bus? My concern was that it was limited by something stupid
> > like an 8-bit identifier.
>
> IIRC pci slots are 8-bit, but you can have multiple buses, so
> effec
Avi Kivity wrote:
No, definitely not define a hypercall ABI. The feature bit should say
"this device understands a hypervisor-specific way of kicking. consult
your hypervisor manual and cpuid bits for further details. should you
not be satisfied with this method, port io is still available".
Anthony Liguori wrote:
Another point is that virtio still has a lot of leading zeros in its
mileage counter. We need to keep things flexible and learn from
others as much as possible, especially when talking about the ABI.
Yes, after thinking about it over holiday, I agree that we should at
l
12 matches
Mail list logo