hes.
(only patch 2 changed in this version)
Thanks,
Joao
Joao Martins (3):
x86/pvclock: add setter for pvclock_pvti_cpu0_va
x86/xen/time: setup vcpu 0 time info page
MAINTAINERS: xen, kvm: track pvclock-abi.h changes
MAINTAINERS| 2 +
arch/x86/include/asm/pvclo
and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
Acked-by: Andy Lutomirski
---
Changes since v1:
* Rebased: the only conflict was that I had move the export
pvclock_pvti_cpu0_va()
vcpu_time_info struct.
Signed-off-by: Joao Martins
---
Changes since v3:
(Comments from Juergen)
* Remove _t added suffix from *GUEST_HANDLE* when sync vcpu.h
with the latest
Changes since v2:
(Comments from Juergen)
* Omit the blank after the cast on all 3 occurrences.
* Change last VCLOCK_PVCLOCK
On 09/27/2017 01:14 PM, Juergen Gross wrote:
> On 27/09/17 14:00, Joao Martins wrote:
[...]
>> diff --git a/include/xen/interface/vcpu.h b/include/xen/interface/vcpu.h
>> index 98188c87f5c1..b4a1eabcf1c4 100644
>> --- a/include/xen/interface/vcpu.h
>> +++ b/i
On 09/27/2017 03:40 PM, Boris Ostrovsky wrote:
>> +static void xen_setup_vsyscall_time_info(void)
>> +{
>> +struct vcpu_register_time_memory_area t;
>> +struct pvclock_vsyscall_time_info *ti;
>> +struct pvclock_vcpu_time_info *pvti;
>> +int ret;
>> +
>> +pvti = &__this_cpu_read(
On 09/27/2017 09:22 PM, Boris Ostrovsky wrote:
> On 09/27/2017 11:26 AM, Joao Martins wrote:
>> On 09/27/2017 03:40 PM, Boris Ostrovsky wrote:
>>>> +static void xen_setup_vsyscall_time_info(void)
>>>> +{
>>>> + struct vcpu_register_time_memory_area t;
On 09/27/2017 11:44 PM, Boris Ostrovsky wrote:
> On 09/27/2017 04:57 PM, Joao Martins wrote:
>> On 09/27/2017 09:22 PM, Boris Ostrovsky wrote:
>>> On 09/27/2017 11:26 AM, Joao Martins wrote:
>>>> On 09/27/2017 03:40 PM, Boris Ostrovsky wrote:
>>>>>>
On 09/28/2017 12:46 AM, Joao Martins wrote:
> On 09/27/2017 11:44 PM, Boris Ostrovsky wrote:
>> On 09/27/2017 04:57 PM, Joao Martins wrote:
>>> On 09/27/2017 09:22 PM, Boris Ostrovsky wrote:
>>>> On 09/27/2017 11:26 AM, Joao Martins wrote:
>>>>>
elog is in individual patches.
Thanks,
Joao
Joao Martins (4):
x86/pvclock: add setter for pvclock_pvti_cpu0_va
x86/xen/time: set pvclock flags on xen_time_init()
x86/xen/time: setup vcpu 0 time info page
MAINTAINERS: xen, kvm: track pvclock-abi.h changes
MAINTAINERS|
Specifically check for PVCLOCK_TSC_STABLE_BIT and if this bit is set,
then set it too on pvclock flags. This allows Xen clocksource to use it
and thus speeding up xen_clocksource_read() callers (i.e. sched_clock())
Signed-off-by: Joao Martins
---
New in v5
---
arch/x86/xen/time.c | 9
vcpu_time_info struct.
Signed-off-by: Joao Martins
Reviewed-by: Juergen Gross
---
Changes since v4:
* Remove pvclock_set_flags since predecessor patch will set in
xen_time_init. Consequently pvti local variable is not so useful
and doesn't make things more clear - therefore remove it.
* Adjust co
peers noticed when such changes happen.
Signed-off-by: Joao Martins
Acked-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Paolo Bonzini
---
Changes since v4:
* Add Paolo's Acked-by
* Add Konrad's Reviewed-by
Changes since v1:
* Add Juergen's Gross Acked-by.
---
M
and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
Acked-by: Andy Lutomirski
---
Changes since v1:
* Rebased: the only conflict was that I had move the export
pvclock_pvti_cpu0_va()
On 10/02/2017 07:44 PM, Boris Ostrovsky wrote:
>
>> +
>> +static void xen_setup_vsyscall_time_info(void)
>> +{
>> +struct vcpu_register_time_memory_area t;
>> +struct pvclock_vsyscall_time_info *ti;
>> +int ret;
>
>
> In the previous version you'd return immediately if
> PVCLOCK_TS
Specifically check for PVCLOCK_TSC_STABLE_BIT and if this bit is set,
then set it too on pvclock flags. This allows Xen clocksource to use it
and thus speeding up xen_clocksource_read() callers (i.e. sched_clock())
Signed-off-by: Joao Martins
Reviewed-by: Boris Ostrovsky
---
Changes since v5
vcpu_time_info struct.
Signed-off-by: Joao Martins
Reviewed-by: Juergen Gross
---
Changes since v5:
* Move xen_setup_vsyscall_time_info within the PVCLOCK_TSC_STABLE_BIT
clause added in the previous patch.
Changes since v4:
* Remove pvclock_set_flags since predecessor patch will set in
xen_time_init
and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
Acked-by: Andy Lutomirski
---
Changes since v1:
* Rebased: the only conflict was that I had move the export
pvclock_pvti_cpu0_va()
elog is in individual patches.
Thanks,
Joao
Joao Martins (4):
x86/pvclock: add setter for pvclock_pvti_cpu0_va
x86/xen/time: set pvclock flags on xen_time_init()
x86/xen/time: setup vcpu 0 time info page
MAINTAINERS: xen, kvm: track pvclock-abi.h changes
MAINTAINERS| 2 +
peers noticed when such changes happen.
Signed-off-by: Joao Martins
Acked-by: Juergen Gross
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Paolo Bonzini
---
Changes since v4:
* Add Paolo's Acked-by
* Add Konrad's Reviewed-by
Changes since v1:
* Add Juergen's Gross Acked-by.
---
M
Add a document outlining how the guest can map a set of grants
on the backend through the control ring.
Signed-off-by: Joao Martins
Reviewed-by: Konrad Rzeszutek Wilk
---
New in v5
---
docs/misc/netif-staging-grants.pandoc | 587 ++
1 file changed, 587
/jpemartins/linux.git xen-net-stg-gnts-v3
Thanks!
Joao Martins (2):
public/io/netif.h: add gref mapping control messages
docs/misc: add netif staging grants design document
docs/misc/netif-staging-grants.pandoc | 587 ++
xen/include/public/io/netif.h | 123
added are:
- Add grefs to be mapped by backend
- Remove grefs mappings (If they are not in use)
- Get maximum amount of grefs kept mapped.
Signed-off-by: Joao Martins
Reviewed-by: Paul Durrant
Reviewed-by: Konrad Rzeszutek Wilk
---
v5:
* Added RoB from Paul and Konrad
v4:
* Declare
>> up (verify_tsc_reliability init call).
>>
>> Signed-off-by: Joao Martins
>> Reviewed-by: Konrad Rzeszutek Wilk
>
> Reviewed-by: Jan Beulich
>
> But not really useful to apply imo without the next patch.
>
I also agree with you. Thanks!
___
alibration is set
>> to 1sec after we switch to TSC, thus these stamps are reseeded to also
>> ensure monotonic returning values right after the point we switch to
>> TSC. This is also to avoid the possibility of having inconsistent
>> readings in this short period (i.e. unt
On 08/25/2016 11:13 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> And use to initialize platform time solely for clocksource=tsc,
>> as opposed to initializing platform overflow timer, which would
>> only fire in ~180 years (on 2.2 Ghz Broadwell processor).
>
> Do we really want to
On 08/25/2016 11:17 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> To fetch the last read from the clocksource which was used to
>> calculate system_time.
>
> DYM "To allow the caller to fetch ..."?
Yeap, sounds better that way.
>
>> In the case of clocksource=tsc we will
>> use
On 08/25/2016 11:38 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> Add TSC as another clocksource that can be used, plus
>> a mention to the maxcpus parameter and that it requires
>> being explicitly set.
>
> This belongs in the patch introducing the option.
OK, I merged this back
On 08/25/2016 11:37 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> This patch proposes relying on host TSC synchronization and
>> passthrough to the guest, when running on a TSC-safe platform. On
>> time_calibration we retrieve the platform time in ns and the counter
>> read by the cl
On 08/29/2016 10:36 AM, Jan Beulich wrote:
On 26.08.16 at 17:11, wrote:
>> On 08/25/2016 11:06 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
This patch introduces support for using TSC as platform time source
which is the highest resolution time and most performant to
On 08/29/2016 10:41 AM, Jan Beulich wrote:
On 26.08.16 at 17:12, wrote:
>> On 08/25/2016 11:13 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
And use to initialize platform time solely for clocksource=tsc,
as opposed to initializing platform overflow timer, which would
On 08/29/2016 11:06 AM, Jan Beulich wrote:
On 26.08.16 at 17:44, wrote:
>> On 08/25/2016 11:37 AM, Jan Beulich wrote:
>> On 24.08.16 at 14:43, wrote:
This patch proposes relying on host TSC synchronization and
passthrough to the guest, when running on a TSC-safe platform. On
>>
On 08/30/2016 01:30 PM, Jan Beulich wrote:
On 30.08.16 at 14:08, wrote:
>> On 08/29/2016 10:36 AM, Jan Beulich wrote:
>> On 26.08.16 at 17:11, wrote:
On 08/25/2016 11:06 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> - Change init_tsctimer to skip all the te
On 08/30/2016 01:45 PM, Jan Beulich wrote:
On 30.08.16 at 14:26, wrote:
>> On 08/29/2016 11:06 AM, Jan Beulich wrote:
>> On 26.08.16 at 17:44, wrote:
On 08/25/2016 11:37 AM, Jan Beulich wrote:
On 24.08.16 at 14:43, wrote:
>> This patch proposes relying on host TSC sync
On 08/30/2016 01:31 PM, Jan Beulich wrote:
On 30.08.16 at 14:10, wrote:
>> What would be a preferred period - probably capping it to a
>> day/hour/minutes? Or
>> keeping the current calculated value? Maximum right now in current platform
>> timers
>> are few minutes depending on the HPET fr
On 09/12/2016 08:26 AM, Jan Beulich wrote:
On 09.09.16 at 18:32, wrote:
>> Would that sound reasonable - am I overlooking something? To some extent this
>> might also applicable to the general case, although platform timer is now
>> only
>> used for initial seeding so probably a non-visible
for 2 weeks on a dual-socket Haswell
machine and I haven't yet seen time going backwards (plus tests on older
multi socket machines). Furthermore double checked migration to/from hosts
with/without the bit while guest was running the time warp test and no issues
occurred too.
Thanks!
Jo
t changing and that guests are
expected to check this bit on every read.
Should note that I've yet to see time going backwards in a long running
test for 2 weeks (in a dual socket machine), plus few other tests I did
on older platforms, including migration.
Signed-off-by: Joao Martins
---
of
having inconsistent readings in this short period (i.e. until
calibration fires).
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v3:
- Really fix "HPET switching to TSC" comment. Despite mentioned in the
in previous version, the change wasn't there
To allow the caller to fetch the last read from the clocksource which
was used to calculate system_time. This is a prerequisite for a
subsequent patch that will use this last read.
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v3:
- Add mention of this being
s option.
Also make one style adjustment that is to remove the unnecessary
parenthesis around clearing TSC_RELIABLE.
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Alternatively to having tsc_flags, I could instead introduce a new
X86_FEATURE in the Xen defined mapping.
And accomodate platform time source initialization in
try_platform_time(). This is a preparatory patch for deferring
TSC clocksource initialization to the stage where all CPUS are
up (verify_tsc_reliability init call).
Signed-off-by: Joao Martins
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
On 09/19/2016 11:13 AM, Jan Beulich wrote:
On 14.09.16 at 19:37, wrote:
>> This patch introduces support for using TSC as platform time source
>> which is the highest resolution time and most performant to get.
>> Though there are also several problems associated with its usage, and
>> there
On 09/19/2016 11:29 AM, Jan Beulich wrote:
On 14.09.16 at 19:37, wrote:
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -270,7 +270,9 @@ If set, override Xen's default choice for the platform
>> timer.
>> Having TSC as platform timer require
On 09/19/2016 11:15 AM, Jan Beulich wrote:
>>>> On 14.09.16 at 19:37, wrote:
>> To allow the caller to fetch the last read from the clocksource which
>> was used to calculate system_time. This is a prerequisite for a
>> subsequent patch that will use this last r
On 09/19/2016 11:22 AM, Jan Beulich wrote:
On 14.09.16 at 19:37, wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -951,6 +951,14 @@ static void __update_vcpu_system_time(struct vcpu *v,
>> int force)
>> _u.tsc_timestamp = tsc_stamp;
>> _u.system_time = t->
On 09/19/2016 05:25 PM, Jan Beulich wrote:
On 19.09.16 at 18:11, wrote:
>> On 09/19/2016 11:13 AM, Jan Beulich wrote:
>> On 14.09.16 at 19:37, wrote:
Since b64438c7c ("x86/time: use correct (local) time stamp in
constant-TSC calibration fast path") updates to cpu time use local
On 09/20/2016 08:13 AM, Jan Beulich wrote:
On 19.09.16 at 19:54, wrote:
>> On 09/19/2016 05:25 PM, Jan Beulich wrote:
>> On 19.09.16 at 18:11, wrote:
On 09/19/2016 11:13 AM, Jan Beulich wrote:
On 14.09.16 at 19:37, wrote:
>> Since b64438c7c ("x86/time: use correct (loc
On 09/20/2016 11:15 AM, Joao Martins wrote:
> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>>>>> On 19.09.16 at 19:54, wrote:
>>> On 09/19/2016 05:25 PM, Jan Beulich wrote:
>>>>>>> On 19.09.16 at 18:11, wrote:
>>>>> On 09/19/2
On 09/20/2016 02:55 PM, Jan Beulich wrote:
On 20.09.16 at 12:15, wrote:
>> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>> On 19.09.16 at 19:54, wrote:
On 09/19/2016 05:25 PM, Jan Beulich wrote:
On 19.09.16 at 18:11, wrote:
>> On 09/19/2016 11:13 AM, Jan Beulich wrote:
>
On 09/20/2016 05:17 PM, Joao Martins wrote:
> On 09/20/2016 02:55 PM, Jan Beulich wrote:
>>>>> On 20.09.16 at 12:15, wrote:
>>> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>>>>>>> On 19.09.16 at 19:54, wrote:
>>>>> On 09/19/2
On 09/20/2016 05:17 PM, Joao Martins wrote:
> On 09/20/2016 02:55 PM, Jan Beulich wrote:
>>>>> On 20.09.16 at 12:15, wrote:
>>> On 09/20/2016 08:13 AM, Jan Beulich wrote:
>>>>>>> On 19.09.16 at 19:54, wrote:
>>>>> On 09/19/2
On 09/21/2016 10:45 AM, Jan Beulich wrote:
>>>> On 21.09.16 at 11:20, wrote:
>> On 09/20/2016 05:17 PM, Joao Martins wrote:
>>> On 09/20/2016 02:55 PM, Jan Beulich wrote:
>>>> I.e. the introduction of nop_rendezvous is
>>>> really just to avoi
s option.
Also make one style adjustment that is to remove the unnecessary
parenthesis around clearing TSC_RELIABLE.
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v4:
- Fix documentation spelling mistakes namely repeated use of
"parameter&qu
est for >2 weeks on a dual-socket Haswell
machine and I haven't yet seen time going backwards (plus tests on older
multi socket machines). Furthermore double checked migration to/from hosts
with/without the bit while guest was running the time warp test and no issues
occurred too.
Tha
To allow the caller to fetch the last read from the clocksource which
was used to calculate system_time. This is a prerequisite for a
subsequent patch that will use this last read.
Signed-off-by: Joao Martins
Acked-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v4
me stamps accordingly. Time
calibration is set to 1sec after we switch to TSC, thus these stamps
are reseeded to also ensure monotonic returning values right after the
point we switch to TSC. This is to remove the possibility of having
inconsistent readings in this short period (i.e. until cal
s.
Signed-off-by: Joao Martins
Reviewed-by: Jan Beulich
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v4:
- Remove blanks from flag assignment.
- Added "Reviewed-by" from Jan Beulich.
- Move nop_rendezvous introduction (and the mention in the commit
message) into t
And accomodate platform time source initialization in
try_platform_time(). This is a preparatory patch for deferring
TSC clocksource initialization to the stage where all CPUS are
up (verify_tsc_reliability init call).
Signed-off-by: Joao Martins
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by
On 02/02/2017 10:31 PM, Jim Fehlig wrote:
> When the libxl driver is initialized, it creates a virDomainDef
> object for dom0 and adds it to the list of domains. Total memory
> for dom0 was being set from the max_memkb field of libxl_dominfo
> struct retrieved from libxl, but this field can be set
On 02/08/2017 04:06 PM, Jim Fehlig wrote:
> Joao Martins wrote:
>> On 02/02/2017 10:31 PM, Jim Fehlig wrote:
>>> When the libxl driver is initialized, it creates a virDomainDef
>>> object for dom0 and adds it to the list of domains. Total memory
>>> for dom0 wa
e written.
>
> Signed-off-by: Jan Beulich
FWIW,
Reviewed-by: Joao Martins
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
On 02/10/2017 11:17 AM, Andrew Cooper wrote:
> On 10/02/17 11:11, Joao Martins wrote:
>> On 02/10/2017 11:03 AM, Jan Beulich wrote:
>>> While we shouldn't remove its current invocation, we need to re-run it
>>> for the case that the X86_FEATURE_TSC_RELIABLE featu
used?
OK, see attached - I should note that its a WIP as Konrad noted, but once the
staging grants work is finished, the code would be improved to have it in better
shape (as well as in feature parity) for a proper RFC [and adhering to the
project coding style].
Joao
>From 3bced1452e1e619e7f470
On 02/20/2017 09:56 AM, Jan Blunck wrote:
> On Fri, Feb 17, 2017 at 5:07 PM, Konrad Rzeszutek Wilk
> wrote:
>> On Thu, Feb 16, 2017 at 10:51:44PM +0100, Vincent JARDIN wrote:
>>> Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit :
> Is it time now to officially remove Dom0 support?
So
g used we allow offlining CPUs but not onlining any ones
back. Should note that I've yet to see time going backwards in a long running
test in the past few days (in a dual socket machine), plus few other tests I
did on older platforms.
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: And
And use to initialize platform time solely for clocksource=tsc,
as opposed to initializing platform overflow timer, which would
only fire in ~180 years (on 2.2 Ghz Broadwell processor).
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v2:
- Remove pointless
is short period (i.e. until calibration fires).
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v2:
- Suggest "HPET switching to TSC" only as an example as otherwise it
would be misleading on platforms not having one.
- Change init_tsctimer to skip all
To fetch the last read from the clocksource which was used to
calculate system_time. In the case of clocksource=tsc we will
use it to set tsc_timestamp.
Signed-off-by: Joao Martins
---
Cc: Jan Beulich
Cc: Andrew Cooper
Changes since v2:
- s/plt_stamp_counter/plt_counter/g
- Move conditional
And accomodate platform time source initialization in
try_platform_time(). This is a preparatory patch for deferring
TSC clocksource initialization to the stage where all CPUS are
up (verify_tsc_reliability init call).
Signed-off-by: Joao Martins
Reviewed-by: Konrad Rzeszutek Wilk
---
Cc: Jan
Add TSC as another clocksource that can be used, plus
a mention to the maxcpus parameter and that it requires
being explicitly set.
Signed-off-by: Joao Martins
---
Cc: Andrew Cooper
Cc: Jan Beulich
New in v3.
---
docs/misc/xen-command-line.markdown | 6 +-
1 file changed, 5 insertions
ong running time warp test for the past days on a dual-socket Haswell
machine and I haven't yet seen time going backwards.
Thanks!
Joao
Joao Martins (6):
x86/time: refactor init_platform_time()
x86/time: implement tsc as clocksource
x86/time: streamline platform time init on pl
[Missed CC-ing the maintainers in the cover letter, my apologies]
On 08/24/2016 01:43 PM, Joao Martins wrote:
> Hey!
>
> This is v3 on the pvclock TSC stable bit series.
>
> Complete changelog on individual patches but overall is addressing
> Jan's comments, plus some
hrought write intercept msrs. We keep IA32_TSC MSR logic such that writes so
accomodate adjustments to TSC_ADJUST, hence no functional change in the
msr_tsc_adjust for IA32_TSC msr. Though, we do that in a separate routine
namely hvm_set_guest_tsc_msr instead of through hvm_set_guest_tsc(...).
Signed
On 01/20/2017 11:51 PM, Joao Martins wrote:
> Commit 6e03363 ("x86: Implement TSC adjust feature for HVM guest")
> implemented TSC_ADJUST MSR for hvm guests. Though while booting
> an HVM guest the boot CPU would have a value set with delta_tsc -
> guest tsc while secondary
ugh, we do that in a separate routine
namely hvm_set_guest_tsc_msr instead of through hvm_set_guest_tsc(...).
Signed-off-by: Joao Martins
Reviewed-by: Jan Beulich
---
Since v1:
* Change from section numbers to section titles
* Add citation of Intel SDM mentioning TSC_ADJUST being changed only thr
peers noticed when such changes happen.
Signed-off-by: Joao Martins
---
This was suggested by folks at xen-devel as we missed some of the
ABI additions (e.g. flags field in pvti, TSC stable bit) - so this
patch is to help preventing that from happening. Alternatively I
could instead add a "P
BI changes. Changelog since RFC is
included in individual patches.
Any comments/suggestions are welcome.
Thanks,
Joao
Joao Martins (3):
x86/pvclock: add setter for pvclock_pvti_cpu0_va
x86/xen/time: setup vcpu 0 time info page
MAINTAINERS: xen, kvm: track pvclock-abi.h changes
M
eric place to have it
and adds the correspondent setter routine for it. This allows other
pvclock-based clocksources to use it, such as Xen.
Signed-off-by: Joao Martins
---
Changes since RFC:
(Comments from Andy Lutomirski)
* Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
pvclock_set_pv
vcpu_time_info struct.
Signed-off-by: Joao Martins
---
Changes since RFC:
(Comments from Boris and David)
* Remove Kconfig option
* Use get_zeroed_page/free/page
* Remove the hypercall availability check
* Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
(New)
* Set seco
On 01/25/2017 07:26 PM, Boris Ostrovsky wrote:
> On 01/25/2017 12:33 PM, Joao Martins wrote:
>> In order to support pvclock vdso on xen we need to setup the time
>> info page for vcpu 0 and register the page with Xen using the
>> VCPUOP_register_vcpu_time_memory_area hype
On 01/26/2017 05:25 PM, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins
> wrote:
>> Right now there is only a pvclock_pvti_cpu0_va() which is defined
>> on kvmclock since:
>>
>> commit dac16fba6fc5
>> ("x86/vdso: Get pvclock dat
On 01/26/2017 05:25 PM, Andy Lutomirski wrote:
> On Wed, Jan 25, 2017 at 9:33 AM, Joao Martins
> wrote:
>> This file defines an ABI shared between guest and hypervisor(s)
>> (KVM, Xen) and as such there should be an correspondent entry in
>> MAINTAINERS file. Notice tha
ally causing noticeably (even if only temporary) strange
>>> behavior. As we're anyway expecting only sufficiently similar CPUs to
>>> appear during hotplug, this shouldn't be introducing new limitations.
>>>
>>> Reported-by: Joao Martins
>>> Sig
Joao
---
% Staging grants for network I/O requests
% Joao Martins <>
% Revision 1
\clearpage
Status: **Experimental**
Architecture(s): x86 and ARM
Component(s): Guest
Hardware: In
On 01/04/2017 01:54 PM, Wei Liu wrote:
> Hey!
Hey!
> Thanks for writing this detailed document!
Thanks a lot for the review and comments!
>
> On Wed, Dec 14, 2016 at 06:11:12PM +, Joao Martins wrote:
>> Hey,
>>
>> Back in the Xen hackaton '16 networking s
Hey Stefano,
Thanks a lot for the review and the comments!!
On 01/04/2017 07:40 PM, Stefano Stabellini wrote:
> On Wed, 14 Dec 2016, Joao Martins wrote:
>> # Proposed Extension
>>
>> ## Terminology
>>
>> `data gref` refers to the reusable/staging grants, wherea
On 01/06/2017 12:30 AM, Stefano Stabellini wrote:
> On Thu, 5 Jan 2017, Joao Martins wrote:
>> Hey Stefano,
>>
>> Thanks a lot for the review and the comments!!
>>
>> On 01/04/2017 07:40 PM, Stefano Stabellini wrote:
>>> On Wed, 14 Dec 2016, Joa
On 01/06/2017 09:33 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>> Sent: 14 December 2016 18:11
>> To: xen-de...@lists.xenproject.org
>> Cc: David Vrabel ; Andrew Cooper
>> ; Wei Liu ;
On 01/06/2017 07:18 PM, Stefano Stabellini wrote:
> On Fri, 6 Jan 2017, Paul Durrant wrote:
>>> -Original Message-
>>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>>> Sent: 14 December 2016 18:11
>>> To: xen-de...@lists.xenproject.o
On 01/09/2017 08:56 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Joao Martins [mailto:joao.m.mart...@oracle.com]
>> Sent: 06 January 2017 20:09
>> To: Paul Durrant
>> Cc: xen-de...@lists.xenproject.org; Andrew Cooper
>> ; Wei Liu ; Stefano
rface statistics we resort to virNetInterfaceStats
and let libvirt handle the platform specific nits. Note that the latter
is not yet supported in FreeBSD.
Signed-off-by: Joao Martins
---
Changes since v1:
- Fill .ifname after domain start with generated
name from libxl based on domain id and
cooperation of the guest and thus currently not supported.
We build on the data returned from libxl_domain_info and deliver
it in the virDomainMemoryStat format.
Signed-off-by: Joao Martins
---
Changes since v1:
- Cleanup properly after error fetching domain stats
- Dispose libxl_dominfo after
ence thus it is possible to
migrate from a P2P to non-P2P host.
Signed-off-by: Joao Martins
---
Changes since v1:
- Move Begin step to libxlDoMigrateP2P to have all 4 steps
together.
- Remove if before VIR_FREE(dom_xml)
---
src/libxl/libxl_driver.c| 13 ++-
src/libxl/libxl_mi
migration has been completed. But because we don't support
completed jobs we will deliver an error.
Signed-off-by: Joao Martins
---
Changes since v1:
- Fixed indentation on libxlDomainGetJobStats()
- s/estimed/estimated/g
- Bump version to 1.2.22
---
src/libxl/libxl_driver.c
Introduce support for domainGetCPUStats API call and consequently
allow us to use `virsh cpu-stats`. The latter returns a more brief
output than the one provided by`virsh vcpuinfo`.
Signed-off-by: Joao Martins
---
Changes since v1:
- Remove libxl_vcpuinfo_dispose() in favor or using
e node and will
return VIR_DOMAIN_JOB_NONE. Though nova handles this case and
will migrate it properly instead of crashing.
Signed-off-by: Joao Martins
---
Changes since v1:
- s/inexistent/nonexistent/g in commit message
- s/estimed/estimated/g
- Bump version to 1.2.22
---
src/libxl/libx
ed benefit of getting the number of flush requests.
Signed-off-by: Joao Martins
---
Changes since v1:
- Fix identation issues
- Set ret to LIBXL_VBD_SECTOR_SIZE
- Reuse VIR_STRDUP error instead of doing virReportError
when we fail to set stats->backend
- Change virAsprintf(...) error
Introduce support for connectGetAllDomainStats call that
allow us to _all_ domain(s) statistics including network, block,
cpus and memory. Changes are rather mechanical and mostly
take care of the format to export the data.
Signed-off-by: Joao Martins
---
Changes since v1:
- Rework flags
urthermore with this series we get to
support nova diagnostics.
Tested this series on 4.4.3 and 4.5 setups plus Openstack Kilo.
Individual patches contain the changelog and comments addressed since v1.
Thanks!
Joao Martins (8):
libxl: implement virDomainGetCPUStats
libxl: implement virDomainM
ned-off-by: Joao Martins
---
src/libvirt_private.syms | 1 +
src/util/virutil.c | 41 +++
src/util/virutil.h | 1 +
tests/utiltest.c | 56
4 files changed, 95 insertions(+), 4 deletions(-)
diff -
101 - 200 of 353 matches
Mail list logo
