On January 22, 2024 4:04:33 PM PST, Alexey Makhalov
wrote:
>
>
>On 1/22/24 10:28 AM, H. Peter Anvin wrote:
>> On January 22, 2024 8:32:22 AM PST, Dave Hansen
>> wrote:
>>> On 1/9/24 00:40, Alexey Makhalov wrote:
>>>> +#ifdef CONFIG_INTEL_TDX_GUES
On January 22, 2024 8:32:22 AM PST, Dave Hansen wrote:
>On 1/9/24 00:40, Alexey Makhalov wrote:
>> +#ifdef CONFIG_INTEL_TDX_GUEST
>> +unsigned long vmware_tdx_hypercall(unsigned long cmd,
>> + struct tdx_module_args *args)
>> +{
>> +if
to see BIOS output.
Add support for the 4321: device number in addition to the
1234: one.
Signed-off-by: H. Peter Anvin (Intel)
---
drivers/gpu/drm/tiny/bochs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index
On January 11, 2016 3:28:01 AM PST, Chris Wilson
wrote:
>On Sat, Jan 09, 2016 at 02:36:03PM -0800, Andy Lutomirski wrote:
>> On Sat, Jan 9, 2016 at 12:01 AM, Chris Wilson
> wrote:
>> > On Thu, Jan 07, 2016 at 02:32:23PM -0800, H. Peter Anvin wrote:
>> >> On 01/
On 01/07/16 14:32, H. Peter Anvin wrote:
>
> Nevermind. CLFLUSH is not ordered with regards to CLFLUSHOPT to the
> same cache line.
>
*Except* to the same cache line, dammit.
-hpa
On 01/07/16 14:29, H. Peter Anvin wrote:
>
> I would be very interested in knowing if replacing the final clflushopt
> with a clflush would resolve your problems (in which case the last mb()
> shouldn't be necessary either.)
>
Nevermind. CLFLUSH is not ordered with regard
that; I don't know if this is a compiler failure to do an
obvious hoisting (which should then be merged with the other load) or a
consequence of the volatile. It might be useful to report this to the
gcc bugzilla to let them look at it.
Either way, the diff looks good and you can add my:
Acked-
On 01/07/16 11:44, Chris Wilson wrote:
>
> Now I feel silly. Looking at the .s, there is no difference with the
> addition of the barrier to clflush_cache_range(). And sure enough
> letting the test run for longer, we see a failure. I fell for a placebo.
>
> The failing assertion is always on
On 06/19/2014 01:01 PM, Greg KH wrote:
> On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH
>> wrote:
>> + BUG_ON(f1->context != f2->context);
>
> Nice, you just crashed the kernel, making it impossible to debug or
>
gt;
>> Cc: David Airlie
>> Cc: dri-devel at lists.freedesktop.org
>> Cc: H Peter Anvin
>> Cc: Ingo Molnar
>> Cc: Thomas Gleixner
>
> Picked to my topic/core-stuff drm branch so it doesn't get lost.
> -Daniel
>
Does this mean you're picking this up, or do you want me to put it into
-tip?
-hpa
On 02/24/2014 12:19 PM, Borislav Petkov wrote:
> Btw,
>
> I don't know whether the following observation is related or not, but it
> so happens that after resume from suspend-to-disk, I see the booting up
> of the resume kernel on the console but when it is time for the original
> kernel to take
On 07/04/2013 05:25 AM, David Herrmann wrote:
> - What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
> (other than ARGB/XRGB32)
The common pixel formats on x86 are:
- Palettized 4-bit planar (bigendian, i.e. MSB to the left)
- Palettized 8-bit packed (one byte per
On 07/04/2013 05:25 AM, David Herrmann wrote:
- What FB formats are common on x86 that we should add to SIMPLEFB_FORMATS?
(other than ARGB/XRGB32)
The common pixel formats on x86 are:
- Palettized 4-bit planar (bigendian, i.e. MSB to the left)
- Palettized 8-bit packed (one byte per
The aliasing doesn't matter for Linux because we map the high and low half the
same.
Henrique de Moraes Holschuh wrote:
>On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>> >
>> > And as far as I could find fro
On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
>
> And as far as I could find from Intel's not-that-complete public
> "specification updates", we are applying the errata workaround to a few more
> processors than strictly required, but since I have no idea how to write a
> test case,
On 06/23/2013 01:54 PM, Dave Airlie wrote:
>>> breaking old boxes just because, is just going to get reverted when I
>>> get the first regression report that you broke old boxes.
>>>
>>
>> Not "just because", but *if* the choice is between breaking old boxes
>> and breaking new boxes I'll take the
On 06/23/2013 01:30 PM, Dave Airlie wrote:
Why do you care about performance when PAT is disabled?
>
> breaking old boxes just because, is just going to get reverted when I
> get the first regression report that you broke old boxes.
>
Not "just because", but *if* the choice is between
On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jun 2013, H. Peter Anvin wrote:
>> Why do you care about performance when PAT is disabled?
>
> It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
> nobody ever took the pain to tra
Why do you care about performance when PAT is disabled?
Brice Goglin wrote:
>Le 21/06/2013 07:00, H. Peter Anvin a ?crit :
>> An awful lot of drivers, mostly DRI drivers, are still mucking with
>> MTRRs directly as opposed to using ioremap_wc() or similar
>interfac
Why do you care about performance when PAT is disabled?
Brice Goglin brice.gog...@gmail.com wrote:
Le 21/06/2013 07:00, H. Peter Anvin a écrit :
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar
interfaces
On 06/23/2013 12:29 PM, Henrique de Moraes Holschuh wrote:
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
Why do you care about performance when PAT is disabled?
It will regress already slow boxes. We blacklist a LOT of P4s, PMs, etc and
nobody ever took the pain to track down which ones
On 06/23/2013 01:30 PM, Dave Airlie wrote:
Why do you care about performance when PAT is disabled?
breaking old boxes just because, is just going to get reverted when I
get the first regression report that you broke old boxes.
Not just because, but *if* the choice is between breaking old
On 06/23/2013 01:54 PM, Dave Airlie wrote:
breaking old boxes just because, is just going to get reverted when I
get the first regression report that you broke old boxes.
Not just because, but *if* the choice is between breaking old boxes
and breaking new boxes I'll take the latter.
But
The aliasing doesn't matter for Linux because we map the high and low half the
same.
Henrique de Moraes Holschuh h...@hmh.eng.br wrote:
On Sun, 23 Jun 2013, H. Peter Anvin wrote:
On 06/23/2013 02:56 PM, Henrique de Moraes Holschuh wrote:
And as far as I could find from Intel's
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
An awful lot of drivers, mostly DRI drivers, are still mucking with
MTRRs directly as opposed to using ioremap_wc() or similar interfaces.
In addition to the architecture dependency, this is really undesirable
because MTRRs are a limited resource, whereas page table attributes are not.
The problem is that the code will be broken, and so it makes no sense. The #if
0 is really confusing.
Daniel Vetter wrote:
>On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
>> On 03/07/2013 09:28 PM, Tejun Heo wrote:
>> > On Thu, Mar 7, 2013 at 9:27 PM,
The problem is that the code will be broken, and so it makes no sense. The #if
0 is really confusing.
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Mar 07, 2013 at 10:09:26PM -0800, H. Peter Anvin wrote:
On 03/07/2013 09:28 PM, Tejun Heo wrote:
On Thu, Mar 7, 2013 at 9:27 PM, Yinghai Lu ying
ve it alone. Maybe add a comment.
> The change is just making things more confusing.
>
Indeed, but...
Daniel: can you guys clean this up or can we just remove the #if 0 clause?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
a comment.
The change is just making things more confusing.
Indeed, but...
Daniel: can you guys clean this up or can we just remove the #if 0 clause?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf
It would be nice to support more than 512 characters when using a graphical
console. We should be able to support up to 2048 at least.
Dave Airlie wrote:
>On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin wrote:
>> The characters will morph anyway, it is just a matter off ha
Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin wrote:
>> We should clear this bit presumably on switching either from or to
>512-char mode, since the bit doesn't really make sense either way.
>
>Yeah the only problem going from 512-char is that chars above 256 will
>morph into garbage
wrote:
On Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin h...@zytor.com wrote:
We should clear this bit presumably on switching either from or to
512-char mode, since the bit doesn't really make sense either way.
Yeah the only problem going from 512-char is that chars above 256 will
morph
It would be nice to support more than 512 characters when using a graphical
console. We should be able to support up to 2048 at least.
Dave Airlie airl...@gmail.com wrote:
On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin h...@zytor.com wrote:
The characters will morph anyway, it is just
We should clear this bit presumably on switching either from or to 512-char
mode, since the bit doesn't really make sense either way.
Dave Airlie wrote:
>From: Dave Airlie
>
>When we switch from 256->512 byte font rendering mode, it means the
>current contents of the screen is being
e-removal-schedule.txt, not
all at once due to some arbitrary milestone.
We have found it works better this way.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
to some arbitrary milestone.
We have found it works better this way.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
On 05/23/2011 04:17 PM, Ted Ts'o wrote:
> On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
>> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>>
>>> I really hope there's also a voice that tells you to wait until .42 before
>>> cutting 3.0.0! :-)
>>
>> So I'm toying with 3.0
On 04/15/2011 12:18 PM, Yinghai Lu wrote:
> On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
>>
>> Joerg, mind submitting it with a changelog that includes everything we
>> learned
>> about this bug and all the Tested-by's in place?
>>
>> Is anyone of the opinion that we should try to revert the
hes.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
lready. Not the
> droids.
>
> the num cpu pages is how many CPU pages would be needed to fill the GPU
> GTT, for those crazy cases where CPU pagesize != GPU pagesize.
>
OK, well, something is still weird.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
to fill the GPU
GTT, for those crazy cases where CPU pagesize != GPU pagesize.
OK, well, something is still weird.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
dri-devel
. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
blem that is manifesting itself
in other ways on other systems.
The other thing that this has uncovered is that we already have a bunch
of complete b*llsh*t magic numbers in this path, some of which are
trivially shown to be wrong or at least completely arbitrary, so there
are more issues here :(
00aff0 (usable)
>
> so looks bios program wrong address to the radon card?
>
Okay, staring at this, it definitely seems toxic to overlay the GART
over memory areas reserved by the BIOS. If I were to guess, I would say
that the problem here seems to be that the kernel thinks it is
overlaying
On 04/13/2011 03:22 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
>> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>>> - addr = memblock_find_in_range(0, 1
On 04/13/2011 02:59 PM, Yinghai Lu wrote:
> On 04/13/2011 02:50 PM, Joerg Roedel wrote:
>> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>>> - addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>>> + addr = memblock_find_in_range(0, 1ULL<<32, aper_size,
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>> -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
>
> Btw, while looking at this code I
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
>
> First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
> only a couple of patches and merged v2.6.38-rc4 in at every step. There
> was no failure found.
> Then I tried this again, but this time I merged v2.6.38-rc5 at every
> step
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
>> Could you please send the before/after bootlog (in particular all memory
>> init
>> messages included) and your .config?
>>
>> before: f005fe12b90c: x86-64: Move out cleanup higmap
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
First of all, I bisected between v2.6.37-rc2..f005fe12b90c which where
only a couple of patches and merged v2.6.38-rc4 in at every step. There
was no failure found.
Then I tried this again, but this time I merged v2.6.38-rc5 at every
step and was
On 04/13/2011 10:21 AM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 08:46:09AM +0200, Ingo Molnar wrote:
Could you please send the before/after bootlog (in particular all memory
init
messages included) and your .config?
before: f005fe12b90c: x86-64: Move out cleanup higmap [_brk_end,
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
-addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while looking at this code I wondered why the
On 04/13/2011 02:59 PM, Yinghai Lu wrote:
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
- addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+ addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
Btw, while
On 04/13/2011 03:22 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 03:01:10PM -0700, H. Peter Anvin wrote:
On 04/13/2011 02:50 PM, Joerg Roedel wrote:
On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
- addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+ addr
of memory, but the actual GART is in fact 512 MiB in
size -- 131072 CPU pages -- which now overlaps the BIOS reserved areas.
Alex D., could you comment on the num cpu pages bit?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf
a bunch
of complete b*llsh*t magic numbers in this path, some of which are
trivially shown to be wrong or at least completely arbitrary, so there
are more issues here :(
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf
57 matches
Mail list logo
