On November 27, 2022 7:03:20 PM PST, Hou Wenlong
wrote:
>On Sun, Nov 27, 2022 at 09:24:34AM -0800, H. Peter Anvin wrote:
>> On November 24, 2022 3:51:53 AM PST, Hou Wenlong
>> wrote:
>> >Similar to the alternative patching, use relative reference for original
>
On November 24, 2022 3:51:53 AM PST, Hou Wenlong
wrote:
>Similar to the alternative patching, use relative reference for original
>instruction rather than absolute one, which saves 8 bytes for one entry
>on x86_64. And it could generate R_X86_64_PC32 relocation instead of
>R_X86_64_64
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 2020-03-04 11:19, Thomas Garnier wrote:
>>
>> The huge memory model, required for arbitrary placement, has a very
>> significant performance impact.
>
> I assume you mean mcmodel=large, it doesn't use it. It uses -fPIE and
> removes -mcmodel=kernel. It favors relative references whenever
>
On 2020-03-04 10:21, Kees Cook wrote:
> On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote:
>> But at what cost; it does unspeakable ugly to the asm. And didn't a
>> kernel compiled with the extended PIE range produce a measurably slower
>> kernel due to all the ugly?
>
> Was that
On 06/14/18 13:59, Nick Desaulniers wrote:
> On Thu, Jun 14, 2018 at 1:48 PM H. Peter Anvin wrote:
>>
>> On 06/13/18 14:05, Nick Desaulniers wrote:
>>> From: "H. Peter Anvin"
>>>
>>> i386 and x86-64 uses different registers for arguments
On 06/13/18 14:05, Nick Desaulniers wrote:
> From: "H. Peter Anvin"
>
> i386 and x86-64 uses different registers for arguments; make them
> available so we don't have to #ifdef in the actual code.
>
> Native size and specified size (q, l, w, b) versions are provid
On 06/12/18 13:19, Nick Desaulniers wrote:
>
> Oh, by [0] __GCC_STDC_INLINE__ is indeed actually the correct symbol
> to check for. Clang does support that, so nothing to fix there.
>
>> By the way, you should check clang against gcc's predefined macros by doing:
>>
>> gcc [options] -x c
les have removed an explicit C standard compiler flag for users
>of GCC
>> >> 5.1+ or Clang.
>> >>
>> >> Signed-off-by: Nick Desaulniers
>> >> Suggested-by: H. Peter Anvin
>> >> Suggested-by: Joe Perches
>> >
>> > I s
On 06/07/18 11:32, Nick Desaulniers wrote:
>
> Suggested-by: Sedat Dilek
If this was suggested by Sedat, I didn't see that suggestion...
-hpa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On 06/05/18 10:28, H. Peter Anvin wrote:
> On 06/05/18 10:05, Nick Desaulniers wrote:
>> +
>> +/*
>> + * void native_restore_fl(unsigned long flags)
>> + * %rdi: flags
>> + */
>> +ENTRY(native_restore_fl)
>> +push %_ASM_DI
>>
On 10/04/17 08:58, Josh Poimboeuf wrote:
> Add alternative patching support for replacing an instruction with an
> indirect call. This will be needed for the paravirt alternatives.
I have a patchset that generalizes the alternatives in what I think is a
more robust way. I really, really want to
On 01/26/16 00:20, Michael S. Tsirkin wrote:
> On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote:
>
> Hi hpa,
> Any luck getting some feedback on this one?
>
Yes. What we know so far is that *most* cases it will work, but there
are apparently a few corner cas
On 01/12/16 14:21, Michael S. Tsirkin wrote:
>
> OK so I'll have to tweak the test to put something
> on stack to measure the difference: my test tweaks a
> global variable instead.
> I'll try that by tomorrow.
>
> I couldn't measure any difference between mfence and lock+addl
> except in a
On 01/12/16 14:10, Michael S. Tsirkin wrote:
> mb() typically uses mfence on modern x86, but a micro-benchmark shows that
> it's
> 2 to 3 times slower than lock; addl $0,(%%e/rsp) that we use on older CPUs.
>
> So let's use the locked variant everywhere - helps keep the code simple as
> well.
>
On 12/01/15 14:18, Sinclair Yeh wrote:
> These macros will be used by multiple VMWare modules for handling
> host communication.
> + __asm__ __volatile__ ("inl %%dx" : \
This is odd at best; the standard assembly form of this instruction is:
inl
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list. For example, KVM might place
its KVMKVMKVM signature first in the
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list. For example, KVM might place
its KVMKVMKVM signature first in the
On 10/29/2014 03:37 AM, Andrew Cooper wrote:
CPUID with EAX = 0x4F01 and ECX = N MUST return all zeros.
To the extent that the hypervisor prefers a given interface, it should
specify that interface earlier in the list. For example, KVM might place
its KVMKVMKVM signature first in the
On 09/22/2014 06:31 AM, Christopher Covington wrote:
On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM, it is very easy just to
emulate the RDRAND instruction. The hypervisor would report to the guest
On 09/22/2014 07:17 AM, H. Peter Anvin wrote:
It could, but how would you enumerate that? A new RDRAND-CPL-0 CPUID
bit pretty much would be required.
Note that there are two things that differ: the CPL 0-ness and the
performance/exhaustibility attributes.
-hpa
Not really, no.
Sent from my tablet, pardon any formatting problems.
On Sep 22, 2014, at 06:31, Christopher Covington c...@codeaurora.org wrote:
On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like kASLR.
-hpa
___
Virtualization mailing list
On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
I slept on it, and I think using the CPUID instruction alone would be
simple and efficient:
- We have a huge space for CPUID leaves
- CPUID also works for user-level
- It can take an additional 32-bit parameter (ECX), and returns 4
32-bit values
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior it runs on very early
Not anywhere close to early enough. We're talking for uses like kASLR.
Still to early
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior
On 09/19/2014 10:15 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:53 AM, Gleb Natapov wrote:
On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote:
On 09/19/2014 09:37 AM, Gleb Natapov wrote:
Linux detects what hypervior
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.
We can always make cpuid on the leaf in question return all zeros if CPL 0.
Not sure that is better...
-hpa
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM, it is very easy just to
emulate the RDRAND instruction. The hypervisor would report to the guest
that RDRAND is supported in CPUID and the emulate the instruction when guest
executes it. KVM
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
To force deterministic execution.
I incorrectly thought that the kernel could switch RDRAND on and off.
It turns out that a hypervisor can do this, but not the kernel. Also,
determinism is lost anyway because of TSX, which *also* can't be
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
To force deterministic execution.
I incorrectly thought that the kernel could switch RDRAND on and off.
It turns out that a hypervisor can do this, but not the kernel. Also,
determinism is lost anyway because of TSX, which *also* can't be
On 09/19/2014 04:35 PM, Theodore Ts'o wrote:
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
Right, but if the host
On 09/18/2014 07:40 AM, KY Srinivasan wrote:
The main questions are what MSR index to use and how to detect the
presence of the MSR. I've played with two approaches:
1. Use CPUID to detect the presence of this feature. This is very easy for
KVM to implement by using a KVM-specific CPUID
Srinivasan
Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb
Natapov; Niels
Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake
Oshins; Linux
Virtualization
Subject: Re: Standardizing an MSR or other hypercall to get an RNG
seed?
Il 18/09/2014 19:13, Nakajima, Jun ha
On 09/18/2014 02:46 PM, David Hepkin wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that each
hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID
range, and an OS has to do a full scan of this CPUID range on boot to find
it? That seems
On 09/18/2014 03:00 PM, Andy Lutomirski wrote:
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that
each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f
CPUID range, and an OS
On 08/27/2014 12:00 AM, Paolo Bonzini wrote:
Il 27/08/2014 01:58, Andy Lutomirski ha scritto:
hpa pointed out that the ABI that I chose (an MSR from the KVM range
and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice
to allocate an MSR that everyone involved can agree on and,
On 08/11/2014 10:27 PM, Amit Shah wrote:
On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote:
On 08/11/2014 11:49 AM, Amit Shah wrote:
The khwrngd thread is started when a hwrng device of sufficient
quality is registered. The virtio-rng device is backed by the
hypervisor, and we trust
On 08/11/2014 06:30 AM, Torsten Duwe wrote:
On Mon, Aug 11, 2014 at 12:45:27PM +0530, Amit Shah wrote:
What's the suggested value for rng-quality, though, for virtio-rng
that I can use to ensure the kthread starts?
Should I use the 700 (70%) as proposed in the original patchset? I'm
not
On 08/11/2014 11:49 AM, Amit Shah wrote:
The khwrngd thread is started when a hwrng device of sufficient
quality is registered. The virtio-rng device is backed by the
hypervisor, and we trust the hypervisor to provide real entropy. A
malicious hypervisor is a scenario that's ruled out, so we
On 08/08/2014 02:07 AM, Amit Shah wrote:
To
some degree the above is obsolete when we get khwrngd widely deployed,
but that is a new-kernel-only kind of thing.
Right - I'm wondering if any such changes as propsed here are now
obsolted already by khwrngd?
In this case, yes, khwrngd
On 08/07/2014 06:08 AM, Amit Shah wrote:
On KVM guests where the virtio-rng device is available, and set as the
current rng, this udev rule will start rngd which will feed in the
host-provided entropy to /dev/random.
Signed-off-by: Amit Shah amit.s...@redhat.com
---
90-virtio-rng.rules |
On 07/28/2014 12:04 PM, Eduardo Habkost wrote:
When CONFIG_PARAVIRT is enabled, the kernel is ignoring exceptions on
the {rd,wr}msr instructions. This makes serious issues (either on the
guest kernel, or on the host) be silently ignored, and is different from
the native MSR code (which does
As much as I hate adding new pvops, it might be the better answer, especially
since those are the real native ops.
On July 28, 2014 1:39:55 PM PDT, Eduardo Habkost ehabk...@redhat.com wrote:
On Mon, Jul 28, 2014 at 12:18:10PM -0700, H. Peter Anvin wrote:
On 07/28/2014 12:04 PM, Eduardo Habkost
I have gotten scattered reports of strange problems caused by the fact
that virtio_console doesn't behave like a normal tty (support termios
and so on.) This seems to be an odd restriction -- is there any
fundamental reason for this design choice?
-hpa
On 06/12/2014 06:06 PM, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
I have gotten scattered reports of strange problems caused by the fact
that virtio_console doesn't behave like a normal tty (support termios
and so on.) This seems to be an odd restriction -- is there any
On 03/20/2014 03:01 PM, Paolo Bonzini wrote:
No! Please do what I asked you to do. You are not handling Hyper-V or
VMWare. Just use X86_FEATURE_HYPERVISOR and it will cover all
hypervisors that actually follow Intel's guidelines.
And for those that don't, we should turn on
On 11/26/2013 10:15 AM, Ashutosh Dixit wrote:
Avoid declaring ALIGN() and __aligned() in
include/uapi/linux/mic_common.h since they pollute user space
namespace. Also, mic_aligned_size() can be simply replaced simply by
sizeof() since all structures where mic_aligned_size() is used are
On 10/30/2013 03:22 PM, Kees Cook wrote:
- /*
-* sizeof(unsigned long) coming from an extra long at the end
-* of the iobitmap. See tss_struct definition in processor.h
-*
-* -1? seg base+limit should be pointing to the address of the
-* last
On 09/04/2013 01:53 AM, Alok Kataria wrote:
Hey,
This change adds an entry to the maintainers file to explicitly state
that any changes to vmware.c should be sent to the authors of the file
as well.
If you are thinking why do this now, off late we have seen quite a few
changes that
On 08/09/2013 06:00 AM, Konrad Rzeszutek Wilk wrote:
On Fri, Aug 09, 2013 at 06:20:02PM +0530, Raghavendra K T wrote:
On 08/09/2013 04:34 AM, H. Peter Anvin wrote:
Okay, I figured it out.
One of several problems with the formatting of this patchset is that it
has one- and two-digit patch
On 08/07/2013 06:02 PM, Gleb Natapov wrote:
On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote:
On 08/07/2013 10:18 AM, H. Peter Anvin wrote:
Please let me know, if I should rebase again.
tip:master
On 08/08/2013 02:13 PM, H. Peter Anvin wrote:
On 08/07/2013 06:02 PM, Gleb Natapov wrote:
On Wed, Aug 07, 2013 at 08:50:12PM -0400, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 07, 2013 at 12:15:21PM +0530, Raghavendra K T wrote:
On 08/07/2013 10:18 AM, H. Peter Anvin wrote:
Please let me know
The kbuild test bot is reporting some pretty serious errors for this
patchset. I think these are serious enough that the patchset will need
to be respun.
-hpa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On 08/06/2013 04:40 AM, Raghavendra K T wrote:
This series replaces the existing paravirtualized spinlock mechanism
with a paravirtualized ticketlock mechanism. The series provides
implementation for both Xen and KVM.
The current set of patches are for Xen/x86 spinlock/KVM guest side, to be
On 08/06/2013 07:54 PM, Raghavendra K T wrote:
On 08/07/2013 02:31 AM, H. Peter Anvin wrote:
What is the baseline for this patchset? I tried to apply it on top of
3.11-rc4 and I got nontrivial conflicts.
I had based it on top of 445363e8 [ Merge branch 'perf/urgent']
of tip. Sorry
On 08/05/2013 07:34 AM, Konrad Rzeszutek Wilk wrote:
Could you provide me with a git branch so I can test it overnight please?
Pull tip:x86/paravirt.
-hpa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
So, having read through the entire thread I *think* this is what the
status of this patchset is:
1. Patches 1-17 are noncontroversial, Raghavendra is going to send an
update split into two patchsets;
2. There are at least two versions of patch 15; I think the PATCH
RESEND RFC is the right
On 07/22/2013 10:20 AM, Eric W. Biederman wrote:
Also, in any virtualized environment the hypervisor can do a better job
for things like kdump, simply because it can provide two things that are
otherwise hard to do:
1. a known-good system state;
2. a known-clean kdump image.
As such, I do
On 07/22/2013 11:33 AM, Greg KH wrote:
I don't care about kdump, I care about kexec on domU for people who are
running on cloud providers with old versions of Xen so that they can
control what kernel they can boot, when they want to boot it. If kdump
works as well, that's just a bonus, but
On 07/19/2013 12:14 PM, Greg KH wrote:
The errors that the kexec tools seem to run into is finding the memory
to place the new kernel into, is that just an issue that PV guests
aren't given enough kernel memory in which to replicate themselves from
dom0?
There are a lot of differences
On 07/11/2013 03:08 AM, Paul Bolle wrote:
On Mon, 2013-07-08 at 20:26 -0400, Konrad Rzeszutek Wilk wrote:
Could you explain to me please why the check in the scripts is
superfluous?
The discussion has since moved on a bit, but I haven't answered this
question yet.
The check grub2
On 07/09/2013 08:05 AM, Borislav Petkov wrote:
On Tue, Jul 09, 2013 at 10:48:40AM -0400, Konrad Rzeszutek Wilk wrote:
Then that should be discussed on grub2 to remove said check and modify
the code so that it can properly work without regression.
Actually, the kernel patch removing that
On 07/09/2013 03:34 PM, Sander Eikelenboom wrote:
Grub does this in it's update script to prevent adding a xen + kernel
combination that has no chance of booting when dom0 support has not been
configured in the kernel.
That doesn't seem to be a unreasonable thought.
Except it does it
On 07/08/2013 12:28 PM, Konrad Rzeszutek Wilk wrote:
On Mon, Jul 08, 2013 at 08:28:24AM +0200, Michael Opdenacker wrote:
This patch proposes to remove the XEN_PRIVILEGED_GUEST kernel
configuration parameter defined in arch/x86/xen/Kconfig, but used
nowhere in the makefiles and source code.
On 07/08/2013 12:34 PM, Matt Wilson wrote:
For reference, here's a related Debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633127
Summary: grub2 scripts parse /boot/config-$(uname -r)
What. The. Fuck.
-hpa
___
On 04/29/2013 07:48 AM, Don Dutile wrote:
c) it's architecture neutral, or can be made architecture neutral.
e.g., inb/outb PCI ioport support is very different btwn x86
non-x86.
A hypercall interface would not have that dependency/difference.
You are joking, right? Hypercalls
Kees posted that one too.
Andi Kleen a...@firstfloor.org wrote:
Ingo Molnar mi...@kernel.org writes:
This looks very nice to me now. Peter, any objections?
it seems pointless without randomized main kernel text location,
because
the IDT will be still at a known per kernel fixed writable
Right... the TSS does get written to during a task switch.
Jan Beulich jbeul...@suse.com wrote:
On 10.04.13 at 02:43, H. Peter Anvin h...@zytor.com wrote:
OK, thinking about the GDT here.
The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
such, we probably don't want
On 04/10/2013 09:31 AM, Eric Northup wrote:
If the effect is measurable I agree it is a legitimate optimization. At
one point there was a suggestion to make the code in the IDT vectors
differ based on the which interrupt was registed. While that can also
reduce cache misses that can get
On 04/10/2013 02:42 AM, Jan Beulich wrote:
However, the packing solution has the advantage of reducing address
space consumption which matters on 32 bits: even on i386 we can easily
burn a megabyte of address space for 4096 processors, but burning 16
megabytes starts to hurt.
Packing
. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
with those addresses.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org
the question if we need to randomize kmalloc... which could
have issues by itself.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Virtualization mailing list
Virtualization@lists.linux
On 04/09/2013 11:54 AM, Eric Northup wrote:
The GDT is a problem if the address returned by 'sgdt' is
kernel-writable - it doesn't necessarily reveal the random offset, but
I'm pretty sure that writing to the GDT could cause privilege
escalation.
That is a pretty safe assumption...
On 04/09/2013 11:22 AM, Kees Cook wrote:
Can we create a RO fixed per-cpu area?
Fixed and percpu are mutually exclusive...
-hpa
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On 04/09/2013 09:39 AM, Kees Cook wrote:
-
static void __cpuinit intel_smp_check(struct cpuinfo_x86 *c)
{
/* calling is from identify_secondary_cpu() ? */
@@ -206,8 +192,7 @@ static void __cpuinit intel_workarounds(struct
cpuinfo_x86 *c)
/*
* All current models of
megabytes starts to hurt.
It would be important to measure the performance impact on task switch,
though.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Virtualization mailing
On 04/09/2013 05:53 PM, Steven Rostedt wrote:
On Tue, 2013-04-09 at 17:43 -0700, H. Peter Anvin wrote:
OK, thinking about the GDT here.
The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As
such, we probably don't want to allocate a full page to it for only
that. This means
On 04/08/2013 03:43 PM, Kees Cook wrote:
This makes the IDT unconditionally read-only. This primarily removes
the IDT from being a target for arbitrary memory write attacks. It has
an added benefit of also not leaking (via the sidt instruction) the
kernel base offset, if it has been relocated.
0 should probably mean no shift; that way we explicitly prohibit odd offsets,
which is a good thing, too.
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Apr 03, 2013 at 04:40:29PM +1030, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
On 03/29/2013 08:19 PM, Rusty Russell wrote
I mean no offset.
Michael S. Tsirkin m...@redhat.com wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Apr 03, 2013 at 04:40:29PM +1030, Rusty Russell wrote:
H. Peter Anvin h...@zytor.com writes:
On 03/29/2013 08:19 PM, Rusty Russell wrote:
Shift count?
You can only
On 03/29/2013 08:19 PM, Rusty Russell wrote:
Shift count?
You can only have 2^16 vqs per device. Is it verboten to write 16-bit
values to odd offsets? If so, we've just dropped it to 2^15 before you
have to do some decoding to do. Hard to care...
I dislike saying multiply offset by 2
26, 2013 at 07:31:31PM -0700, H. Peter Anvin wrote:
On 03/26/2013 05:22 PM, H. Peter Anvin wrote:
I would say let it be undefined... in most cases the host will know
what device(s) will matter; e.g. if the guest is ppc no point in
providing an I/O BAR.
For pluggable physical devices, though
nor there ...
Shift count?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https
I would say let it be undefined... in most cases the host will know what
device(s) will matter; e.g. if the guest is ppc no point in providing an I/O
BAR.
Rusty Russell ru...@rustcorp.com.au wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Mon, Mar 25, 2013 at 08:30:28PM +1030, Rusty
On 03/26/2013 05:22 PM, H. Peter Anvin wrote:
I would say let it be undefined... in most cases the host will know what
device(s) will matter; e.g. if the guest is ppc no point in providing an I/O
BAR.
For pluggable physical devices, though, both should be provided.
-hpa
--
H
That might be pushing it, fitting into the 192-byte nonstandard area with
everything else that might have to go there...
Michael S. Tsirkin m...@redhat.com wrote:
On Sun, Mar 24, 2013 at 04:23:57PM -0700, H. Peter Anvin wrote:
On 03/24/2013 06:14 AM, Michael S. Tsirkin wrote:
Peter
On 03/24/2013 06:14 AM, Michael S. Tsirkin wrote:
Peter is also saying we need a way to
do configuration/ISR without memory accesses.
I'm not 100% sure what you mean with ISR here (mostly because virtio
only has a limited fraction of my attention right now.)
For configuration, are we
On 03/24/2013 01:19 PM, Michael S. Tsirkin wrote:
struct virtio_pci_cap {
u8 cap_vndr;/* Generic PCI field: PCI_CAP_ID_VNDR */
@@ -150,7 +153,9 @@ struct virtio_pci_common_cfg {
__le16 queue_size; /* read-write, power of 2. */
__le16 queue_msix_vector;/* read-write */
doesn't care?).
Cc: H. Peter Anvin h...@zytor.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
I think guests is exactly the wrong place to decide,
it really does not know whether it's running on a
hypervisor with fast IO or fast memory.
Also, as long as we have an IO BAR, we have
ability.
That is a violation of the PCIe spec; the PCIe spec specifically states
that failure to allocate an I/O BAR should still allow the device to
function. So we shouldn't rule it out going forward.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I
On 03/21/2013 08:58 AM, Michael S. Tsirkin wrote:
Most of them do really ugly hacks in hardware (like putting in a back
door in config space) to make that possible.
config space register that let us access
registers within BAR actually sounds pretty reasonable.
Way better than an I/O BAR.
On 03/21/2013 09:11 AM, Michael S. Tsirkin wrote:
It is really, really, nasty, not to mention slow.
Almost everything we do is through DMA, except a single write
to start transmit and a single read to clear interrupts. So all it means
is we do 2 io writes or reads per packet instead of 1.
On 03/21/2013 09:26 AM, Michael S. Tsirkin wrote:
Thanks. Same place in latest 3.0:
A PCI Express Endpoint must not depend on operating system allocation of
I/O resources claimed through BAR(s).
A PCI Express Endpoint must not generate I/O Requests.
of course this only applies to
On 03/21/2013 10:07 AM, Michael S. Tsirkin wrote:
I just think it does not apply to BIOS so much. A bigger issue for BIOS
virtio performance is that it normally does not implement batching at
all, to keep it simple and reduce memory usage it uses a small number
(often 1) of outstanding
On 03/21/2013 10:49 AM, Michael S. Tsirkin wrote:
Just to clarify, I expect BIOS to use it *for config access*.
Notification will support IO anyway because it's
faster on KVM, so BIOS can use it directly.
Ah, yes, of course.
Quite frankly, I don't see any reason to support *anything else*
Can we just leave the configuration in config space, or is that undesirable?
Rusty Russell ru...@rustcorp.com.au wrote:
H. Peter Anvin h...@zytor.com writes:
On 03/21/2013 10:49 AM, Michael S. Tsirkin wrote:
Just to clarify, I expect BIOS to use it *for config access*.
Notification
On 03/06/2013 01:21 AM, Michael S. Tsirkin wrote:
Right. Though even with better granularify bridge windows
would still be a (smaller) problem causing fragmentation.
If we were to extend the PCI spec I would go for a bridge without
windows at all: a bridge can snoop on configuration
bridge
to allow a much narrower window? That fits much more nicely into the
device resource assignment on the guest side, and could even be
implemented on a real hardware device -- we can offer it to the PCI-SIG
for standardization, even.
-hpa
--
H. Peter Anvin, Intel Open Source Technology
1 - 100 of 203 matches
Mail list logo
