On Sun, 28 Aug 2016 23:36:20 -0700 Benjamin Serebrin <serebrin@xxxxxxxxxx> wrote: > Thanks, all, > > The general view from last week is to pursue an ACPI table that > indicates that the SWIOTLB isn't needed. I'll work with our local > ACPI experts on table format. Isn't SWIOTLB linux specific impl. detail? Suppose guest is started without SWIOTLB and later user hotplugs a device that not capable to handle high mem, what's then? Wouldn't it be better to make SWIOTLB created/allocated on demand in kernel (i.e. presence of devices that require it) instead of making hardware(hypervisor) to provide some obscure ACPI table quirk to fix kernel issue? > > For existing guests, we'll work on language suggesting kernel command > line options (iommu=off) if people are concerned, and will look into > doing the command line setting in our own provided images. > > On Thu, Aug 25, 2016 at 7:45 PM, Wanpeng Li <kernellwp@xxxxxxxxx> wrote: > > 2016-08-26 9:16 GMT+08:00 Yang Zhang <yang.zhang.wz@xxxxxxxxx>: > >> On 2016/8/24 22:36, Benjamin Serebrin wrote: > >>> > >>> iommu=off would kill the SWIOTLB as well, while swiotlb=1 consumes 1MB. > >>> > >>> However, maintaining guests' kernel commandlines is something we'd > >>> like to stay away from if possible. It's certainly a short-term > >> > >> > >> I don't quite understand why stay away from kernel command line. It provides > >> more flexibility, allowing you to turn on/off it by yourself. > > > > I agree with Benjamin, it will result in customers have to tune their > > guest OSes kernel command line or we supply guest images w/ kernel > > command line modification. > > > > Regards, > > Wanpeng Li > > > >> > >> > >>> answer, or something individual customers can choose to do today. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
