OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


On 2018/11/21 äå1:11, Michael S. Tsirkin wrote:
A question is. Are you suggesting to have VIRTIO_F_ORDER_PLATFORM for each
hardware implementation?
It's not a simple question. There are implementations such as
VDPA which have a hardware and a software component.
For a hardware only device that is also pluggable into an
arbitrary system, it's true.

If not, can a hardware detect the platform by
itself and advertise this bit automatically?
So a mixed software/hardware device might be able to,
and e.g. fallback to a software implementation
if driver assumes that.

There's actually some text that suggests this - is
that not clear then?

Maybe it's better to add text about the suggestion of hardware implementation.

ACCESS_PLATFORM has similar question.
That one is a bit different in that guest might rely on e.g.
vIOMMU for security.  So depending on platform device might want
to fail feature negotiation.

But it's not a problem for e.g. SEV since a legacy non encrypted
guest will just work.

How about a encrypted guest that wants to use software IOTLB?

Maybe a new section about security might make sense.

The question is about the necessarily
of duplicating platform specific feature detection into a device feature.
Historically the assumption drivers made was that
a device is exactly like driver: same physical address,
same permissions and ordering for memory accesses.

Nowdays some drivers make the assumptions about ordering
but not permissions and physical address.

We can't just ignore existing drivers, can we?

It can only work if both features were supported and advertised by devices. Consider the case that IOMMU is enable but iommu_platform is not, in this case:

1) we still can't recognize old guests, so it won't fail gracefully.

2) new guests can't work

It depends on how much we can gain from failing gracefully. I believe we don't want to force a software fallback. So I wonder how bad just let existing drivers fail and try to patch and backport the fixes without introducing new feature bits. With this we can offload those tasks to platform or configuration specific codes instead of our own.

Another question is whether or not we need two separate feature bits. E.g when should we set one bit but not for another?

So a device needs to know what it's dealing with, to
either fail gracefully or recover by a software fallback.

All good questions, though I'm not sure whether they mean we
need to add some text to the spec. Suggestions about
what should be documented?

Maybe it's better to clarify the suggestion for hardware or mixed implementations.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]