Re: [Xen-devel] [PATCH v2 1/4] x86/MSI-X: be more careful during teardown

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.04.15 at 14:01, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Mon, 13 Apr 2015, Jan Beulich wrote:
>> >>> On 13.04.15 at 12:50, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
>> > On Mon, 13 Apr 2015, Jan Beulich wrote:
>> >> While we trust Dom0 to not do outright bad things,
>> >> the hypervisor should still avoid doing things that can go wrong
>> >> due to the state a device is put (or left) in by Dom0.
>> > 
>> > Xen should also avoid doing things that can go wrong because of the
>> > state a device is put in by QEMU or other components in the system.
>> > There isn't much room for Xen to play with.
>> 
>> Qemu is either part of Dom0, or doesn't play with devices directly.
> 
> I don't understand the point you are trying to make here.
> If your intention is to point out that QEMU shouldn't be writing to the
> control register, as I wrote earlier, the current codebase disagrees
> with you and has been that way for years.

Yes, this was precisely my intention. Qemu having done a certain
thing for many years doesn't mean this is correct, and shouldn't
be fixed if broken.

>> > And how are we going to deal with older "unfixed" QEMUs?
>> > So far we have been using the same policy for QEMU and the Dom0 kernel:
>> > Xen doesn't break them -- old Linux kernels and QEMUs are supposed to
>> > just work.
>> 
>> I'm not sure that's really true for qemu, or if it is, then only by pure
>> luck:
> 
> This is false, it is so by design.  QEMU has an internal libxc
> compatibility layer.

Which could necessarily only ever be updated after the fact (of
a libxc change) and only ever in maintained branches. I.e. as
widely or as narrow as fixing the issues here would require.

>> I view it as unavoidable to break older qemu here.
> 
> I disagree and I am opposed to any patches series that would
> deliberately break QEMU.

If that was without also adjusting qemu I would understand you.
Considering that the issues here haven't been brought up just
yesterday, the lack of any substantial counter proposal on how
to fix this is signaling to me that there are little alternatives. Or
do you have any going beyond "do it another way"?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel