linux-kernel - Re: [Xen-devel] [PATCH 1/2] xen/swiotlb: If iommu=soft was not passed in on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Jul 2012 08:06:17 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Konrad Rzeszutek Wilk" <konrad@...nok.org>
Cc:	"xen-devel" <xen-devel@...ts.xen.org>,
	"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/2] xen/swiotlb: If iommu=soft was not
 passed in on > 4GB, don't turn it on.

>>> On 27.07.12 at 19:54, Konrad Rzeszutek Wilk <konrad@...nok.org> wrote:
> On Fri, Jul 27, 2012 at 08:27:39AM +0100, Jan Beulich wrote:
>> >>> On 26.07.12 at 22:43, Konrad Rzeszutek Wilk <konrad.wilk@...cle.com> wrote:
>> > +	/* Check if the user supplied the e820_hole parameter
>> > +	 * which would create a machine looking E820 region. */
>> > +	for (i = 0; i < e820.nr_map; i++) {
>> > +		if ((e820.map[i].type == E820_ACPI) ||
>> > +		    (e820.map[i].type == E820_NVS))
>> > +			return true;
>> 
>> Tying this decision to the presence of ACPI regions in E820 is
>> problematic for two reasons imo: For one, it precludes cleaning
>> up this (bogus!) construct where it gets produced (PV DomU-s
>> really shouldn't ever see such E820 entries, they should get
>> converted to simple reserved entries, to wipe any notion of
>> ACPI presence). And second it ties you to running on systems
>> that actually have ACPI, whereas it is my rudimentary
>> understanding that systems with e.g. SFI would not have any
>> ACPI).
> 
> Right. The other idea was to check the XenBus for the existence
> of vpci backend. But at this stage it is not up yet.
> 
> Perhaps what I should check for is the existence of two E820_RSV
> and two E820_RAM regions - and that would be a normal PV guest.
> Anything that is outside of that scope would be considered
> a PCI PV guest?

I'd limit this to two RAM and at least one reserved regions (after
all it could happen that all the reserved ones can be folded into
one). But beyond this minor detail that's the approach I'd prefer.
All the ones below look more or less fragile.

Jan

> The other thought I had was to skip this check altogether and
> either do:
> 1). initialize SWIOTLB when xen-pcifront start up and detects
>     that it has devices (so later on initialization - similar to
>     how IA64 does it) - but I am not sure how the PCI-DMA works
>     with these late bloomers (especially as one could just make
>     xen-pcifront be a module).
> 2). If xen-pcifront starts and does not detect any backends
>     it calls swiotlb_free. But that also requires the PCI-DMA
>     to swap in the dma_ops, and I am not entirely sure how
>     that would work out.
> 3). Have an "early_init" xen-pcifront components that does a
>     a quick XenBus init (similar to how hvmloader checks for
>     DMI overwrites) and if it finds vpci then declare its
>     time to turn SWIOTLB on.
> 4). The other thing is to wrap this code with something like
>     this:
> 
> #ifdef CONFIG_SWIOTLB
> #ifdef CONFIG_XEN_PCI_FRONTEND
> 	if (.. blah balh) do the check as outlined in 3).
> #else // PCI_FRONTEND is not present, so we won't need SWIOTLB
> 	swiotlb = 0;
> 	iommu = 1;
> #endif
> #endif
> 
> That would take care of the built-in issues.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/