Re: [PATCH v11 05/37] x86/trapnr: Add event type macros to
On 23.09.23 г. 12:41 ч., Xin Li wrote: Intel VT-x classifies events into eight different types, which is inherited by FRED for event identification. As such, event type becomes a common x86 concept, and should be defined in a common x86 header. Add event type macros to , and use it in . Suggested-by: H. Peter Anvin (Intel) Tested-by: Shan Kang Signed-off-by: Xin Li --- Changes since v10: * A few comment fixes and improvements (Andrew Cooper). --- arch/x86/include/asm/trapnr.h | 12 arch/x86/include/asm/vmx.h| 17 + 2 files changed, 21 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/trapnr.h b/arch/x86/include/asm/trapnr.h index f5d2325aa0b7..8d1154cdf787 100644 --- a/arch/x86/include/asm/trapnr.h +++ b/arch/x86/include/asm/trapnr.h @@ -2,6 +2,18 @@ #ifndef _ASM_X86_TRAPNR_H #define _ASM_X86_TRAPNR_H +/* + * Event type codes used by FRED, Intel VT-x and AMD SVM + */ +#define EVENT_TYPE_EXTINT 0 // External interrupt +#define EVENT_TYPE_RESERVED1 +#define EVENT_TYPE_NMI 2 // NMI +#define EVENT_TYPE_HWEXC 3 // Hardware originated traps, exceptions +#define EVENT_TYPE_SWINT 4 // INT n +#define EVENT_TYPE_PRIV_SWEXC 5 // INT1 +#define EVENT_TYPE_SWEXC 6 // INTO, INT3 nit: This turned into INTO (Oh) rather than INT0( zero) in v11
Re: [PATCH v11 05/37] x86/trapnr: Add event type macros to
On 26/09/2023 9:10 am, Nikolay Borisov wrote: > On 23.09.23 г. 12:41 ч., Xin Li wrote: >> diff --git a/arch/x86/include/asm/trapnr.h >> b/arch/x86/include/asm/trapnr.h >> index f5d2325aa0b7..8d1154cdf787 100644 >> --- a/arch/x86/include/asm/trapnr.h >> +++ b/arch/x86/include/asm/trapnr.h >> @@ -2,6 +2,18 @@ >> #ifndef _ASM_X86_TRAPNR_H >> #define _ASM_X86_TRAPNR_H >> +/* >> + * Event type codes used by FRED, Intel VT-x and AMD SVM >> + */ >> +#define EVENT_TYPE_EXTINT 0 // External interrupt >> +#define EVENT_TYPE_RESERVED 1 >> +#define EVENT_TYPE_NMI 2 // NMI >> +#define EVENT_TYPE_HWEXC 3 // Hardware originated traps, >> exceptions >> +#define EVENT_TYPE_SWINT 4 // INT n >> +#define EVENT_TYPE_PRIV_SWEXC 5 // INT1 >> +#define EVENT_TYPE_SWEXC 6 // INTO, INT3 > > nit: This turned into INTO (Oh) rather than INT0( zero) in v11 Yes, v11 corrected a bug in v10. The INTO instruction is "INT on Overflow". No zero involved. INT3 is thusly named because it generates vector 3. Similarly for INT1 although it had the unofficial name ICEBP long before INT1 got documented. If INTO were to have a number, it would need to be 4, but it's behaviour is conditional on the overflow flag, unlike INT3/1 which are unconditional exceptions. ~Andrew
Re: [PATCH] tracing: document buffer_size_kb more precisely
On 25/09/2023 12:44, Zheng Yejian wrote:
> On 2023/9/25 18:02, Christian Loehle wrote:
>> buffer_size_kb no longer shows the requested amount, but the one that
>> is actually used internally for the ring buffer.
>>
>> commit 6d98a0f2ac3c ("tracing: Set actual size after ring buffer resize")
>> changed the sysfs behavior such that value read will always show the
>> actual size, while previously it showed the size that was requested
>> through the sysfs interface, even if it was rounded up to fulfill
>> the request.
>> So the documentation can state that more precisely now.
>>
>> Signed-off-by: Christian Loehle
>> ---
>> Documentation/trace/ftrace.rst | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
>> index 23572f6697c0..2e066b3b6edc 100644
>> --- a/Documentation/trace/ftrace.rst
>> +++ b/Documentation/trace/ftrace.rst
>> @@ -191,7 +191,7 @@ of ftrace. Here is a list of some of the key files:
>> A few extra pages may be allocated to accommodate buffer management
>> meta-data. If the last page allocated has room for more bytes
>> than requested, the rest of the page will be used,
>> - making the actual allocation bigger than requested or shown.
>> + making the actual allocation bigger than requested.
>
> Hi, the actual allocation should still be bigger than shown due to the
> loss of accuracy when doing unit conversion from bytes to kilobytes (see
> tracing_entries_read()).
>
Right, the sysfs obviously only allows for KB aligned setting, but you're right.
If set on the cmdline non-KB multiples are possible and accuracy is lost.
Nevermind then.
> --
>
> Thanks,
> Zheng Yejian
>
>> ( Note, the size may not be a multiple of the page size
>> due to buffer management meta-data. )
>>
>
Re: [EXTERNAL] Re: [PATCH v4 0/3] UIO driver for low speed Hyper-V devices
On Wed, Sep 06, 2023 at 05:23:07AM -0700, Saurabh Singh Sengar wrote: > On Tue, Aug 22, 2023 at 01:48:03PM +0200, Greg KH wrote: > > On Mon, Aug 21, 2023 at 07:36:18AM +, Saurabh Singh Sengar wrote: > > > > > > > > > > -Original Message- > > > > From: Greg KH > > > > Sent: Saturday, August 12, 2023 4:45 PM > > > > To: Saurabh Sengar > > > > Cc: KY Srinivasan ; Haiyang Zhang > > > > ; wei@kernel.org; Dexuan Cui > > > > ; Michael Kelley (LINUX) ; > > > > cor...@lwn.net; linux-ker...@vger.kernel.org; > > > > linux-hyp...@vger.kernel.org; > > > > linux-doc@vger.kernel.org > > > > Subject: [EXTERNAL] Re: [PATCH v4 0/3] UIO driver for low speed Hyper-V > > > > devices > > > > > > > > On Fri, Aug 04, 2023 at 12:09:53AM -0700, Saurabh Sengar wrote: > > > > > Hyper-V is adding multiple low speed "speciality" synthetic devices. > > > > > Instead of writing a new kernel-level VMBus driver for each device, > > > > > make the devices accessible to user space through a UIO-based > > > > > hv_vmbus_client driver. Each device can then be supported by a user > > > > > space driver. This approach optimizes the development process and > > > > > provides flexibility to user space applications to control the key > > > > > interactions with the VMBus ring buffer. > > > > > > > > Why is it faster to write userspace drivers here? Where are those new > > > > drivers, > > > > and why can't they be proper kernel drivers? Are all hyper-v drivers > > > > going to > > > > move to userspace now? > > > > > > Hi Greg, > > > > > > You are correct; it isn't faster. However, the developers working on > > > these userspace > > > drivers can concentrate entirely on the business logic of these devices. > > > The more > > > intricate aspects of the kernel, such as interrupt management and host > > > communication, > > > can be encapsulated within the uio driver. > > > > Yes, kernel drivers are hard, we all know that. > > > > But if you do it right, it doesn't have to be, saying "it's too hard for > > our programmers to write good code for our platform" isn't exactly a > > good endorcement of either your programmers, or your platform :) > > > > > The quantity of Hyper-V devices is substantial, and their numbers are > > > consistently > > > increasing. Presently, all of these drivers are in a development/planning > > > phase and > > > rely significantly on the acceptance of this UIO driver as a prerequisite. > > > > Don't make my acceptance of something that you haven't submitted before > > a business decision that I need to make, that's disenginous. > > > > > Not all hyper-v drivers will move to userspace, but many a new slow > > > Hyperv-V > > > devices will use this framework and will avoid introducing a new kernel > > > driver. We > > > will also plan to remove some of the existing drivers like kvp/vss. > > > > Define "slow" please. > > In the Hyper-V environment, most devices, with the exception of network and > storage, > typically do not require extensive data read/write exchanges with the host. > Such > devices are considered to be 'slow' devices. > > > > > > > > The new synthetic devices are low speed devices that don't support > > > > > VMBus monitor bits, and so they must use vmbus_setevent() to notify > > > > > the host of ring buffer updates. The new driver provides this > > > > > functionality along with a configurable ring buffer size. > > > > > > > > > > Moreover, this series of patches incorporates an update to the fcopy > > > > > application, enabling it to seamlessly utilize the new interface. The > > > > > older fcopy driver and application will be phased out gradually. > > > > > Development of other similar userspace drivers is still underway. > > > > > > > > > > Moreover, this patch series adds a new implementation of the fcopy > > > > > application that uses the new UIO driver. The older fcopy driver and > > > > > application will be phased out gradually. Development of other similar > > > > > userspace drivers is still underway. > > > > > > > > You are adding a new user api with the "ring buffer" size api, which is > > > > odd for > > > > normal UIO drivers as that's not something that UIO was designed for. > > > > > > > > Why not just make you own generic type uiofs type kernel api if you > > > > really > > > > want to do all of this type of thing in userspace instead of in the > > > > kernel? > > > > > > Could you please elaborate more on this suggestion. I couldn't understand > > > it > > > completely. > > > > Why is uio the requirement here? Why not make your own framework to > > write hv drivers in userspace that fits in better with the overall goal? > > Call it "hvfs" or something like that, much like we have usbfs for > > writing usb drivers in userspace. > > > > Bolting on HV drivers to UIO seems very odd as that is not what this > > framework is supposed to be providing at all. UIO was to enable "pass > > through" memory-mapped drivers that only wanted an in
RE: [PATCH v11 05/37] x86/trapnr: Add event type macros to
> >> +EVENT_TYPE_PRIV_SWEXC 5 // INT1 #define EVENT_TYPE_SWEXC 6 > >> +// INTO, INT3 > > > > nit: This turned into INTO (Oh) rather than INT0( zero) in v11 > > Yes, v11 corrected a bug in v10. > > The INTO instruction is "INT on Overflow". No zero involved. > > INT3 is thusly named because it generates vector 3. Similarly for INT1 > although it > had the unofficial name ICEBP long before INT1 got documented. > > If INTO were to have a number, it would need to be 4, but it's behaviour is > conditional on the overflow flag, unlike INT3/1 which are unconditional > exceptions. live x86 SDM!
