search for: eschew

...) */ +#define VIRTIO_F_IOMMU_PLATFORM????????????????34 OK... let's see if I can reconcile those descriptions coherently. Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that its own operating system's IOMMU code is expected to be broken, and that the virtio driver should eschew the DMA API? And that the guest OS cannot further assign the affected device to any of *its* nested guests? Not that the broken IOMMU code in said guest OS will know the latter, of course. With VIRTIO_F_IOMMU_PLATFORM set, VIRTIO_F_IOMMU_PASSTHROUGH is just a *hint*, suggesting that the guest OS s...

...) */ +#define VIRTIO_F_IOMMU_PLATFORM????????????????34 OK... let's see if I can reconcile those descriptions coherently. Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that its own operating system's IOMMU code is expected to be broken, and that the virtio driver should eschew the DMA API? And that the guest OS cannot further assign the affected device to any of *its* nested guests? Not that the broken IOMMU code in said guest OS will know the latter, of course. With VIRTIO_F_IOMMU_PLATFORM set, VIRTIO_F_IOMMU_PASSTHROUGH is just a *hint*, suggesting that the guest OS s...

...al to not depend on linker scripts for the common case, not > having the functionality of fine grained output control is certainly a > problem. They are crucial for embedded developers and also at least > significant for anything near a system kernel. I’m not saying that the linker should eschew fine grained control, I’m saying it should dump linker scripts (and replace them with something better). Are you going to argue that linker scripts are great, or that they are what we would end up with if we weren’t driven by backwards compatibility goals? -Chris

...LATFORM????????????????34 > > OK... let's see if I can reconcile those descriptions coherently. > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > its own operating system's IOMMU code is expected to be broken, and > that the virtio driver should eschew the DMA API? No - it tells guest that e.g. the ACPI tables (or whatever the equivalent is) do not match reality with respect to this device since IOMMU is ignored by hypervisor. Hypervisor has no idea what does guest IOMMU code do - hopefully it is not actually broken. > And that the guest OS...

...most often associated with a composer but you may still > care who the performers or conductors were. A piece may > be split across several movements which may be even further > broken down into tracks on the source. This things are easily solved with vorbis comments ... Provided you eschew the specific instrument(s) performed. Obviously, Daniel's format has that going for it. -- -:-:- David K. Gasaway -:-:- Email: dave@gasaway.org -:-:- Web : dave.gasaway.org

On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote: > I'm not sure I understand the issue.??The public API is not about how > the driver works.??It doesn't say "don't use DMA API" anywhere, does it? > It's about telling device whether to obey the IOMMU and > about discovering whether a device is in fact under the IOMMU. Apologies, I was wrongly

Greetings, Have been looking at the specs of Boston Venom T4000. Boston Venom T4000 http://www.bostonindia.in/products/bos-t4000.aspx I could not figure out the lowest base price points, HA features and KVM support Yet to work out the storage part of say 8TB storage (with HA features, of course) for this beast. and accessability issues from devices. I am in the middle of trying to find out

On Mon, May 04, 2015 at 12:52:55PM -0700, Chris Lattner wrote: > I think the problem here is that these lead to natural and inescapable > tensions, and Alex summarized how Camp B has been steering LLD away > from what Camp A people want. This isn’t bad in and of itself, because > what Camp B wants is clearly and unarguably good for LLVM. However, > it is also not sufficient, and

On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > its own operating system's IOMMU code is expected to be broken, and > > that the virtio driver should eschew the DMA API? > > No - it tells guest that e.g. the ACPI tables (or whatever the > equivalent is) do not match reality with respect to this device > since IOMMU is ignored by hypervisor. > Hypervisor has no idea what does guest IOMMU code do - hopefully > it is not actually broken...

On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > its own operating system's IOMMU code is expected to be broken, and > > that the virtio driver should eschew the DMA API? > > No - it tells guest that e.g. the ACPI tables (or whatever the > equivalent is) do not match reality with respect to this device > since IOMMU is ignored by hypervisor. > Hypervisor has no idea what does guest IOMMU code do - hopefully > it is not actually broken...

...be terminated with semicolon. I don't really like the attitude that *I* have to follow *their* coding guidelines in my own code! If I'm contributing code to their project then I agree it's reasonable to expect adherence to their coding standards, but not just to use their library. By eschewing the standard idiom for wrapping multiline macro calls, they're forcing the risk of silent miscompilation on their users. Finally, they use UTF-16 as their internal representation whereas we want to use UTF-8. For the queryparser, this isn't an issue as there are macros for decoding UTF...

...rote: > On Mon, 2016-04-18 at 18:30 +0300, Michael S. Tsirkin wrote: > > > > > Setting (only) VIRTIO_F_IOMMU_PASSTHROUGH indicates to the guest that > > > its own operating system's IOMMU code is expected to be broken, and > > > that the virtio driver should eschew the DMA API? > > > > No - it tells guest that e.g. the ACPI tables (or whatever the > > equivalent is) do not match reality with respect to this device > > since IOMMU is ignored by hypervisor. > > Hypervisor has no idea what does guest IOMMU code do - hopefully >...

...Symfony php framework, which would provide SSO capabilities to browsers that are logged in an MS AD domain and support the NTLMv2 protocol. Ideally this module would run on linux servers, and be portable, i.e. require as few non-php tools and network/firewall settings as possible (that's why I eschewed the existing Apache modules which do Kerberos) So far I have working code which can generate, send, receive and decode the NTLMv2 messages. The only catch is that I cannot easily verify the autentication messages sent by the browser in response to the challenge messages that my app has sent, as...

..._stream throughput tests from a sender in the guest to a receiver in the host. To answer the other benchmark question first, I did not see anything noteworthy when increasing vq->num from 256 to 1024. With 1 and 10 flows without this patch all packets use zerocopy. With the patch, less than 1% eschews zerocopy. With 100 flows, even without this patch, 90+% of packets are copied. Some zerocopy packets from vhost_net fail this test in tun.c if (iov_iter_npages(&i, INT_MAX) <= MAX_SKB_FRAGS) Generating packets with up to 21 frags. I'm not sure yet why or what the fraction of thes...

..._stream throughput tests from a sender in the guest to a receiver in the host. To answer the other benchmark question first, I did not see anything noteworthy when increasing vq->num from 256 to 1024. With 1 and 10 flows without this patch all packets use zerocopy. With the patch, less than 1% eschews zerocopy. With 100 flows, even without this patch, 90+% of packets are copied. Some zerocopy packets from vhost_net fail this test in tun.c if (iov_iter_npages(&i, INT_MAX) <= MAX_SKB_FRAGS) Generating packets with up to 21 frags. I'm not sure yet why or what the fraction of thes...

On 6/17/20 6:23 AM, Richard W.M. Jones wrote: > I pushed 2 & 3, thanks. > > But ... > >> From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 >> From: Alan Somers <asomers@gmail.com> >> Date: Mon, 15 Jun 2020 16:59:53 -0600 >> Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level directory >> >> This is necessary

Export statistics for successful and failed huge page allocations from the virtio balloon driver. These 2 stats come directly from the vm_events HTLB_BUDDY_PGALLOC and HTLB_BUDDY_PGALLOC_FAIL. Signed-off-by: Jonathan Helman <jonathan.helman at oracle.com> --- drivers/virtio/virtio_balloon.c | 6 ++++++ include/uapi/linux/virtio_balloon.h | 4 +++- 2 files changed, 9 insertions(+), 1

Export statistics for successful and failed huge page allocations from the virtio balloon driver. These 2 stats come directly from the vm_events HTLB_BUDDY_PGALLOC and HTLB_BUDDY_PGALLOC_FAIL. Signed-off-by: Jonathan Helman <jonathan.helman at oracle.com> --- drivers/virtio/virtio_balloon.c | 6 ++++++ include/uapi/linux/virtio_balloon.h | 4 +++- 2 files changed, 9 insertions(+), 1

On 23/06/18 21:03, John R. Dennison wrote: > On Fri, Jun 22, 2018 at 04:58:21PM -0700, Karsten Wade wrote: >> * Is there a better page I can point at? > 'Better' is quite subjective; however this all goes back to > > https://web.archive.org/web/20060523223519/https://www.centos.org/modules/news/article.php?storyid=127 > > and is as good of a reference as any. >

Am 28.10.2015 um 16:17 schrieb Michael S. Tsirkin: > On Tue, Oct 27, 2015 at 11:38:57PM -0700, Andy Lutomirski wrote: >> This switches virtio to use the DMA API unconditionally. I'm sure >> it breaks things, but it seems to work on x86 using virtio-pci, with >> and without Xen, and using both the modern 1.0 variant and the >> legacy variant. > > I'm very