search for: rdtsc

I''m continuing to investigate the usage of rdtsc in userspace and whether there are programs "out there" that use it "unsafely" that might randomly break under Xen if rdtsc is not emulated, e.g. across a migration. Some have argued that nobody should use rdtsc and any programs that use rdtsc directly are "fundamentally br...

On 4/24/20 2:03 PM, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. > > --- > SEV-ES guests will need to execute rdtsc and rdtscp from userspace and > during early boot. Move the rdtsc(p) #VC handler into common code and > extend the #VC handlers. Do S...

On 4/24/20 2:03 PM, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. > > --- > SEV-ES guests will need to execute rdtsc and rdtscp from userspace and > during early boot. Move the rdtsc(p) #VC handler into common code and > extend the #VC handlers. Do S...

...: "c" (msr), "a" (val1), "d" (val2)) - #define rdmsrl(msr,val) do { \ unsigned long l__,h__; \ rdmsr (msr, l__, h__); \ @@ -62,22 +54,6 @@ static inline void wrmsrl (unsigned long : "c" (msr), "i" (-EFAULT));\ ret__; }) -#define rdtsc(low,high) \ - __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high)) - -#define rdtscl(low) \ - __asm__ __volatile__("rdtsc" : "=a" (low) : : "edx") - -#define rdtscll(val) \ - __asm__ __volatile__("rdtsc" : "=A...

...: "c" (msr), "a" (val1), "d" (val2)) - #define rdmsrl(msr,val) do { \ unsigned long l__,h__; \ rdmsr (msr, l__, h__); \ @@ -62,22 +54,6 @@ static inline void wrmsrl (unsigned long : "c" (msr), "i" (-EFAULT));\ ret__; }) -#define rdtsc(low,high) \ - __asm__ __volatile__("rdtsc" : "=a" (low), "=d" (high)) - -#define rdtscl(low) \ - __asm__ __volatile__("rdtsc" : "=a" (low) : : "edx") - -#define rdtscll(val) \ - __asm__ __volatile__("rdtsc" : "=A...

On 4/24/20 4:24 PM, Dave Hansen wrote: > On 4/24/20 2:03 PM, Mike Stunes wrote: >> I needed to allow RDTSC(P) from userspace and in early boot in order to >> get userspace started properly. Patch below. >> >> --- >> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and >> during early boot. Move the rdtsc(p) #VC handler into common code and >> extend...

Hi: I intend to use RDTSC to make some time tests in Xen guest WinXP. However, from Intel Developer''s Manual I noticed that RDTSC will cause VMExit if "RETSC exiting" VM-Execution control field is 1. So I wonder: How to query VM-Execution control field in a programmable way? BTW: On Intel Developer'...

...210708230408i7a8049a9m5db49e6c4d89ab62 at mail.gmail.com/ > > The changelog has an explanation as well. > > d8bb6f4c1670 ("x86: tsc prevent time going backwards") > > I still have one of the machines which is affected by this. Are we sure this isn't a load vs rdtsc reorder? Because if I look at the current code: notrace static u64 vread_tsc(void) { u64 ret = (u64)rdtsc_ordered(); u64 last = gtod->cycle_last; if (likely(ret >= last)) return ret; /* * GCC likes to generate cmov here, but this branch is extremely * predictable (it's just a...

...210708230408i7a8049a9m5db49e6c4d89ab62 at mail.gmail.com/ > > The changelog has an explanation as well. > > d8bb6f4c1670 ("x86: tsc prevent time going backwards") > > I still have one of the machines which is affected by this. Are we sure this isn't a load vs rdtsc reorder? Because if I look at the current code: notrace static u64 vread_tsc(void) { u64 ret = (u64)rdtsc_ordered(); u64 last = gtod->cycle_last; if (likely(ret >= last)) return ret; /* * GCC likes to generate cmov here, but this branch is extremely * predictable (it's just a...

Hi, I am trying to correlating performance issue in guest VM with the scheduling trace from Xentrace. User-mode application in guest VM periodically dump APIC ID and RDTSC into trace. I also start Xentrace in Dom0 during the same period. However, I notice that range of TSC values report both trace is completely disjointed. TSC values from Xentrace is always greater than what guest VM see, even if I start capturing Xen''s trace 30s before capturing trace in...

On 4/24/20 2:27 PM, Tom Lendacky wrote: > On 4/24/20 4:24 PM, Dave Hansen wrote: >> On 4/24/20 2:03 PM, Mike Stunes wrote: >>> I needed to allow RDTSC(P) from userspace and in early boot in order to >>> get userspace started properly. Patch below. >>> >>> --- >>> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and >>> during early boot. Move the rdtsc(p) #VC handler into common code...

On 4/24/20 2:27 PM, Tom Lendacky wrote: > On 4/24/20 4:24 PM, Dave Hansen wrote: >> On 4/24/20 2:03 PM, Mike Stunes wrote: >>> I needed to allow RDTSC(P) from userspace and in early boot in order to >>> get userspace started properly. Patch below. >>> >>> --- >>> SEV-ES guests will need to execute rdtsc and rdtscp from userspace and >>> during early boot. Move the rdtsc(p) #VC handler into common code...

Hi Mike, On Fri, Apr 24, 2020 at 02:03:16PM -0700, Mike Stunes wrote: > I needed to allow RDTSC(P) from userspace and in early boot in order to > get userspace started properly. Patch below. Thanks, but this is not needed anymore. I removed the vc_context_filter from the code. The emulation code is now capable of safely handling any exception from user-space. Regards, Joerg

...uled to a different pcpu by Xen, the underlying tsc may appear erratic. Comments (especially from Intel and AMD)? If agreed, could Intel and AMD provide patches so that hvm reads of the bits return "false"? Or will this cause other problems? Another alternative would be to trap all rdtsc's and emulate them but this probably will not be easy and may have significant performance implications. But perhaps it should be an option? Dan =================================== Thanks... for the memory I really could use more / My throughput's on the floor The balloon is flat / My sw...

...tag Reported-by: kbuild test robot <lkp at intel.com> All errors (new ones prefixed by >>): drivers/vhost/vhost.c: In function 'vhost_get_vq_desc_batch': >> drivers/vhost/vhost.c:2672:9: error: 'desc' undeclared (first use in this function); did you mean 'rdtsc'? if (!(desc->flags & VRING_DESC_F_NEXT)) ^~~~ rdtsc drivers/vhost/vhost.c:2672:9: note: each undeclared identifier is reported only once for each function it appears in vim +2672 drivers/vhost/vhost.c 2569 2570 /* This looks in the virtqueue and f...

Hi Dave, On Fri, Apr 24, 2020 at 03:53:09PM -0700, Dave Hansen wrote: > Ahh, so any instruction that can have an instruction intercept set > potentially needs to be able to tolerate a #VC? Those instruction > intercepts are under the control of the (untrusted relative to the > guest) hypervisor, right? > > >From the main sev-es series: > > +#ifdef

On Sat, Apr 25, 2020 at 11:15:35AM -0700, Andy Lutomirski wrote: > shift_ist is gross. What's it for? If it's not needed, I'd rather > not use it, and I eventually want to get rid of it for #DB as well. The #VC handler needs to be able to nest, there is no way around that for various reasons, the two most important ones are: 1. The #VC -> NMI -> #VC case. #VCs can

On Sat, Apr 25, 2020 at 12:47:31PM -0700, Andy Lutomirski wrote: > I assume the race you mean is: > > #VC > Immediate NMI before IST gets shifted > #VC > > Kaboom. > > How are you dealing with this? Ultimately, I think that NMI will need > to turn off IST before engaging in any funny business. Let me ponder > this a bit. Right, I dealt with that by

On Tue, Apr 28, 2020 at 09:55:12AM +0200, Joerg Roedel wrote: > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > > I have a somewhat serious question: should we use IST for #VC at all? > > As I understand it, Rome and Naples make it mandatory for hypervisors > > to intercept #DB, which means that, due to the MOV SS mess, it's sort > > of mandatory

On Tue, Jun 23, 2020 at 01:11:07PM +0200, Joerg Roedel wrote: > Hi Peter, > > On Tue, Jun 23, 2020 at 12:45:59PM +0200, Peter Zijlstra wrote: > > On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > > > Or maybe you have a better idea how to implement this, so I'd like to > > > hear your opinion first before I spend too many days implementing >