>>> On 28.03.17 at 10:15, wrote:
> On Tue, Mar 28, 2017 at 01:17:27AM -0600, Jan Beulich wrote:
>> >>> On 27.03.17 at 18:49, wrote:
>> > Yes, I think the unnamed structure is way better, here's what I've done:
>> >
>> > save.h:
>> >
>> > union vioapic_redir_entry
>> > {
>> > uint64_t bits;
On Tue, Mar 28, 2017 at 01:17:27AM -0600, Jan Beulich wrote:
> >>> On 27.03.17 at 18:49, wrote:
> > Yes, I think the unnamed structure is way better, here's what I've done:
> >
> > save.h:
> >
> > union vioapic_redir_entry
> > {
> > uint64_t bits;
> > struct {
> > uint8_t vector;
>>> On 27.03.17 at 18:49, wrote:
> Yes, I think the unnamed structure is way better, here's what I've done:
>
> save.h:
>
> union vioapic_redir_entry
> {
> uint64_t bits;
> struct {
> uint8_t vector;
> uint8_t delivery_mode:3;
> uint8_t dest_mode:1;
> uint
On Mon, Mar 27, 2017 at 09:38:49AM -0600, Jan Beulich wrote:
> >>> On 27.03.17 at 12:18, wrote:
> > The reason to expand the hvm_vioapic structure instead of the hvm_hw_vioapic
> > one is that the variable number of pins functionality is only going to be
> > used
> > by the hardware domain, so no
>>> On 27.03.17 at 12:18, wrote:
> The reason to expand the hvm_vioapic structure instead of the hvm_hw_vioapic
> one is that the variable number of pins functionality is only going to be used
> by the hardware domain, so no modifications are needed to the save format.
As you say here you expand
This is required in order to have a variable number of vIO APIC pins, instead
of the current fixed value (48). Note that this patch only expands the fields
of the hvm_vioapic struct, without actually introducing any new fields or
functionality.
The reason to expand the hvm_vioapic structure instea
