search for: ness

Page reporting features were never supported by legacy hypervisors. Supporting them poses a problem: should we use native endian-ness (like current code assumes)? Or little endian-ness like the virtio spec says? Rather than try to figure out, and since results of incorrect endian-ness are dire, let's just block this configuration. Cc: stable at vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---...

Page reporting features were never supported by legacy hypervisors. Supporting them poses a problem: should we use native endian-ness (like current code assumes)? Or little endian-ness like the virtio spec says? Rather than try to figure out, and since results of incorrect endian-ness are dire, let's just block this configuration. Cc: stable at vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---...

...0, 2020 at 09:13:41AM -0700, Alexander Duyck wrote: > On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > Page reporting features were never supported by legacy hypervisors. > > Supporting them poses a problem: should we use native endian-ness (like > > current code assumes)? Or little endian-ness like the virtio spec says? > > Rather than try to figure out, and since results of > > incorrect endian-ness are dire, let's just block this configuration. > > > > Cc: stable at vger.kernel.org > > Signed...

...0, 2020 at 09:13:41AM -0700, Alexander Duyck wrote: > On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > Page reporting features were never supported by legacy hypervisors. > > Supporting them poses a problem: should we use native endian-ness (like > > current code assumes)? Or little endian-ness like the virtio spec says? > > Rather than try to figure out, and since results of > > incorrect endian-ness are dire, let's just block this configuration. > > > > Cc: stable at vger.kernel.org > > Signed...

On Tue, Dec 02, 2014 at 07:39:30PM +0100, Cornelia Huck wrote: > On Tue, 2 Dec 2014 13:44:06 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > balloon device is not part of virtio 1.0 spec. Still, it's easy enough > > to make it handle endian-ness exactly as other virtio 1.0 devices: what > > we gain from this, is that there's no need to special-case it in virtio > > core. > > Well, the balloon is weird in a number of ways, including its always > little-endian config space. Hmm yes, I forgot about that. > But I...

On Tue, Dec 02, 2014 at 07:39:30PM +0100, Cornelia Huck wrote: > On Tue, 2 Dec 2014 13:44:06 +0200 > "Michael S. Tsirkin" <mst at redhat.com> wrote: > > > balloon device is not part of virtio 1.0 spec. Still, it's easy enough > > to make it handle endian-ness exactly as other virtio 1.0 devices: what > > we gain from this, is that there's no need to special-case it in virtio > > core. > > Well, the balloon is weird in a number of ways, including its always > little-endian config space. Hmm yes, I forgot about that. > But I...

balloon device is not part of virtio 1.0 spec. Still, it's easy enough to make it handle endian-ness exactly as other virtio 1.0 devices: what we gain from this, is that there's no need to special-case it in virtio core. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/uapi/linux/virtio_balloon.h | 5 +++-- drivers/virtio/virtio_balloon.c | 4 ++-- 2 files changed,...

balloon device is not part of virtio 1.0 spec. Still, it's easy enough to make it handle endian-ness exactly as other virtio 1.0 devices: what we gain from this, is that there's no need to special-case it in virtio core. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/uapi/linux/virtio_balloon.h | 5 +++-- drivers/virtio/virtio_balloon.c | 4 ++-- 2 files changed,...

...#39;m working on..." or "It would be really great if..." on all of these without seeing real evidence on any of them other than talk. The only well-remembered myth I can say for certain that has been dispelled is the SCCP channel driver, and that has been moved out of "Loch Ness" status to "peer-reviewed" status. JT

Aha, okay. I had noticed that the column-info hack went away. So the distinct-ness implies the scope implicit in the inlined call, which later on will be turned into the explicit inlined_subroutine entry. That seems… indirect. I have to say, the LangRef page's words about "merge based on content" is not really to the point. It's like saying the purpose of a s...

On Tue, 2 Dec 2014 13:44:06 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > balloon device is not part of virtio 1.0 spec. Still, it's easy enough > to make it handle endian-ness exactly as other virtio 1.0 devices: what > we gain from this, is that there's no need to special-case it in virtio > core. Well, the balloon is weird in a number of ways, including its always little-endian config space. But I'm not quite sure the spec covers this? > > Signe...

On Tue, 2 Dec 2014 13:44:06 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote: > balloon device is not part of virtio 1.0 spec. Still, it's easy enough > to make it handle endian-ness exactly as other virtio 1.0 devices: what > we gain from this, is that there's no need to special-case it in virtio > core. Well, the balloon is weird in a number of ways, including its always little-endian config space. But I'm not quite sure the spec covers this? > > Signe...

On Wed, 22 Oct 2014 01:09:40 +0300 "Michael S. Tsirkin" <mst at redhat.com> wrote: > This adds wrappers to switch between native endian-ness > (virtio 0.9) and virtio endian-ness (virtio 1.0). > Add new typedefs as well, so that we can check > statically that we didn't miss any accesses. > All callers simply pass in false (0.9) so no > functional change for now. > > Signed-off-by: Michael S. Tsirkin <mst at...

Config space endian-ness is currently a mess: fields are not tagged with the correct endian-ness so it's easy to make mistakes like instanciating config space in native endian-ness. The following patches adding sparse tagging are currently in my tree. Lightly tested. As a follow-up, I plan to add new APIs that handle...

I'm encountering a merge issue whose root cause has to do with "distinct" metadata nodes. I see that distinct-ness is an intentional concept, but the explanation in the LLVM Language Reference is not very enlightening. distinct nodes are useful when nodes shouldn't be merged based on their content. The notion of "merged" metadata is not discussed elsewhere on the page, except for Objecti...

...iler warnings now. The second is hard because of bitfields. I object to the first. If you need a new type name, use a typedef. It's time honored and everyone, including C programmers, will know what you're doing. I don't understand why people push the new thing just for the sake of new-ness. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170109/eb3d1ebc/attachment.html>

vhost/scsi doesn't handle type conversion correctly for request type when using virtio 1.0 and up for BE, or cross-endian platforms. Fix it up using vhost_32_to_cpu. Cc: stable at vger.kernel.org Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vhost/scsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c

On Fri, Jul 10, 2020 at 4:31 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > Page reporting features were never supported by legacy hypervisors. > Supporting them poses a problem: should we use native endian-ness (like > current code assumes)? Or little endian-ness like the virtio spec says? > Rather than try to figure out, and since results of > incorrect endian-ness are dire, let's just block this configuration. > > Cc: stable at vger.kernel.org > Signed-off-by: Michael S. Tsirkin &l...

On 2020/7/15 ??9:58, Michael S. Tsirkin wrote: > VDPA sim stores config space as native endian, but that > is wrong: modern guests expect LE. > I coded up the following to fix it up, but it is wrong too: > vdpasim_create is called before guest features are known. > > So what should we do? New ioctl to specify the interface used? > More ideas? > > Signed-off-by: Michael

VDPA mlx5 accesses config space as native endian - this is wrong since it's a modern device and actually uses LE. It only supports modern guests so we could punt and just force LE, but let's use the full virtio APIs since people tend to copy/paste code, and this is not data path anyway. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/vdpa/mlx5/net/mlx5_vnet.c |