On Wed, 2017-02-22 at 10:14 -0500, Boris Ostrovsky wrote:
> On 02/22/2017 09:28 AM, Bjorn Helgaas wrote:
> >
> > On Tue, Feb 21, 2017 at 10:58:39AM -0500, Boris Ostrovsky wrote:
> > >
> > > On 02/21/2017 10:45 AM, Juergen Gross wrote:
> > > >
> > > > On 21/02/17 16:31, Dan Streetman wrote:
> > >
From: David Woodhouse
This includes stuff lke the hypercall tables which we really want
to be read-only. And they were going into .data.read-mostly.
Signed-off-by: David Woodhouse
---
Build tested on x86_64 (you really don't want to know about what I
*actually* tested it with), not a
From: David Woodhouse
This includes stuff like the hypercall tables which we really kind of want
to be read-only. And they were going into .data.read-mostly.
Signed-off-by: David Woodhouse
Reviewed-by: Wei Liu
Acked-by: Julien Grall
Acked-by: Andrew Cooper
---
Fixed typo, collected acks
On Sun, 2017-07-30 at 13:50 +0100, Andrew Cooper wrote:
> On 30/07/17 07:16, Jan Beulich wrote:
> >
> > >
> > > >
> > > > >
> > > > > David Woodhouse 07/20/17 5:22 PM >>>
> > > This includes stuff lke the hyperca
On Mon, 2017-07-31 at 03:57 -0600, Jan Beulich wrote:
> Are there any such relocations? The compiler shouldn't emit data needing
> relocation to .rodata, so if at all such might live in assembly code. But yes,
> if there are any, things would have been latently broken even before.
$ git diff 33a
On Sun, 2017-07-30 at 00:16 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > David Woodhouse 07/20/17 5:22 PM >>>
> > This includes stuff lke the hypercall tables which we really want
> > to be read-only. And they were going into .
On Mon, 2017-07-31 at 07:15 -0600, Jan Beulich wrote:
> > > > David Woodhouse 07/31/17 1:02 PM >>>
> > On Sun, 2017-07-30 at 00:16 -0600, Jan Beulich wrote:
> > > > > > David Woodhouse 07/20/17 5:22 PM >>>
> > > > This includes
protection when ExitBootServices() is called, because it
knows we're going to need to do this kind of thing.
Signed-off-by: David Woodhouse
---
This basically means that new versions of UEFI are going to break
(all?) existing EFI Xen versions? Or at least any that have relocations
in .init.text
On Wed, 2017-08-02 at 03:17 -0600, Jan Beulich wrote:
>
> >... but then again, if the whole function is really doing nothing at
> >all when invoked with delta==0 then perhaps it would just be easier to
> >remove the first pass altogether. I feel sure I'm missing something,
>
> The reason is even
On Wed, 2017-08-02 at 05:56 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > David Woodhouse 08/02/17 1:30 PM >>>
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -87,7 +87,8 @@ static void
On Wed, 2017-08-02 at 07:58 -0600, Jan Beulich wrote:
> > > > David Woodhouse 08/02/17 2:11 PM >>>
> > This change is sufficient (we believe) to make EFI builds of Xen
> > actually boot again on current EDK2, is it not?
>
> It is safe / sufficient only wit
On Wed, 2017-08-02 at 09:16 -0600, Jan Beulich wrote:
>
> Well, I've seen breakage in all sorts of places I wouldn't have expected
> anyone to fine a need to fiddle with.
This is the nature of 'value subtract', I suppose.
How about something like this? Somewhat complicated by the fact that
COFF
On Thu, 2017-01-26 at 14:50 +, David Woodhouse wrote:
>
> Finally, add a comment clarifying how that 'return -1' works — it isn't
> returning an error and causing the mapping to fail; it relies on…
Btw, something odd happened when committing this. That U+2014 emdash i
On Thu, 2017-02-09 at 01:56 -0700, Jan Beulich wrote:
>
> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> > index 86c71be..3d9386a 100644
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d, unsigned
On Thu, 2017-02-09 at 11:54 +0800, Chao Gao wrote:
>
> Jan is right. When the assertion fails, the value of gfn is 0xfee00.
>
> Do you mean that is_iomem_page() is equal to direct_mmio except some
> corner cases such as APIC access MFN and INVALID_MFN( any others? ) ?
That was the hypothesis, an
> x86: enforce consistent cachability of MMIO mappings
>
> We've been told by Intel that inconsistent cachability between
> multiple mappings of the same page can affect system stability only
> when the affected page is an MMIO one. Since the stale data issue is
> of no relevance to the hypervisor
On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
> Note the difference between "contains" and "overlaps".
Oh, that makes more sense; thanks.
> > And then there's a 'if (direct_mmio) return UC;' further down which
> > looks like it'd do the right thing for the use case I'm actually
> > testin
On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
>
> If there wasn't INVALID_MFN to be taken care of, the !mfn_valid()
> check could simply move down, and be combined with the
> direct_mmio one.
As discussed on IRC, once we fix the overflow with order > 0, I think
INVALID_MFN is OK. Not that
From: David Woodhouse
Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce
consistent cachability of MMIO mappings"), HVM guests have no longer
been able to use PAT to obtain write-combining on MMIO because the
'ignore PAT' bit is set in EPT.
For MMIO we shou
On Thu, 2017-01-26 at 03:45 -0700, Jan Beulich wrote:
>
> This is too broad a statement: MMIO pages for which mfn_valid()
> is true would still allow WC use.
... where mfn_valid() would be true for MMIO regions in the low memory
hole, but not for regions above all physical memory?
> The only oth
From: David Woodhouse
For some MMIO regions, such as those high above RAM, mfn_valid() will
return false.
Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce
consistent cachability of MMIO mappings"), guests have no longer been
able to use PAT to obtain write-combini
On Thu, 2017-01-26 at 07:35 -0700, Jan Beulich wrote:
>
> Hmm, didn't you say you'd take care of the hard tabs?
Er... yes. But it seems I neglected to specify whether I would also
*save* the resulting file, 'git commit --amend', and actually send that
version. Sorry.
smime.p7s
Description: S/MIM
From: David Woodhouse
For some MMIO regions, such as those high above RAM, mfn_valid() will
return false.
Since the fix for XSA-154 in commit c61a6f74f80e ("x86: enforce
consistent cachability of MMIO mappings"), guests have no longer been
able to use PAT to obtain write-combini
On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
>
> Well, in the context of this XSA we've asked both of them, and iirc
> we've got a vague reply from Intel and none from AMD. In fact we
> did defer the XSA for quite a bit waiting for any useful feedback.
> To AMD's advantage I'd like to add
On Fri, 2017-01-27 at 10:36 -0500, Konrad Rzeszutek Wilk wrote:
> . snip ..
> >
> > >
> > > Signed-off-by: David Woodhouse
> > Reviewed-by: Jan Beulich
> >
> > But before committing I'd prefer to have a VMX maintainer ack
> > too.
>
On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 06.02.17 at 14:55, wrote:
> > Switch its return type to bool to match its use, and simplify the
> > ARM
> > implementation slightly.
> >
> > No functional change.
> >
> > Signed-off-by: Andrew Cooper
> Reviewe
On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> This ports built-in firmware to use linker tables,
> this replaces the custom section solution with a
> generic solution.
>
> This also demos the use of the .rodata (SECTION_RO)
> linker tables.
>
> Tested with 0 built-in firmware, 1 a
ffected architectures could provide (as a prelude to fixing it so that
the DMA API does the right thing for *itself*)?
It would be functionally equivalent, but it would help to push the
workarounds to the right place — rather than entrenching them for ever
in tricky "OMG we need to audit what al
of
> principle. I'd also like to flip as many arches over as possible, but
> that could be trickier. Let me mull over this.
Let's queue the arch_vring_eschew_dma_api() thing up after this first
batch, and not hold it up any further.
--
David Woodhouse
cel whatever abominations
the HP firmware tends to set up behind the OS's back on other PCI
devices, we can cancel the RMRRs for those too.
Then the IOMMU code has a simple choice and no special cases — we can
assign a device iff it has no active RMRR.
--
David Woodhouse
ase... what *do* we have to do? Does the VMM (and the
VM's BIOS, between them) have to provision a "stolen" region of guest
memory and point the gfx framebuffer at that?
Once we have a proper handle on precisely what needs to happen, we can
have a better conversation about where/ho
On Wed, 2016-02-17 at 11:29 +0200, Michael S. Tsirkin wrote:
>
> I was hoping for an explicit ack from David Woodhouse,
> but I guess the informal "let's not hold this up"
> that was sent on v5 will do.
Apologies; I was working under that assumption too.
--
dwmw2
pt-
in-simulation issues with VT-d IOMMU covering *some* devices but not
all.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
33 matches
Mail list logo
