>>> On 04.08.15 at 20:08, wrote:
> On 03/08/15 18:31, Roger Pau Monné wrote:
>> struct vcpu_hvm_x86_16 {
>> uint16_t ax;
>> uint16_t cx;
>> uint16_t dx;
>> uint16_t bx;
>> uint16_t sp;
>> uint16_t bp;
>> uint16_t si;
>> uint16_t di;
>> uint16_t ip;
>>
>> uin
At 19:11 +0200 on 05 Aug (1438801877), Roger Pau Monné wrote:
> El 05/08/15 a les 18.46, Andrew Cooper ha escrit:
> > On 05/08/15 17:40, Roger Pau Monné wrote:
> >> El 05/08/15 a les 17.39, Andrew Cooper ha escrit:
> >>> On 05/08/15 10:53, Roger Pau Monné wrote:
> El 04/08/15 a les 20.08, Andr
On 05/08/15 18:11, Roger Pau Monné wrote:
> El 05/08/15 a les 18.46, Andrew Cooper ha escrit:
>> On 05/08/15 17:40, Roger Pau Monné wrote:
>>> El 05/08/15 a les 17.39, Andrew Cooper ha escrit:
On 05/08/15 10:53, Roger Pau Monné wrote:
> El 04/08/15 a les 20.08, Andrew Cooper ha escrit:
>>>
El 05/08/15 a les 18.46, Andrew Cooper ha escrit:
> On 05/08/15 17:40, Roger Pau Monné wrote:
>> El 05/08/15 a les 17.39, Andrew Cooper ha escrit:
>>> On 05/08/15 10:53, Roger Pau Monné wrote:
El 04/08/15 a les 20.08, Andrew Cooper ha escrit:
> On 03/08/15 18:31, Roger Pau Monné wrote:
>>>
On 05/08/15 17:40, Roger Pau Monné wrote:
> El 05/08/15 a les 17.39, Andrew Cooper ha escrit:
>> On 05/08/15 10:53, Roger Pau Monné wrote:
>>> El 04/08/15 a les 20.08, Andrew Cooper ha escrit:
On 03/08/15 18:31, Roger Pau Monné wrote:
> uint32_t cs_base;
> uint32_t ds_base;
>>>
El 05/08/15 a les 17.39, Andrew Cooper ha escrit:
> On 05/08/15 10:53, Roger Pau Monné wrote:
>> El 04/08/15 a les 20.08, Andrew Cooper ha escrit:
>>> On 03/08/15 18:31, Roger Pau Monné wrote:
uint32_t cs_base;
uint32_t ds_base;
uint32_t ss_base;
uint32_t cs_limi
On 05/08/15 10:53, Roger Pau Monné wrote:
> El 04/08/15 a les 20.08, Andrew Cooper ha escrit:
>> On 03/08/15 18:31, Roger Pau Monné wrote:
Therefore, I am leaning slightly towards the specify the internals side
of things, which removes some complexity from the Xen side of the
hyperc
El 04/08/15 a les 20.08, Andrew Cooper ha escrit:
> On 03/08/15 18:31, Roger Pau Monné wrote:
>>> Therefore, I am leaning slightly towards the specify the internals side
>>> of things, which removes some complexity from the Xen side of the hypercall.
>> I've updated the proposed structure, so now i
On 03/08/15 18:31, Roger Pau Monné wrote:
> El 03/08/15 a les 18.55, Andrew Cooper ha escrit:
>> On 24/07/15 17:54, Roger Pau Monné wrote:
> struct vcpu_hvm_context {
> /* 16bit fields of the strucutre will be used. */
> #define _VCPUHVM_MODE_16B 0
> #define VCPUHVM_MOD
El 03/08/15 a les 18.55, Andrew Cooper ha escrit:
> On 24/07/15 17:54, Roger Pau Monné wrote:
>>
struct vcpu_hvm_context {
/* 16bit fields of the strucutre will be used. */
#define _VCPUHVM_MODE_16B 0
#define VCPUHVM_MODE_16B (1<<_VCPUHVM_MODE_16B)
>>>
On 24/07/15 17:54, Roger Pau Monné wrote:
>
>>> struct vcpu_hvm_context {
>>> /* 16bit fields of the strucutre will be used. */
>>> #define _VCPUHVM_MODE_16B 0
>>> #define VCPUHVM_MODE_16B (1<<_VCPUHVM_MODE_16B)
>>> /* 32bit fields of the structure will be used. */
>>> #d
El 24/07/15 a les 19.36, Konrad Rzeszutek Wilk ha escrit:
> On Fri, Jul 24, 2015 at 06:54:09PM +0200, Roger Pau Monné wrote:
>> I have the feeling that we are over engineering this interface. IMHO we
>> should only allow the user to set the control registers, efer (on amd64)
>> and the GP registers
On Fri, Jul 24, 2015 at 06:54:09PM +0200, Roger Pau Monné wrote:
> El 24/07/15 a les 17.49, Jan Beulich ha escrit:
> On 24.07.15 at 17:26, wrote:
> >> El 24/07/15 a les 14.44, Jan Beulich ha escrit:
> >> On 24.07.15 at 14:11, wrote:
> Or your idea was to put all the bitness specific
El 24/07/15 a les 17.49, Jan Beulich ha escrit:
On 24.07.15 at 17:26, wrote:
>> El 24/07/15 a les 14.44, Jan Beulich ha escrit:
>> On 24.07.15 at 14:11, wrote:
Or your idea was to put all the bitness specific registers inside of
another separate structure and then unionize them
>>> On 24.07.15 at 17:26, wrote:
> El 24/07/15 a les 14.44, Jan Beulich ha escrit:
> On 24.07.15 at 14:11, wrote:
>>> Or your idea was to put all the bitness specific registers inside of
>>> another separate structure and then unionize them? AFAICT the 16 and
>>> 32bit structures are going to
El 24/07/15 a les 14.41, Jan Beulich ha escrit:
On 24.07.15 at 13:49, wrote:
>> El 24/07/15 a les 13.11, Andrew Cooper ha escrit:
>>> To start straight in 64bit, you need gdtr and cs as a minimum
>>>
>>> With that in mind, room for each of the task registers, and segment
>>> selectors.
>>
>>
El 24/07/15 a les 14.44, Jan Beulich ha escrit:
On 24.07.15 at 14:11, wrote:
>> It seems kind of pointless IMHO, the reason to have the union is to be
>> able to access the registers using the native nomenclature, but if a
>> register doesn't exist in a specific bitness I don't see the point
>>> On 24.07.15 at 14:11, wrote:
> El 24/07/15 a les 12.46, Jan Beulich ha escrit:
> On 24.07.15 at 11:59, wrote:
>>> __DECL_GP_REG(flags);
>>
>> r8-r11, selector and descriptor registers, pseudo descriptor registers.
>> Or else for all of them their default state would need to be spelle
>>> On 24.07.15 at 13:49, wrote:
> El 24/07/15 a les 13.11, Andrew Cooper ha escrit:
>> To start straight in 64bit, you need gdtr and cs as a minimum
>>
>> With that in mind, room for each of the task registers, and segment
>> selectors.
>
> I was planning to say that on both 32 and 64 bits we s
El 24/07/15 a les 12.46, Jan Beulich ha escrit:
On 24.07.15 at 11:59, wrote:
>> Just to recap and to make sure I got all the points:
>>
>> - vCPU initialization from the toolstack (BSP initialization) is going
>> to be done using XEN_DOMCTL_sethvmcontext.
>> - XEN_DOMCTL_{get/set}vcpuconte
El 24/07/15 a les 13.11, Andrew Cooper ha escrit:
> On 24/07/15 10:59, Roger Pau Monné wrote:
>> struct vcpu_hvm_context {
>> /* 32bit fields of the structure will be used. */
>> #define _VCPUHVM_MODE_32B 0
>> #define VCPUHVM_MODE_32B (1<<_VCPUHVM_MODE_32B)
>> /* 64bit fi
>>> On 24.07.15 at 13:28, wrote:
> On Fri, 2015-07-24 at 12:11 +0100, Andrew Cooper wrote:
>>
>> To avoid making the 32bit (and optionally 16bit) massive as a side
>> effect of 64bit, can I suggest
>>
>> uint32_t flags;
>> union {
>> cpu_hvm32_regs;
>> cpu_hvm64_regs;
>> };
>>
>> Whi
>>> On 24.07.15 at 13:11, wrote:
>
> On 24/07/15 10:59, Roger Pau Monné wrote:
>> El 24/07/15 a les 10.22, Jan Beulich ha escrit:
>> On 23.07.15 at 19:12, wrote:
I would go with Jan's suggestion and make
XEN_DOMCTL_{get/set}vcpucontext ineligible for use on HVM guests.
>>> Plus, a
On Fri, 2015-07-24 at 12:11 +0100, Andrew Cooper wrote:
>
> To avoid making the 32bit (and optionally 16bit) massive as a side
> effect of 64bit, can I suggest
>
> uint32_t flags;
> union {
> cpu_hvm32_regs;
> cpu_hvm64_regs;
> };
>
> Which allows hvm32_regs to be a far smaller struct
On 24/07/15 10:59, Roger Pau Monné wrote:
El 24/07/15 a les 10.22, Jan Beulich ha escrit:
On 23.07.15 at 19:12, wrote:
I would go with Jan's suggestion and make
XEN_DOMCTL_{get/set}vcpucontext ineligible for use on HVM guests.
Plus, as you said earlier, a new VCPUOP_initialize.
(Adding the
>>> On 24.07.15 at 11:59, wrote:
> Just to recap and to make sure I got all the points:
>
> - vCPU initialization from the toolstack (BSP initialization) is going
> to be done using XEN_DOMCTL_sethvmcontext.
> - XEN_DOMCTL_{get/set}vcpucontext is going to return EOPNOTSUPP for
> HVM guests.
>
El 24/07/15 a les 10.22, Jan Beulich ha escrit:
On 23.07.15 at 19:12, wrote:
>> I would go with Jan's suggestion and make
>> XEN_DOMCTL_{get/set}vcpucontext ineligible for use on HVM guests.
>
> Plus, as you said earlier, a new VCPUOP_initialize.
(Adding the Linux maintainers to get their o
>>> On 23.07.15 at 19:12, wrote:
> I would go with Jan's suggestion and make
> XEN_DOMCTL_{get/set}vcpucontext ineligible for use on HVM guests.
Plus, as you said earlier, a new VCPUOP_initialize.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.or
On 23/07/15 17:56, Roger Pau Monné wrote:
> El 23/07/15 a les 18.19, Jan Beulich ha escrit:
> On 23.07.15 at 18:15, wrote:
>>> On 23/07/15 17:00, Ian Campbell wrote:
On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
> O
El 23/07/15 a les 18.49, Andrew Cooper ha escrit:
> On 23/07/15 17:19, Jan Beulich wrote:
> On 23.07.15 at 18:15, wrote:
>>> On 23/07/15 17:00, Ian Campbell wrote:
On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
> On
El 23/07/15 a les 18.19, Jan Beulich ha escrit:
On 23.07.15 at 18:15, wrote:
>> On 23/07/15 17:00, Ian Campbell wrote:
>>> On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
El 23/07/15 a les 17.32, Jan Beulich ha escrit:
On 23.07.15 at 17:10, wrote:
>> IMHO introduc
On 23/07/15 17:19, Jan Beulich wrote:
On 23.07.15 at 18:15, wrote:
>> On 23/07/15 17:00, Ian Campbell wrote:
>>> On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
El 23/07/15 a les 17.32, Jan Beulich ha escrit:
On 23.07.15 at 17:10, wrote:
>> IMHO introducing a new
>>> On 23.07.15 at 18:15, wrote:
> On 23/07/15 17:00, Ian Campbell wrote:
>> On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
>>> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
>>> On 23.07.15 at 17:10, wrote:
> IMHO introducing a new structure that gets rid of all the PV-only
On 23/07/15 17:00, Ian Campbell wrote:
> On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
>> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
>> On 23.07.15 at 17:10, wrote:
IMHO introducing a new structure that gets rid of all the PV-only
fields seems like a good optio
On Thu, 2015-07-23 at 17:48 +0200, Roger Pau Monné wrote:
> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
> > > > > On 23.07.15 at 17:10, wrote:
> > > IMHO introducing a new structure that gets rid of all the PV-only
> > >
> > > fields seems like a good option:
> > >
> > > struct vcpu_hvm_con
>>> On 23.07.15 at 17:48, wrote:
> El 23/07/15 a les 17.32, Jan Beulich ha escrit:
> On 23.07.15 at 17:10, wrote:
>>> IMHO introducing a new structure that gets rid of all the PV-only
>>> fields seems like a good option:
>>>
>>> struct vcpu_hvm_context {
>>> #define _VGCF_online
El 23/07/15 a les 17.32, Jan Beulich ha escrit:
On 23.07.15 at 17:10, wrote:
>> IMHO introducing a new structure that gets rid of all the PV-only
>> fields seems like a good option:
>>
>> struct vcpu_hvm_context {
>> #define _VGCF_online 5
>> #define VGCF_online
>>> On 23.07.15 at 17:10, wrote:
> IMHO introducing a new structure that gets rid of all the PV-only
> fields seems like a good option:
>
> struct vcpu_hvm_context {
> #define _VGCF_online 5
> #define VGCF_online(1<<_VGCF_online)
> uint32_t flags;
El 23/07/15 a les 13.41, Ian Campbell ha escrit:
> On Thu, 2015-07-23 at 05:29 -0600, Jan Beulich wrote:
>>>
> On 23.07.15 at 12:25, wrote:
>>> El 13/07/15 a les 16.01, Jan Beulich ha escrit:
>>> On 03.07.15 at 13:34, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domai
On Thu, 2015-07-23 at 05:29 -0600, Jan Beulich wrote:
> >
> > > > On 23.07.15 at 12:25, wrote:
> > El 13/07/15 a les 16.01, Jan Beulich ha escrit:
> > > > > > On 03.07.15 at 13:34, wrote:
> > > > --- a/xen/arch/x86/domain.c
> > > > +++ b/xen/arch/x86/domain.c
> > > > @@ -795,6 +795,15 @@ int arc
>>> On 23.07.15 at 12:25, wrote:
> El 13/07/15 a les 16.01, Jan Beulich ha escrit:
> On 03.07.15 at 13:34, wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -795,6 +795,15 @@ int arch_set_info_guest(
>>>c.nat->fs_base || c.nat->gs_base_user)) )
>>>
El 13/07/15 a les 16.01, Jan Beulich ha escrit:
On 03.07.15 at 13:34, wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -795,6 +795,15 @@ int arch_set_info_guest(
>>c.nat->fs_base || c.nat->gs_base_user)) )
>> return -EINVAL;
>> }
>>
El 10/07/15 a les 20.47, Konrad Rzeszutek Wilk ha escrit:
> On Fri, Jul 03, 2015 at 01:34:45PM +0200, Roger Pau Monne wrote:
>> Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
>> always started in 32bit protected mode with paging disabled.
>
> This is kind of odd in the
El 06/07/15 a les 14.58, Andrew Cooper ha escrit:
> On 03/07/15 12:34, Roger Pau Monne wrote:
>> Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
>> always started in 32bit protected mode with paging disabled.
>>
>> Signed-off-by: Roger Pau Monné
>> Cc: Jan Beulich
>> C
>>> On 03.07.15 at 13:34, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -795,6 +795,15 @@ int arch_set_info_guest(
>c.nat->fs_base || c.nat->gs_base_user)) )
> return -EINVAL;
> }
> +else if ( is_hvm_domain(d) )
> +{
> +if
On Fri, Jul 03, 2015 at 01:34:45PM +0200, Roger Pau Monne wrote:
> Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
> always started in 32bit protected mode with paging disabled.
This is kind of odd in the placement of the series. The next couple of
patches deal with the
On Fri, Jul 03, 2015 at 01:34:45PM +0200, Roger Pau Monne wrote:
> Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
> always started in 32bit protected mode with paging disabled.
Please mention that only the HVM guests which use the VCPU_xx hypercalls
are the ones that a
On 03/07/15 12:34, Roger Pau Monne wrote:
> Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
> always started in 32bit protected mode with paging disabled.
>
> Signed-off-by: Roger Pau Monné
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86/domain.c | 14
Add checks for ignored vcpu fields in HVM mode. HVM vCPUs (BSP and APs) are
always started in 32bit protected mode with paging disabled.
Signed-off-by: Roger Pau Monné
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/domain.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions
49 matches
Mail list logo
