Komunikacja między partycjami

Funkcja hypervisor udostępnia dwa proste mechanizmy komunikacji z jedną partycją: komunikaty i zdarzenia. W obu przypadkach powiadomienie jest sygnalizowane przy użyciu synIC (syntetyczny kontroler przerwań).

Komunikaty synic

Funkcja hypervisor udostępnia prostą funkcję komunikacji między partycjami, która umożliwia jednej partycji wysyłanie sparametryzowanego komunikatu do innej partycji. (Ponieważ wiadomość jest wysyłana asynchronicznie, mówi się, że ma zostać wysłana). Partycja docelowa może zostać powiadomiona o nadejściu tej wiadomości przez przerwanie. Komunikaty mogą być wysyłane jawnie przy użyciu funkcji hypercallPostMessage HvCallMessage lub niejawnie przez funkcję hypervisor.

Messages

Po wysłaniu komunikatu funkcja hypervisor wybiera wolny bufor komunikatów. Zestaw dostępnych komunikatów zależy od zdarzenia, które wyzwoliło wysyłanie komunikatu.

Funkcja hypervisor oznacza bufor komunikatów "w użyciu" i wypełnia nagłówek komunikatu typem komunikatu, rozmiarem ładunku i informacjami o nadawcy. Na koniec wypełnia ładunek komunikatu. Zawartość ładunku zależy od zdarzenia, które wyzwoliło komunikat.

Następnie funkcja hypervisor dołącza bufor komunikatów do kolejki komunikatów odbierających. Kolejka komunikatów odbierających zależy od zdarzenia, które wyzwoliło wysyłanie komunikatu. W przypadku wszystkich typów komunikatów SINTx jest niejawny (w przypadku przechwytywania komunikatów), jawny (w przypadku komunikatów czasomierza) lub określony przez identyfikator portu (w przypadku komunikatów gościa). Docelowy procesor wirtualny jest jawnie określony lub wybrany przez funkcję hypervisor, gdy komunikat jest w kolejce. Procesory wirtualne, których strona SynIC lub SIM jest wyłączona, nie będą traktowane jako potencjalne cele. Jeśli żadne obiekty docelowe nie są dostępne, funkcja hypervisor kończy operację i zwraca błąd do wywołującego.

Funkcja hypervisor określa następnie, czy określone miejsce komunikatu SINTx na stronie SIM dla docelowego procesora wirtualnego jest puste. Jeśli typ komunikatu w miejscu komunikatu jest równy HvMessageTypeNone (czyli zero), zakłada się, że miejsce komunikatu jest puste. W takim przypadku funkcja hypervisor dequeuuje bufor komunikatu i kopiuje jego zawartość do miejsca komunikatu na stronie SIM. Funkcja hypervisor może kopiować tylko liczbę bajtów ładunku skojarzonych z komunikatem. Funkcja hypervisor próbuje również wygenerować przerwanie wyzwalane przez krawędź dla określonego SINTx. Jeśli APIC jest wyłączone oprogramowanie lub SINTx jest zamaskowany, przerwanie zostanie utracone. Przybycie tego przerwania powiadamia gościa o nadejściu nowej wiadomości. Jeśli strona SIM jest wyłączona lub miejsce komunikatu na stronie SIM nie jest puste, komunikat pozostanie w kolejce i nie zostanie wygenerowany żaden przerwanie.

Podobnie jak w przypadku przerwania o stałym priorytcie, przerwanie nie jest potwierdzane przez procesor wirtualny, dopóki rejestr PPR (rejestr priorytetu procesu) nie jest mniejszy niż wektor określony w rejestrze SINTx i przerwania nie są maskowane przez procesor wirtualny (rFLAGS[IF] jest ustawiony na 1).

Wiele komunikatów z tym samym SINTx można kolejkować do procesora wirtualnego. W takim przypadku funkcja hypervisor dostarczy pierwszy komunikat (czyli zapisz go na stronie SIM) i pozostaw inne umieszczone w kolejce do momentu wystąpienia jednego z trzech zdarzeń:

• Inny bufor komunikatów jest kolejkowany.
• Gość wskazuje "koniec przerwania", pisząc do rejestru EOI APIC.
• Gość wskazuje "koniec wiadomości", pisząc do rejestru EOM synIC.

We wszystkich trzech przypadkach funkcja hypervisor przeskanuje co najmniej jedną kolejkę bufora komunikatów i spróbuje dostarczyć dodatkowe komunikaty. Funkcja hypervisor próbuje również wygenerować przerwanie wyzwalane przez krawędź, co oznacza, że przybył nowy komunikat.

Strona SIM

Strona SIM składa się z tablicy 16 elementów 256-bajtowych komunikatów (zobacz HV_MESSAGE strukturę danych). Każdy element tablicy (znany również jako gniazdo komunikatów) odpowiada jednemu syntetycznym źródle przerwań (SINTx). Mówi się, że miejsce komunikatu jest "puste", jeśli typ komunikatu w miejscu jest równy HvMessageTypeNone.

Adres strony SIM jest określony w rejestrze SIMP. Adres strony SIM powinien być unikatowy dla każdego procesora wirtualnego. Programowanie tych stron w celu nakładania się innych wystąpień stron SIEF lub SIM lub dowolnej innej strony nakładki (na przykład strony hypercall) spowoduje niezdefiniowane zachowanie.

Dostęp do odczytu i zapisu przez procesor wirtualny na stronie SIM zachowuje się jak dostęp do odczytu i zapisu do pamięci RAM. Jednak implementacja SynIC funkcji hypervisor zapisuje również na stronach w odpowiedzi na określone zdarzenia.

Po utworzeniu i zresetowaniu procesora wirtualnego strona SIM zostanie wyczyszczone do zera.

Zalecana obsługa komunikatów

Mechanizm dostarczania komunikatów SynIC został zaprojektowany w celu zapewnienia wydajnego dostarczania i odbierania komunikatów w partycji docelowej. Zaleca się, aby obsługa komunikatów ISR (procedura usługi przerwania) w partycji docelowej wykonywała następujące czynności:

• Sprawdź komunikat, który został zdeponowany w miejscu komunikatu SIM.
• Skopiuj zawartość wiadomości do innej lokalizacji i ustaw typ komunikatu w miejscu komunikatu na HvMessageTypeNone.
• Wskaż koniec przerwania dla wektora, zapisując w rejestrze EOI APIC.
• Wykonaj wszelkie akcje dorozumiane przez komunikat.

Źródła komunikatów

Klasy zdarzeń, które mogą wyzwolić wysyłanie komunikatu, są następujące:

• Przechwytuje: przechwycenie w procesorze wirtualnym spowoduje wysłanie komunikatu do partycji nadrzędnej lub wyższej biblioteki VTL.
• Czasomierze: mechanizmy czasomierza spowodują wysłanie komunikatów. Skojarzony z każdym procesorem wirtualnym to cztery dedykowane komunikatów czasomierza, po jednym dla każdego czasomierza. Kolejka komunikatów odbierających należy do SINTx procesora wirtualnego, którego czasomierz wyzwolił wysyłanie komunikatu.
• Komunikaty gościa: funkcja hypervisor obsługuje przekazywanie komunikatów jako mechanizm komunikacji między partycjami między gośćmi. Interfejsy zdefiniowane w tej sekcji umożliwiają jednemu gościowi wysyłanie komunikatów do innego gościa. komunikatów używane w przypadku komunikatów tej klasy są pobierane z puli poszczególnych portów odbiornika komunikatów gościa.

komunikatów

Bufor komunikatów jest używany wewnętrznie do funkcji hypervisor do przechowywania komunikatu do momentu dostarczenia go do adresata. Funkcja hypervisor obsługuje kilka zestawów komunikatów.

komunikatów gościa

Funkcja hypervisor obsługuje zestaw komunikatów gościa dla każdego portu. Te są używane w przypadku komunikatów wysyłanych jawnie z jednej partycji do innej przez gościa. Po utworzeniu portu funkcja hypervisor przydzieli szesnaście komunikatów (16) z puli pamięci właściciela portu. Te komunikatów są zwracane do puli pamięci po usunięciu portu.

Kolejki komunikatów

Dla każdej partycji i każdego procesora wirtualnego w partycji funkcja hypervisor obsługuje jedną kolejkę komunikatów dla każdego sinTx (syntetyczne źródło przerwań) w synIC procesora wirtualnego. Wszystkie kolejki komunikatów procesora wirtualnego są puste podczas tworzenia lub resetowania procesora wirtualnego.

Niezawodność i sekwencjonowanie komunikatów gościa

Komunikaty pomyślnie opublikowane przez gościa zostały umieszczone w kolejce do dostarczania przez funkcję hypervisor. Rzeczywiste dostarczanie i odbiór przez partycję docelową zależy od prawidłowej operacji. Partycje mogą wyłączyć dostarczanie komunikatów do określonych procesorów wirtualnych, wyłączając funkcję SynIC lub wyłączając kartę SIMP.

Przerwanie połączenia nie wpłynie na komunikaty niedostarczone (w kolejce). Usunięcie portu docelowego zawsze spowoduje zwolnienie wszystkich komunikatów portu, niezależnie od tego, czy są dostępne, czy zawierają komunikaty niedostarczone (w kolejce).

Wiadomości docierają do kolejności, w której zostały pomyślnie opublikowane. Jeśli port odbierający jest skojarzony z określonym procesorem wirtualnym, komunikaty będą dostarczane w tej samej kolejności, w jakiej zostały opublikowane. Jeśli port odbierający jest skojarzony z HV_ANY_VP, komunikaty nie są gwarantowane do odebrania w jakiejkolwiek określonej kolejności.

Flagi zdarzeń synIC

Oprócz komunikatów synIC obsługuje drugi typ mechanizmu powiadamiania o różnych partycjach nazywanych flagami zdarzeń. Flagi zdarzeń można ustawić jawnie przy użyciu funkcji hypercall HvCallSignalEvent lub niejawnie przez funkcję hypervisor.

Flagi zdarzeń a komunikaty

Flagi zdarzeń są lżejsze niż komunikaty i dlatego są niższe obciążenie. Ponadto flagi zdarzeń nie wymagają żadnej alokacji buforu ani kolejkowania w ramach funkcji hypervisor, więc HvCallSignalEvent nigdy nie zakończy się niepowodzeniem z powodu niewystarczających zasobów.

Dostarczanie flagi zdarzeń

Gdy partycja wywołuje element HvCallSignalEvent, określa numer flagi zdarzenia. Funkcja hypervisor reaguje niepodziealnie na stronie SIEF odbierającego procesora wirtualnego. Procesory wirtualne, których strona SynIC lub SIEF jest wyłączona, nie będą traktowane jako potencjalne cele. Jeśli żadne obiekty docelowe nie są dostępne, funkcja hypervisor kończy operację i zwraca błąd do wywołującego.

Jeśli flaga zdarzenia została wcześniej wyczyszczone, funkcja hypervisor próbuje powiadomić partycję odbierającą, że flaga jest teraz ustawiona przez wygenerowanie przerwania wyzwalanego przez krawędź. Docelowy procesor wirtualny, wraz z docelowym SINTx, jest określany jako część tworzenia portu. Jeśli sinTx jest maskowany, HvSignalEvent zwraca HV_STATUS_INVALID_SYNIC_STATE.

Podobnie jak w przypadku jakichkolwiek przerwań zewnętrznych o stałym priorytcie, przerwanie nie jest uznawane przez procesor wirtualny, dopóki rejestr priorytetu procesu (PPR) nie jest mniejszy niż wektor określony w rejestrze SINTx i przerwania nie są maskowane przez procesor wirtualny (rFLAGS[IF] jest ustawiony na 1).

Strona SIEF

Strona SIEF składa się z 16-elementowej tablicy 256-bajtowych flag zdarzeń (zobacz HV_SYNIC_EVENT_FLAGS). Każdy element tablicy odpowiada jednemu syntetycznym źródle przerwań (SINTx).

Adres strony SIEF jest określony w rejestrze SIEF. Adres strony SIEF powinien być unikatowy dla każdego procesora wirtualnego. Programowanie tych stron w celu nakładania się innych wystąpień stron SIEF lub SIM lub dowolnej innej strony nakładki (na przykład strony hypercall) spowoduje niezdefiniowane zachowanie.

Dostęp do odczytu i zapisu przez procesor wirtualny na stronie SIEF zachowuje się jak dostęp do odczytu i zapisu do pamięci RAM. Jednak implementacja SynIC funkcji hypervisor zapisuje również na stronach w odpowiedzi na określone zdarzenia.

Po utworzeniu i zresetowaniu procesora wirtualnego strona SIEF zostanie wyczyszczone do zera.

Zalecana obsługa flag zdarzeń

Zaleca się, aby w ramach partycji docelowej procedury przerwania usługi (ISR) flaga zdarzenia wykonywała następujące czynności:

• Sprawdź flagi zdarzeń i określ, które, jeśli istnieją, są ustawione.
• Wyczyść co najmniej jedną flagę zdarzenia przy użyciu zablokowanej (niepodzielnej) operacji, takiej jak LOCK AND lub LOCK CMPXCHG.
• Wskaż koniec przerwania dla wektora, zapisując w rejestrze EOI APIC.
• Wykonaj wszelkie akcje sugerowane przez flagi zdarzeń, które zostały ustawione.

Porty i połączenia

Komunikat lub zdarzenie wysyłane z jednego gościa do innego musi być wysyłane za pośrednictwem wstępnie przydzielonego połączenia. Z kolei połączenie musi być skojarzone z portem docelowym.

Port jest przydzielany z puli pamięci odbiorcy i określa, który procesor wirtualny i SINTx mają być docelowe. Porty zdarzeń mają "numer flagi podstawowej" i "liczbę flag", które umożliwiają obiektowi wywołującym określenie zakresu prawidłowych flag zdarzeń dla tego portu.

Połączenia są przydzielane z puli pamięci nadawcy. Po utworzeniu połączenia musi być skojarzony z prawidłowym portem. To powiązanie tworzy prosty, jednokierunkowy kanał komunikacyjny. Jeśli port zostanie następnie usunięty, jego połączenie, gdy pozostanie, stanie się bezużyteczne.

Rejestry synIC

Każdy procesor wirtualny ma własną kopię tych rejestrów, więc można je programować niezależnie.

Na platformach x64 te rejestry są dostępne jako rejestry specyficzne dla modelu (MSR) przy użyciu instrukcji RDMSR i WRMSR:

Na platformach ARM64 te rejestry są dostępne przy użyciu HvCallGetVpRegisters i HvCallSetVpRegisters hypercallers z następującymi nazwami rejestrów:

Rejestrowanie SCONTROL

Ten rejestr służy do kontrolowania zachowania SynIC procesora wirtualnego.

W czasie tworzenia procesora wirtualnego i po zresetowaniu procesora wartość tego rejestru kontroli SCONTROL (SynIC) jest 0x0000000000000000. W związku z tym kolejkowanie komunikatów i powiadomienia o flagach zdarzeń zostaną wyłączone.

Rejestracja SVERSION

Jest to rejestr tylko do odczytu i zwraca numer wersji synIC. Próby zapisu w tym rejestrze powodują błąd #GP.

Rejestracja SIEFP

W czasie tworzenia procesora wirtualnego i po zresetowaniu procesora wartość tego rejestru SIEFP (syntetyczne flagi zdarzeń przerwania) jest 0x0000000000000000. W związku z tym protokół SIEFP jest domyślnie wyłączony. Gość musi go włączyć, ustawiając bit 0. Jeśli określony adres podstawowy znajduje się poza końcem przestrzeni gpA partycji, strona SIEFP nie będzie dostępna dla gościa. Podczas modyfikowania rejestru goście powinni zachować wartość zarezerwowanych bitów (od 1 do 11) w celu zapewnienia przyszłej zgodności.

Rejestrowanie SIMP

W czasie tworzenia procesora wirtualnego i po zresetowaniu procesora wartość tego rejestru SIMP (syntetyczna strona komunikatu przerwania) jest 0x0000000000000000. W związku z tym simp jest domyślnie wyłączony. Gość musi go włączyć, ustawiając bit 0. Jeśli określony adres podstawowy znajduje się poza końcem przestrzeni gpA partycji, strona SIMP nie będzie dostępna dla gościa. Podczas modyfikowania rejestru goście powinni zachować wartość zarezerwowanych bitów (od 1 do 11) w celu zapewnienia przyszłej zgodności.

Rejestry SINTx

W czasie tworzenia procesora wirtualnego wartość domyślna wszystkich rejestrów SINTx (syntetycznego źródła przerwań) jest 0x0000000000010000. W związku z tym wszystkie syntetyczne źródła przerwań są domyślnie maskowane. Gość musi je zdemaskować przez zaprogramowanie odpowiedniego wektora i wyczyszczenie bitu 16.

Ustawienie bitu sondowania będzie miało wpływ na usunięcie źródła przerwań, z wyjątkiem tego, że rzeczywiste przerwanie nie jest generowane.

Flaga AutoEOI wskazuje, że niejawna funkcja EOI powinna być wykonywana przez funkcję hypervisor po dostarczeniu przerwania do procesora wirtualnego. Ponadto funkcja hypervisor automatycznie wyczyści odpowiednią flagę w "rejestrze w usłudze" (ISR) wirtualnej APIC. Jeśli gość włączy to zachowanie, nie może wykonać EOI w swojej procedurze obsługi przerwania. Flaga AutoEOI może być włączona w dowolnym momencie, choć gość musi wykonać jawne EOI na przerwaniu lotu. Kwestie dotyczące czasu utrudniają ustalenie, czy określone przerwanie wymaga EOI, więc zaleca się, aby po zdemaskowaniu SINT jego ustawienia nie zostały zmienione. Podobnie flaga AutoEOI może być w dowolnym momencie wyłączona, chociaż obowiązują te same obawy dotyczące przerwań lotów

Prawidłowe wartości wektora to 16–255 włącznie. Określenie nieprawidłowej liczby wektorów powoduje #GP.

Rejestracja EOM

Zapis na końcu rejestracji komunikatów (EOM) przez gościa powoduje, że funkcja hypervisor skanuje kolejki wewnętrznego buforu komunikatów skojarzone z procesorem wirtualnym. Jeśli kolejka buforu komunikatów zawiera bufor komunikatu w kolejce, funkcja hypervisor próbuje dostarczyć komunikat. Dostarczanie komunikatów powiedzie się, jeśli strona SIM jest włączona, a miejsce komunikatu odpowiadające SINTx jest puste (oznacza to, że typ komunikatu w nagłówku jest ustawiony na HvMessageTypeNone). Jeśli komunikat zostanie pomyślnie dostarczony, jego odpowiedni wewnętrzny bufor komunikatu zostanie odsłonięty i oznaczony jako wolny. Jeśli odpowiedni sinTx nie jest maskowany, zostanie dostarczone przerwanie wyzwalane przez krawędź (czyli odpowiedni bit w IRR jest ustawiony).

Ten rejestr może być używany przez gości do "sondowania" wiadomości. Może być również używany jako sposób opróżniania kolejki komunikatów dla sintx, który został wyłączony (czyli maskowany).

Jeśli kolejki komunikatów są puste, zapis w rejestrze EOM jest no-op.

Odczyty z rejestru EOM zawsze zwracają zera.